New RelicはOpenTelemetryによるTrace、Metric、Logsの標準規格化にも協力しています。今日は「OpenTelemetry: Future-Proofing Your Instrumentation」の抄訳をお伝えします。また、あわせて、OpenTelemetryプロジェクトのドキュメント日本語訳化プロジェクトに関する記事「OpenTelemetry in Japanese」もぜひご覧ください。
開発者としてアプリケーションのパフォーマンスを気にしていると思いますが、それと同時にテレメトリデータを取得するための適切な計装器を見つけることがどれほど困難であるかを知っています。1つの選択肢はプロプライエタリなエージェントを使用することですが、そのエージェントのベンダーにロックインされたくない場合はどうしたらよいでしょうか？
OpenCensus や OpenTracingのようなオープンな標準のいずれかを使用することもできますが、どのオプションがアプリケーションやワークフローに適しているかを判断するのは難しい場合があります。どのオプションを選択するにしても、アプリケーションが時間の経過とともに変化していく中で、ニーズに合わせて拡張し、適応することができなければなりません。しかし、選択する計装器がベンダーやプロジェクト間で共有できる標準に準拠していることも、ますます重要になってきています。
ベンダー中立でオープンな標準が重要です。クラウドネイティブコンピューティングファウンデーション（CNCF）プロジェクトであるOpenTelemetryは、テレメトリデータの収集方法とバックエンドプラットフォームへの送信方法を標準化するために使用できるオープンな仕様を作成しました。
この記事では、OpenTelemetryプロジェクトの仕組みやメリット、開始方法など、OpenTelemetryプロジェクトについて詳しく説明します。
OpenTelemetryとは？
OpenTelemetryは、OpenTracingプロジェクトとOpenCensusプロジェクトを統合して誕生しました。OpenTelemetry は、テレメトリデータの収集および転送方法を標準化する API およびライブラリの単一セットを提供します。OpenTelemetryは計測器のための安全でベンダー中立な仕様を提供しており、New Relicのような異なるバックエンドにデータを送信できるようになっています。
OpenTelemetryプロジェクトは以下のコンポーネントから構成されています。
- すべてのプロジェクト間で一貫性を持たせるための仕様
- 仕様に基づいたインターフェースや実装を含むAPI
- Java、Python、Go、Erlangなどの言語に特化して作成されたSDK（APIの参照実装）
- お好みのバックエンドへのデータ送信を可能にするExporter
- 処理とエクスポートのためのベンダーに依存しない実装を提供するCollector
(以下のアーキテクチャセクションでは、これらのコンポーネントについて詳しく説明します)
OpenTelemetryのメリット
OpenTracingとOpenCensusを単一のオープンスタンダードに統合することで、OpenTelemetryは以下のメリットを提供します。
- 選択の簡素化。どちらか一方の標準と他方の標準のどちらかに決める必要がありません。現在OpenTracingまたはOpenCensus 使用していますか？ご心配いりません。OpenTelemetry は両方のプロジェクトの下位互換性を提供しています。
- クロスプラットフォーム。OpenTelemetry は様々な言語とバックエンドをサポートしています。OpenTelemetry は、既存の計測器に変更を加えることなく、テレメトリーをキャプチャしてバックエンドに送信するためのベンダー中立な蒲黄法を提供しています。この種の自由を求める開発者を満足させる重要なプロジェクトです。
- 合理化された観測性。OpenTelemetryが言うように、「効果的な観測性は高品質の遠隔測定を必要」とします。一つの規格に対応してテストする方がはるかに簡単なので、より多くのベンダーがOpenTelemetryに移行することを期待しています。
すなわち、意思決定の煩雑さに陥ることなく、信頼性の高い素晴らしいソリューションベースのソフトウェアを構築することに力を注ぐことができます。そして、それがすべてなのです。
OpenTelemetryの使用
OpenTelemetry API と SDK には、多くのクイックスタートガイドとドキュメントが付属しているので、データのインジェスト方法をすぐに学ぶことができます。例えば、Java用のクイックスタートガイドでは、Tracerの取得方法、Spanの作成、Attributesの追加、様々なSpanにまたがるContextの伝搬方法が概説されています。
また、一般的なユースケースの例も掲載されています。これらは、HTTP/gRPC サーバやクライアント、データベースコネクタなどを計装する方法を示す実用的な作業コードを提供します。
OpenTelemetry Trace API を使用してアプリケーションを計装した後は、OpenTelemetry Registry内の事前に構築ずみのいずれかのExporterを使用して、New Relic やその他のバックエンドのようなオブザーバビリティプラットフォームにTraceデータを送信することができます。
MetricsとLogsの仕様はまだ開発段階にありますが、一度発表されれば、OpenTelemetryの主な目標である、ライブラリやフレームワークにすべての組み込みテレメトリデータタイプがあることを保証し、開発者が計測をしなくてもテレメトリデータを取り込むことができるようにするための重要な役割を果たすことになります。
OpenTelemetryのアーキテクチャコンポーネント
OpenTelemetry はベンダや可観測性バックエンドのためのクロスランゲージフレームワークであることを意図しているので、非常に柔軟で拡張性がありますが、同時に非常に複雑なものでもあります。OpenTelemetryのデフォルトの実装のアーキテクチャは3つのコンポーネントに分かれています。
- OpenTelemetry API
- OpenTelemetry SDK。これは以下から構成されています。
- Tracer パイプライン
- Meterパイプライン
- 共有Contextレイヤー
- Collector
アーキテクチャの各コンポーネントを見てみましょう。
OpenTelemetry API
アプリケーション開発者は Open Telemetry API を使用してコードの計装を行い、ライブラリの作者はそれを使用して直接ライブラリに計装を書き込んでいます。このAPIでは、運用上の関心事や、ベンダーのバックエンドにデータをどのように送信するかについては触れていません。
APIは4つの部分に分けることができます。
- Tracer API
- Metrics API
- Context API
- セマンティック規約のセット
Tracer API
Tracer API は、Trace内の作業の連続したSegmentを表す、名前付きの時間計測された処理であるSpanの生成をサポートしています。SpanにはtraceIdを割り当てることができ、オプションでタイムスタンプ付きのEventを付加することもできます。TracerはSpanに名前とバージョンを付けます。データを見るときに、Tracerに関連付けられた名前とバージョンを使用してSpanを生成した計装器のライブラリを追跡することができます。
Metric API
Metric API は、CountersやObserversなど、さまざまなタイプのMetric計測器へのアクセスを提供します。Countersを使用して数を数えられます。Observersを使用して離散的な時点での値を計測できます。例えば、現在のCPU負荷やディスク上の空きバイト数など、Spanのコンテキスト内では発生しない値を「観測」するためにObserversを使用します。可能なMetricユースケースの全範囲をカバーする計測器のリストについては、仕様書を参照してください。
Context API
Context API は、W3C Trace Context、Zipkin B3 ヘッダ、または New Relic 分散トレースヘッダのようなContext情報を、同じ「コンテキスト」を使用するSpanやTraceに追加します。さらに、この API を使用することで、システム内でのSpanの伝播方法を追跡することができます。ContextはTraceがあるプロセスから次のプロセスに伝搬する際に更新されます。Metricの計測器は常に現在のContextにアクセスできます。
セマンティック規約
最後に、OpenTelemetry APIには、Span、Attributes、エラーをSpan(およびその他のもの)に関連付けるためのガイドラインやルールを含むセマンティック規約が含まれています。これをAPI仕様にすることで、OpenTelemetryプロジェクトは、作者や言語に関係なく、すべての計測器に同じセマンティック情報が含まれていることを保証します。これは、すべてのユーザーに一貫したAPMエクスペリエンスを提供しようとしているベンダーにとって非常に価値のあるものです。
OpenTelemetry Architecture Overview
OpenTelemetry SDK
次に、OpenTelemetry SDK は OpenTelemetry API の実装です。このSDKは大まかに3つの部分で構成されており、先ほど説明したAPIと同じく、Tracer、Meter、そしてそれらすべてを結びつける共有Contextレイヤーです。
理想的には、SDKは標準的なユースケースの99%を満たすべきですが、必要に応じてSDKをカスタマイズすることができます。例えば、Tracerパイプラインの実装では、コアの実装が共有コンテキストレイヤーと相互作用する方法以外にも、何でもカスタマイズすることができます。例えば、Tracerパイプラインの実装では、使用するサンプリングアルゴリズムをカスタマイズすることができます。
Tracerパイプライン
SDK を構成する際には、1 つ以上のSpanProcessorをTracerパイプラインの実装に関連付けます。SpanProcessorはSpanのライフサイクルを監視し、適切な場合にはSpanをSpanExporterに配信します。SDKに組み込まれているのは、完成したSpanを一度に一つずつExporterに直接転送するシンプルなSpanProcessorです。
このSDKには、完成したSpanを設定可能な間隔でバッチ転送する処理の実装も含まれています。しかし、SpanProcessorの実装はプラグインを受け入れるので、独自の実装を行い、カスタム動作を割り当てることができます。例えば、テレメトリバックエンドが「進行中」のスパンの表示をサポートしている場合は、Spanの状態が変化するたびにエクスポート用のSpanを送信するSpanProcessorの実装を作成することができます。
Tracerパイプラインの終端にはSpanExporterがあります。Exporterの仕事は簡単です。すなわち、Spanを OpenTelemetryでの表現からテレメトリバックエンドが必要とするものに変換し、そのバックエンドに送ることです。カスタムSpanExporterを提供することは、テレメトリベンダーがOpenTelemetryエコシステムに参加する最も簡単な方法です。
Meterパイプライン
Meterパイプラインは、MetricsがSpanよりも複雑なように、Tracerパイプラインよりもかなり複雑です。 以下の説明は、SDK の Java 実装に基づいており、言語によって異なる場合があります。
MeterパイプラインはCountersやObserversを含む様々なタイプのMetrics計測器を生成し維持します。計測器の各インスタンスは、何らかの方法で集約される必要があります。デフォルトでは、Countersは値を合計することで集約され、Observersは記録された最新の値を取ることで集約されます。すべての計測器タイプにはデフォルトの集約が定義されています。
(この記事を書いている時点では、メトリクス計測器のカスタム集約を構成する機能はまだ提案段階にあります)
Meterパイプラインの実装は、現在のところ言語によって異なりますが、すべての場合においてMetricsの集約はMetricExporterに配信されます。Spanの場合と同様に、ベンダーは、Metricsの集約によって生成された集約データをテレメトリバックエンドが必要とするタイプに変換するために、独自のExporterを提供することができます。
OpenTelemetryは2つのスタイルのExporterをサポートしています。「push」ベースのExporterでは、エクスポータは一定時間ごとにバックエンドにデータを送信します。New Relicはpushベースのバックエンドの例で、Prometheusはpullベースのバックエンドです。
共有Contextレイヤー
共有Contextレイヤーは、TracerパイプラインとMeterパイプラインの間にあり、実行中のSpanのContext内ですべての非Observer Metricを記録できるようにします。Propagatorsを使用してContextをカスタマイズすることができ、システムの内外でSpanのContextをPropagatorで伝搬します。前述のように、すべての OpenTelemetry SDK の実装は W3C Trace Context 仕様の実装を提供していますが、オプションで Zipkin B3 伝搬やその他の伝搬を含めることができます。
Collector
OpenTelemetry Collector はスタンドアロンのサービスで、Zipkin、Jaeger、OpenCensus など様々なソースからMetricsとSpansを注入することができます。CollectorはSpanのtailベースのサンプリングを行うことができ、New Relicを含む多数のベンダーやオープンソースのテレメトリシステムにSpansとMetricsをエクスポートすることができます。
OpenTelemetry のアーキテクチャの詳細については、完全な仕様書をご覧ください。
早速OpenTelemetryの探索し始めよう！
現在、OpenTelemetryはベータ段階にあります。今は、このプロジェクトで何ができるのかを探り始める理想的な時期です。
この基本的なJavaの例では、MetricsやTracesをNew Relicのようなバックエンドに送信するためのコードを作成する方法を説明しています。
New Relicが関わっている他のオープンソースプロジェクトの詳細については、New Relic Open Sourceをご覧ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
