ストーリー
田
田中VPoE
アーキテクチャの全体像が見えた。次はデータ収集パイプラインの設計だ。ここは可観測性基盤の「血管」にあたる
あなた
OpenTelemetry Collectorを使えばいいんですよね?
あ
田
田中VPoE
Collectorは核心だが、それだけでは不十分だ。15のマイクロサービスから毎秒数万件のテレメトリデータが流れ込む。サンプリング、フィルタリング、エンリッチメント、バッファリング — パイプラインの設計が悪いと、データ爆発でコストが跳ね上がるか、重要なデータが欠損する
田
田中VPoE
そうだ。「すべてのデータを最高解像度で保存する」は理想だが、現実的ではない。価値のあるデータを適切な解像度で、適切な期間保持する。これがデータ収集戦略の核心だ
OpenTelemetry Collector の設計
Collector デプロイメントパターン
| パターン | 構成 | 適用 |
|---|
| Agent | 各ホスト/PodにサイドカーとしてCollectorをデプロイ | ホストメトリクス収集、ローカル処理 |
| Gateway | 中央集約ポイントとしてCollectorクラスタをデプロイ | ルーティング、高度な処理 |
| Agent + Gateway | ローカルAgentで一次処理、Gatewayで集約処理 | 大規模環境の推奨構成 |
推奨構成(Agent + Gateway):
Service A ─→ Agent Collector ─┐
Service B ─→ Agent Collector ─┤
Service C ─→ Agent Collector ─┼─→ Gateway Collector ─→ Backend
Service D ─→ Agent Collector ─┤ (集約・ルーティング)
Service E ─→ Agent Collector ─┘
Agent の役割:
├── ローカルバッファリング
├── 基本的なフィルタリング
├── リソース属性の付加
└── バッチ送信
Gateway の役割:
├── テイルサンプリング
├── 高度なフィルタリング
├── ルーティング(バックエンド振り分け)
└── レート制限
パイプライン設計(Receiver → Processor → Exporter)
receivers: processors: exporters:
├── otlp ├── batch ├── otlphttp (SaaS)
├── prometheus ├── filter ├── prometheusremotewrite
├── filelog ├── attributes ├── loki
├── hostmetrics ├── tail_sampling └── debug
└── k8s_events ├── resource
├── transform
└── memory_limiter
サンプリング戦略
サンプリングの種類
| 種類 | 説明 | 適用場面 |
|---|
| ヘッドサンプリング | リクエスト開始時に確率的にサンプリングを決定 | 一律的なトラフィック削減 |
| テイルサンプリング | リクエスト完了後に結果に基づいてサンプリングを決定 | エラーや遅延の確実な捕捉 |
| アダプティブサンプリング | トラフィック量に応じて動的にサンプリング率を調整 | トラフィック変動が大きい環境 |
テイルサンプリングの推奨ポリシー
| ポリシー | ルール | 目的 |
|---|
| エラー100%保持 | ステータスコード5xx → サンプリング率100% | エラーを確実に捕捉 |
| 遅延トレース保持 | レイテンシ > P99 → サンプリング率100% | パフォーマンス問題の分析 |
| 通常トレース削減 | 正常レスポンス → サンプリング率10% | コスト削減 |
| 重要サービス優先 | 決済サービス → サンプリング率50% | ビジネスクリティカルなサービスの可視性確保 |
| ヘルスチェック除外 | /health, /readiness → サンプリング率0% | ノイズ除去 |
テイルサンプリング設定例:
processors:
tail_sampling:
decision_wait: 10s
policies:
- name: error-policy
type: status_code
status_code: {status_codes: [ERROR]}
- name: latency-policy
type: latency
latency: {threshold_ms: 1000}
- name: rate-limiting-policy
type: probabilistic
probabilistic: {sampling_percentage: 10}
ログ収集標準
構造化ログフォーマット
| フィールド | 必須/推奨 | 説明 | 例 |
|---|
timestamp | 必須 | ISO 8601形式のタイムスタンプ | 2026-03-04T10:30:00.123Z |
level | 必須 | ログレベル | INFO, WARN, ERROR |
message | 必須 | 人間が読めるメッセージ | "Payment processed successfully" |
service.name | 必須 | サービス名 | "payment-service" |
trace_id | 必須 | 分散トレースの相関ID | "abc123def456" |
span_id | 必須 | スパンID | "789ghi012" |
user_id | 推奨 | ユーザー識別子(匿名化済み) | "user_hash_xxx" |
environment | 必須 | 環境名 | "production" |
error.type | 条件付き必須 | エラー時のエラータイプ | "ConnectionTimeout" |
error.stack | 条件付き必須 | エラー時のスタックトレース | "at ..." |
メトリクス命名規則
命名規則: <namespace>_<subsystem>_<name>_<unit>
例:
http_server_request_duration_seconds (ヒストグラム)
http_server_request_total (カウンター)
db_connection_pool_active_connections (ゲージ)
payment_transaction_amount_jpy_total (カウンター)
禁止:
✗ requestCount → ○ http_server_request_total
✗ api.latency → ○ http_server_request_duration_seconds
✗ DBConnections → ○ db_connection_pool_active_connections
データボリューム管理
データティアリング
| ティア | データ種別 | 解像度 | 保持期間 | ストレージ | コスト |
|---|
| Hot | 直近のメトリクス、アクティブトレース | フル解像度 | 7日 | SSD / メモリ | 高 |
| Warm | 中期メトリクス、重要ログ | ダウンサンプリング | 30日 | SSD | 中 |
| Cold | 長期メトリクス、アーカイブログ | 高度にダウンサンプリング | 1年 | S3 / GCS | 低 |
| Archive | コンプライアンス用データ | 最小限 | 3-7年 | S3 Glacier | 最低 |
コスト最適化の原則
| 原則 | 具体的なアクション |
|---|
| 収集時点でのフィルタリング | デバッグログは本番では収集しない |
| 適切なサンプリング | 正常トレースの90%を削減 |
| ダウンサンプリング | 古いメトリクスは1分→5分→1時間に集約 |
| 重複排除 | 同一イベントの重複を排除 |
| 圧縮 | 転送・保存時にgzip/snappy圧縮 |
「データ収集の鉄則は”必要なデータを最小コストで確保する”ことだ。“全部取って後で考える”は月末の請求書を見て後悔する」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| Collectorデプロイ | Agent + Gatewayの2層構成が大規模環境での推奨 |
| サンプリング | テイルサンプリングでエラー・遅延は100%保持、通常は削減 |
| ログ標準 | JSON構造化ログ、trace_id/span_id必須 |
| コスト管理 | データティアリングとサンプリングでコスト最適化 |
チェックリスト
次のステップへ
次は「ストレージと分析基盤」を学びます。収集したデータをどのように効率的に保存し、高速に分析するかの設計手法を身につけましょう。
推定読了時間: 30分