OpenTelemetryに基づくフルリンクトレース

可観測性 - 鳥瞰図

前の記事で述べたように、可観測性とは、システムによって生成された外部データ (ログ、メトリック、トレースなど) に関する知識に基づいて、システム内で何が起こっているかを把握する能力です。

多くの場合、可観測性は、Dynatrace や OpenTelemetry などのオープンソース プロジェクトを通じて入手できるテレメトリ データによってサポートされます。 OpenTelemetry は、ベンダーに依存しないライブラリ/API、SDK、およびその他のツールの統合セットを提供することを目的とした Cloud Native Computing Foundation (CNCF) サンドボックス プロジェクトです。その主要な貢献者の 1 つが Dynatrace です。

OpenTelemetry を使用すると、IT チームはアプリケーションをインストルメント化し、テレメトリ データを生成、収集、エクスポートして、ソフトウェア アーキテクチャのパフォーマンスとシステムの動作を分析および理解できます。

Kubernetes がコンテナ オーケストレーションのデファクト スタンダードになったのと同様に、OpenTelemetry はクラウド ネイティブ アプリケーションに可観測性を追加するためのデファクト スタンダードになりました。つまり、企業はアプリケーションテレメトリデータを収集するためのメカニズムの開発に貴重な時間を費やす必要がなくなり、代わりに主力製品に集中できるようになります。

OpenTelemetry とは何ですか?

OpenTelemetry (OTel とも呼ばれます) は、一連のツール、API、SDK で構成されるオープン ソースの可観測性フレームワークです。 Otel を使用すると、IT チームはテレメトリ データを検出、生成、収集、エクスポートして、ソフトウェアのパフォーマンスと動作を分析および理解できるようになります。

CNCF プロジェクトとして、OpenTelemetry は言語に依存しない仕様を定義し、ログ、メトリック、トレースなどの観測データをベンダーに依存しない方法で処理するための API と SDK のコレクションを提供します。このプロジェクトは、OpenTracing と OpenCensus という 2 つの競合プロジェクトを融合したもので、Google、Microsoft、Amazon などの大手クラウド プロバイダーや、Splunk、Elastic、Datadog、LightStep、DynaTrace、NewRelic、Logzio、HoneyComb など、可観測性分野のほぼすべてのベンダーからサポートを受けています。既存および将来のグリーンフィールド プロジェクトで OpenTelemetry を採用するメリットを検討してみましょう。

1. OpenTelemetry仕様の言語中立性により、異なる言語での実装が可能

現在、この記事の執筆時点では、OpenTelemetry SIG - Special Interest Group は、C++ など、最も広く使用されている汎用言語のいくつかで実装を提供しています。 Net、Java、Javascript、Python、Go、Rust、Erlang、Ruby、PHP、Swift。これらは、単一の言語の実装に重点を置いた献身的な貢献者のグループです。現在サポートされていない言語を使用するソフトウェア プロジェクトがある場合、将来サポートされる可能性があります。これらすべてにより、ソフトウェア コンポーネントを実装する際の柔軟性が向上します。言語の選択に関係なく、インストルメンテーションは同じままです。

2. OpenTelemetry スケーラビリティ アーキテクチャ

OpenTelemetry の拡張可能なアーキテクチャにより、ライブラリ/プラグインの作成者は API を使用してコードをインストルメント化することができ、これらの成果物が OpenTelemetry SDK を実装するサービスまたはアプリケーションで使用されると、サービス コードとサードパーティ ライブラリの両方のパフォーマンスを可視化できます。 Microsoft の分散アプリケーション ランタイム ライブラリがその一例です。 Spring や Express などの一般的なフレームワーク用のプラグインがあります。

3. OpenTelemetryはベンダーロックインを防ぐ

