OpenTelemetry は『観測性のデファクト標準』
OpenTelemetry (OTel) は traces/metrics/logs を統一する CNCF プロジェクトで、ベンダーロックインを避ける観測性基盤として広く採用されています。本記事では編集部の視点で、実務での使い方を公開情報をもとに整理します。Observability 実践 もご参考に。
OTel の3つの柱
(1) traces：分散トレーシング。(2) metrics：時系列メトリクス。(3) logs：構造化ログ。(4) baggage：context 伝搬の補助情報。(5) OTLP プロトコル：標準的なデータ送信。
SDK と Auto-instrumentation
(1) 各言語の SDK：Java/Python/Node.js/Go 等。(2) Auto-instrumentation：コード変更なしで導入。(3) Manual instrumentation：詳細制御。(4) Resource 属性：service.name/version 等。(5) Semantic Conventions：標準的な属性名。
Collector の設計
(1) receivers：データ受信。(2) processors：データ加工(filter/batch/transform)。(3) exporters：データ送信。(4) pipelines：上記の組合せ。(5) HA 構成：複数台でスケール。中央集約することでアプリの簡素化と運用効率化を両立。
サンプリング戦略
(1) Head-based：開始時に判定。(2) Tail-based：完了後に判定(エラー優先保持)。(3) 確率サンプリング：固定比率。(4) ルールベース：エンドポイント別。(5) adaptive sampling：負荷に応じて調整。分散トレーシング実践 もご参考に。
ベンダー連携
(1) Datadog：OTLP 受信対応。(2) New Relic：OTLP 直接送信可。(3) Honeycomb：OTel フレンドリー。(4) Grafana Tempo/Loki/Mimir：OSS スタック。(5) 切替容易：ベンダー非依存の利点。Datadog 活用ガイド もご参考に。
本番運用のポイント
(1) Collector のキャパシティ計算。(2) Backpressure：受信側超過対応。(3) セキュリティ：TLS・認証。(4) 属性の数制限：高 cardinality 注意。(5) 監視自体の監視：Collector の health。Prometheus+Grafana 実践 も合わせて。
失敗しがちなパターン
(1) Context 伝搬し忘れ：trace 切断。(2) 属性に PII 混入：監査リスク。(3) 過度なサンプル率：コスト爆発。(4) Collector SPOF。(5) 計装放置：データの品質低下。対策は、(1)Auto-instrumentation+確認、(2)PII 除外フィルタ、(3)Tail-based 併用、(4)Collector HA、(5)定期レビュー、です。