OpenTelemetryを理解する 第2回: コアのコンポーネント

OpenTelemetryプロジェクトは、アプリケーションプログラミングインターフェース（API）、ソフトウェア開発キット（SDK）、ツール、テレメトリーデータ（メトリクス、ログ、トレース）のデータモデルの仕様、およびデータのセマンティック規約から構成されています。また、一元化されたコレクターと、テレメトリーデータをさまざまなバックエンドプラットフォームに送信するためのエクスポーターも定義されているので、どのオブザーバビリティプラットフォームに送信するか選ぶことができ、好きなプラットフォームでパフォーマンスを可視化することができます。これらのコンポーネントがどのように連携しているかを理解するために、アーキテクチャ図を見て、各コンポーネントの詳細を見てみましょう。

OpenTelemetryのアーキテクチャ

このビデオツアーでは、API、SDK、OpenTelemetryプロトコル、そして様々なプログラミング言語での作業を可能にするセマンティックな規約など、OpenTelemetryのコンセプトとコンポーネントを順に説明しています。それぞれの概要については、以下のセクションをお読みください。すべては、OpenTelemetery APIがSDKでの実装から切り離されていることから始まります。これにより、ソフトウェアスタックにOpenTelemeteryを採用しなくても、OpenTelemetry APIだけを利用することができます。

OpenTelemetry API

OpenTelemetry API は、アプリケーション開発者やライブラリ作成者が自分のコードをインスツルメンテーションして、トレース、メトリックス、ログといった遠隔測定データを生成するために使用します。OpenTelemetryは、一般的なプログラミング言語ごとにAPIの実装を用意しており、実装（SDK）から完全に切り離されています。API の実装は最小限に抑えられていますので、ソフトウェアスタックに OpenTelemetry を採用しなくても OpenTelemetry API のみを利用することができます。

OpenTelemetry SDK

OpenTelemetry SDKは、OpenTelemetry APIの実装です。APIと同様に、一般的なプログラミング言語用の実装が用意されています。アプリケーション開発者は、このSDKを使ってOpenTelemetryを自分の環境に合わせて設定します。

OpenTelemetry プロトコル (OTLP)

OTLP仕様は、テレメトリーデータのエンコーディングと、クライアントとサーバー間のデータ交換に使用されるプロトコルを定義しています。仕様書では、オープンソースのgRPCプロトコルとHTTP 1.1トランスポート上でのOTLPの実装方法を定義し、ペイロードに使用されるProtocol Buffersのスキーマを規定しています。

OpenTelemetry セマンティック規約

OpenTelemetryは、ソフトウェアが実行する一般的な操作のためのセマンティックな規約を定義しています。例えば、HTTPやデータベース、リソースの呼び出しは、どのプラットフォームや言語を使用しているかに関わらず一貫しています。 

例えば、Pythonアプリが.NETアプリを呼び出す場合、これらのアプリケーションはどちらもhttp.method属性をはじめとするHTTPの規約に準拠しているので安心です。ここで、http.method属性は、呼び出しメソッド（例えば、get、post、put）を特定するために使用されます。これらはPythonと.NETのアプリケーションで統一されています。

リソースは主に、サービス名、Kubernetesノード、ポッド名など、アプリケーションが動作している環境を記述するための属性です。

The OpenTelemetry Collector

さて、APIとSDKの仕組みがわかったところで、国際空港の税関のような場所を考えてみましょう。すなわち、ここでは、すべてのテレメトリデータがさまざまなテレメトリツールからオブザーバビリティプラットフォームへ送信されるために通過しています。OpenTelemetry コレクターはまさに税関です。データを送信するツールに関係なくテレメトリーデータを受信し、処理し、エクスポートする中央リポジトリとしての役割を果たす実装です。このビデオでは、OpenTelemetry コレクターのアーキテクチャと、それを環境に導入する方法について説明します。

OpenTelemetry コレクターは、テレメトリデータの一般的な多くのオープンフォーマットをサポートしており、3つの主要コンポーネントから構成されています。

• レシーバー にはOpenTelemetryネイティブフォーマットをサポートするOTLレシーバーやトレースデータ向けのJaegarやメトリクスデータ向けのPrometheusなどさまざまなよく使われているオープンソースフォーマットをサポートするレシーバーがあります。
• プロセッサー はフィルタリングやサンプリングおよびエンリッチングなどのテレメトリーデータ処理を一元化された場所で行うためのパイプライン処理を、それぞれのデータソース（メトリクス、トレース、ログ）向けに構成できます。
• エクスポーター はNew Relicなどのバックエンドのオブザーバビリティプラットフォームにデータを送信します。

OpenTelemetryのコレクターはゲートウェイもしくはエージェントとして配置できます。

• ゲートウェイとして配置する場合、すべてのサービスはテレメトリーデータを中央のゲートウェイに報告し、ゲートウェイはバックエンドの可観測性ツールにエクスポートします。
• エージェントとして配置する場合は、データを報告するサービスと同じホスト上で実行します。  この場合、コレクターはホストに関するテレメトリデータを収集し、インフラストラクチャエージェントとしても機能することができます。  エージェントとして配置されたコレクターは、データを直接バックエンドに送信したり、別のコレクターに送信してからバックエンドにエクスポートしたりすることができます。

OpenTelemetry exporters and OTLP

テレメトリーデータは送信先のバックエンドが理解できる言語に翻訳してから送信する必要があります。エクスポーターは、テレメトリデータをバックエンドの可観測性プラットフォームが理解できる特定のフォーマットに翻訳することを可能にしています。また、システムへのデータの送信も可能です。インプロセスエクスポーターを使用してサービスから直接データをエクスポートすることもできます。あるいは、コレクターを介してプロキシとして送信もできるため、サービスを再デプロイすることなく新しいエクスポーターを再デプロイすることもできます。

New Relic でのネイティブ OTLPエンドポイントのプレリリースプログラムに参加するには、お使いの環境で OpenTelemetry コレクターを実行し、コレクター用の OTLP エクスポーターを使用するように設定します。すると、New RelicのネイティブOTLPエンドポイントに、OpenTelemetryのネイティブデータ形式でデータをエクスポートすることができます。
詳細は以下のビデオでご確認ください。