
このブログ記事は、「OpenTelemetryを理解する」シリーズの第2回で、「Understand OpenTelemetry Part 2: Core Components」
の抄訳記事です。第1回では、OpenTelemetryの概要と、OpenTelemetryが計測器の未来を担う理由について説明しました。今回は、OpenTelemetryオープンソースプロジェクトのコアコンポーネントをご紹介します。
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 クイックスタートガイドを確認する。
- New Relic の OpenTelemetry のサンプルを確認する。
- New Relic のネイティブ OTLP エンドポイント プレリリースを試してみる
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のネイティブデータ形式でデータをエクスポートすることができます。
詳細は以下のビデオでご確認ください。
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.