OpenTelemetry Collector を使用すると、テレメトリ データの受信、処理、エクスポートが可能になり、Jaeger、Prometheus、Fluent Bit、W3C TraceContext 形式、Zipkin の B3 ヘッダーなど、さまざまなオープン ソースがサポートされます。さらに、エクスポーターのさまざまなテレメトリ バックエンドの実装により、ベンダー間の切り替えが簡単になります。たとえば、NewRelic、Elastic、Zipkin などのデプロイされたインスタンスにトレースデータをストリーミングできます。これはすべて、コレクターでの簡単な構成変更です。これを、テレメトリ データのターゲット バックエンドがアプリケーション/サービスから抽象化される抽象化の形式としてのインストルメンテーションと考えてください。

OpenTelemetry リファレンス アーキテクチャ

OpenTelemetry アーキテクチャはいくつかの主要コンポーネントを中心に展開されており、その一部は柔軟に実装できます。主なコンポーネントは次のとおりです。

1. APIとSDK

OpenTelemetry SDK は、開発者がメトリック、トレース、ログを使用してアプリケーションを計測するために使用するライブラリです。 OpenTelemetry API は、アプリケーションが相互に通信する方法を定義し、アプリケーションまたはサービスを計測するために使用されます。これらは通常、開発者が一般的なプログラミング言語 (Ruby、Java、Python など) で使用できるように用意されています。これらは OpenTelemetry 標準の一部であるため、OpenTelemetry と互換性のある任意のバックエンド システムで使用でき、将来の再インストルメンテーションの必要がなくなります。

SDK も言語固有であり、API とエクスポーターの間の橋渡しとして機能します。トレースをサンプリングし、メトリックを集計できます。

2. コレクター

OpenTelemetry Collector は、OpenTelemetry 上で実行してテレメトリ データを受信、処理、エクスポートできるオプションの中間エージェントです。アプリケーションは、OTLP 経由でテレメトリ データを OTel コレクターに送信します。OTel コレクターは、さまざまな可観測性プロバイダーにエクスポートする前に、バッチ処理やレート制限などの中間処理を実行します。

注意: この中間プロキシは便利ですが、インフラストラクチャの層が追加され、スタックが複雑になります。

コレクターの作業は基本的に、テレメトリの処理、フィルタリング、集約、バッチ処理を中心に展開され、開発者にデータの受信、整形、複数のバックエンドへの送信の柔軟性を提供します。現在、主な展開モデルは 2 つあります。

• アプリケーション内のエージェントとして、またはアプリケーションと同じホスト上で、ホストのデータソースとして機能します (デフォルトでは、OpenTelemetry はローカル コレクターが利用可能であると想定します)
• テレメトリデータを受信、エクスポート、処理するためのデータパイプラインゲートウェイとして機能します。

コレクターは、以下に示すように、レシーバー、プロセッサ、エクスポーターの 3 つのコンポーネントで構成されます。

受信機

たとえば、Jaeger、Prometheus などは、コレクター上の特定のポートの呼び出しをリッスンして、アプリケーションからのシグナルをプッシュまたはプルする役割を担っています。これらは gRPC プロトコルと HTTP プロトコルの両方で動作します。特定のシナリオまたはフレームワークのシンクの完全なリストは、GitHub で確認できます。

プロセッサ

加工業者はシンクと輸出業者の間に位置します。エクスポーターを介してバックエンドに到達する前に、データをフィルタリング、フォーマット、強化して整形することができます。一般的な使用例には、機密情報や個人情報を削除するためのデータクレンジング、スパンからメトリックを導出すること、バックエンドに保存するシグナルを決定することなどがあります。

通常、サポートされているプロセッサが多数用意されており、もちろん独自のプロセッサを開発することも可能です。これらは順番に動作するため、構成の順序が重要です。プロセッサは必須ではありませんが、データ ソースによっては推奨されるものもあります。

輸出業者

エクスポータは、1 つ以上の構成済みバックエンドまたは宛先 (Kafka、OTLP など) にデータをプッシュまたはプルできます。動作の仕組みとしては、必要に応じてデータをさまざまな形式に変換し、定義されたエンドポイントに送信します。エクスポーターは、インストルメンテーションとバックエンド構成の間に分離レイヤーを作成するため、ユーザーはコードを再インストルメンテーションせずにバックエンドを切り替えることができます。 HTTP または gRPC プロトコルをサポートします。人気のあるエクスポーターには、Jaeger、Prometheus、Zipkin などがあり、その他にも多数のオプションがあります。

