LESSON 30分

ストーリー

田中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必須
コスト管理データティアリングとサンプリングでコスト最適化

チェックリスト

  • OTel Collectorのデプロイメントパターンを理解した
  • テイルサンプリングの仕組みと推奨ポリシーを理解した
  • 構造化ログフォーマットとメトリクス命名規則を理解した
  • データティアリングによるコスト最適化を理解した

次のステップへ

次は「ストレージと分析基盤」を学びます。収集したデータをどのように効率的に保存し、高速に分析するかの設計手法を身につけましょう。


推定読了時間: 30分