OpenTelemetry（OTel）は、テレメトリ（トレース、メトリクス、ログ）を生成、収集、エクスポートするための、オープンソースでベンダー中立なフレームワークです。データモデル、ワイヤープロトコル（OTLP）、アプリケーションが使う SDK、データを受信してルーティングする Collector を定義しています。独自のバックエンドを持たないため、同じデータを Grafana、Prometheus、Jaeger、あるいは商用ベンダーに送ることができ、後からコードを再計装することなく切り替えられます。

OpenTelemetry のほとんどすべては、テキストで設定されます。Collector 用の YAML ファイル、SDK 用の環境変数、そして最近では SDK 用の宣言的な YAML ファイルもあります。このシリーズはそこに焦点を当てているため、テレメトリの構成は、インフラの他の部分と同じように、レビューされ、バージョン管理され、再現可能になります。

仕組み

アプリケーションは、OpenTelemetry の SDK（または SDK を注入するコード不要のエージェント）で計装されます。SDK はスパン、メトリクス、ログレコードを作成し、通常は Collector へ OTLP でエクスポートします。Collector はデータを受信し、処理（バッチ処理、エンリッチメント、フィルタリング、サンプリング）し、1 つ以上のバックエンドにエクスポートします。

App + SDK ──OTLP──▶ Collector (receivers → processors → exporters) ──▶ Backends

主要な概念

• シグナル — トレース、メトリクス、ログ。プロファイルが 4 つ目のシグナルとして登場しつつあります。
• API と SDK — API は計装が呼び出すもので、SDK はサンプリング、バッチ処理、エクスポートを行う実装です。
• OTLP — OpenTelemetry のプロトコルで、gRPC（ポート 4317）または HTTP（ポート 4318）を使います。
• Collector — receiver、processor、exporter、connector、extension から構築され、service.pipelines で接続される、スタンドアロンのバイナリです。
• Resource — service.name や deployment.environment.name など、テレメトリを生成するものを記述する属性です。
• セマンティック規約 — 異なる言語やライブラリのデータが同じように見えるようにするための、標準の属性名です。
• サンプリング — どのトレースを保持するかを、SDK（head サンプリング）または Collector（tail サンプリング）で決めます。
• 計装 — テレメトリを作成する、手作業のコード、ライブラリ、またはコード不要のエージェントです。

チームが OpenTelemetry を採用する理由

• ロックインなし。 バックエンドの変更は、アプリケーションのコードではなく、Collector の設定を編集することで行います。
• すべてに 1 つのパイプライン。 同じ Collector が、すべての言語のトレース、メトリクス、ログを処理します。
• エッジでの制御。 データがネットワークを出る前に、フィルター、マスキング、サンプリング、ルーティングを行えます。
• 一貫した命名。 セマンティック規約により、ダッシュボードとアラートがポータブルになります。
• コードとしての設定。 Collector の YAML と SDK の環境変数は、Flux や Argo CD のような GitOps ツールに適合します。

はじめに

小さな設定ファイルで Collector を実行し、いくつかの OTEL_* 環境変数でアプリケーションをそれに向け、Collector の debug exporter でデータを確認します。以降のガイドでは、そこから、コード不要の計装、サンプリング、Kubernetes、本番向けのハードニングへと進みます。これらは、最近の Collector のリリース（0.16x 系）と、安定した宣言的設定のスキーマを想定して書かれています。インストールするバージョンについては、OpenTelemetry のドキュメントを確認してください。Collector のコンポーネントは安定性がさまざまだからです。