3. オープンテレメトリプロトコル

OpenTelemetry プロトコル (OTLP) は、OpenTelemetry が成功した理由の 1 つです。これは、トレース、メトリック、およびログを送信するためのデータ エンコーディングとトランスポート プロトコルを定義する、非依存のプロトコル仕様です。 SDK からコレクターにデータを送信し、コレクターから選択したバックエンドにデータを送信できます。 Collector 要素を使用すると、適切なレシーバーを構成することでサードパーティのフレームワークから抽象化できます。

現在、OTLP はプロトコル バッファ アーキテクチャ (protobuf) を使用し、gRPC および HTTP1.1 (JSON over HTTP) の送信をサポートしています。

OpenTelemetry はどのように機能しますか?

OTel は、テレメトリ データを収集し、それをターゲット システムにエクスポートするために特別に設計されたプロトコルです。 CNCF プロジェクト自体はオープンソースであるため、最終的な目標は、データ収集を現在よりもさらにシステムに依存しないものにすることです。しかし、このデータはどのように生成されるのでしょうか?

データ ライフ サイクルには、開始から終了まで複数のステップがあります。ソリューションが実行する手順と、その過程で生成されるデータは次のとおりです。

1. APIを使用して構築したコードを計測し、システムコンポーネントに収集するメトリックとその収集方法を伝えます。

2. SDKを使用してデータを収集し、処理およびエクスポートのために転送する

3. データを分解し、サンプリングし、フィルタリングしてノイズやエラーを減らし、マルチソースのコンテキスト化を使用してデータを充実させる

4. データの変換とエクスポート

5. データを所定のバックエンドに移動する前に、時間ベースのバッチでさらにフィルタリングを行う

前述のとおり、OpenTelemetry は CNCF プロジェクトです。市場活動とコミュニティの促進および開発の包括的な評価に基づくと、OpenTelemetry プロジェクトは現在、Kubernetes に次いで 2 番目にアクティブな CNCF プロジェクトです。

OpenTelemetry データベースの詳細については、以下を参照してください。

1. OpenTelemetryの主なコンポーネント

• open-telemetry/opentelemetry-specification - OTel 仕様 (プロトコル、メトリック、トレース、ログ、バゲッジ、およびルート OTel のその他の多くの仕様)、スキーマ、およびセマンティック規則
• open-telemetry/oteps - プロジェクトの機能強化の提案
• open-telemetry/opentelemetry-proto - OTLP の Protobuf 定義

2. OTelコレクターリポジトリ

• open-telemetry/opentelemetry-collector - カスタム コレクター ディストリビューション ビルド用の ocb ツールを含むコア コレクター コード
• open-telemetry/opentelemetry-collector-contrib - コレクター用の Contrib レシーバー、拡張機能、プロセッサ、およびエクスポーター
• open-telemetry/opentelemetry-collector-releases - 上記の 2 つのリポジトリには含まれていないコアおよびコントリビューションのリリースですが、ディストリビューションのマニフェストと Dockerfile を含めてここにあります。
• open-telemetry/opentelemetry-operator - 監視対象アプリケーション ポッドのコレクター サイドカー インジェクションを含む、コレクターを操作するための Kubernetes オペレーター

3. OTeL言語固有のツール

• open-telemetry/opentelemetry-go - Go API と SDK
• open-telemetry/opentelemetry-go-contrib - 計測器やプロパゲーターを含む OTel Go の拡張機能
• open-telemetry/opentelemetry-python - Python API と SDK
• open-telemetry/opentelemetry-python-contrib - OTel Python 拡張機能

OpenTelemetry は、開発するソフトウェアで高いレベルの可観測性を実現する方法を提供する優れたプロジェクトです。 OTel を使用することで、コードを変更することなく最大限の洞察を得て、将来の質問に答えることができます。 OpenTelemetry の素晴らしい世界をぜひ深く探究してみてください。望めば、興奮は続く！