Yoshi Yamaguchi

概要

この記事は英語の原文を日本語に翻訳したものです。原文: https://opentelemetry.io/docs/specs/otel/overview/

翻訳元: open-telemetry/opentelemetry-specification v1.60.0（コミット 29ae8c7）

このドキュメントはOpenTelemetryプロジェクトの概要を示し、重要な基本用語を定義します。

その他の用語定義は用語集にあります。

OpenTelemetryクライアントのアーキテクチャ

Cross cutting concerns

もっとも高いアーキテクチャレベルでは、OpenTelemetryクライアントはシグナルを軸に構成されています。各シグナルは特化した形のオブザーバビリティを提供します。例えば、トレーシング、メトリクス、バゲージは3つの独立したシグナルです。シグナルはコンテキスト伝搬という共通のサブシステムを共有しますが、それぞれ独立して機能します。

各シグナルは、ソフトウェアが自身を記述する仕組みを提供します。Webフレームワークやデータベースクライアントといったコードベースは、自身を記述するために各種のシグナルに依存します。そうしてOpenTelemetryの計装コードは、そのコードベース内の他のコードに混ぜ込まれます。これによってOpenTelemetryはcross-cutting concern（横断的関心事）になります。cross-cutting concernとは、価値を提供するために多くの他のソフトウェアに混ぜ込まれるソフトウェアの一片です。cross-cutting concernは、その性質上、関心の分離というコアな設計原則に反します。そのため、OpenTelemetryクライアントの設計では、これらの横断的関心事のAPIに依存するコードベースに問題を生じさせないよう、特別な配慮と注意が必要です。

OpenTelemetryクライアントは、各シグナルのうちcross-cutting concernとしてインポートしなければならない部分と、独立して管理できる部分とを分離するように設計されています。また、OpenTelemetryクライアントは拡張可能なフレームワークとしても設計されています。これらの目標を達成するため、各シグナルはAPI、SDK、セマンティック規約、Contribという4種類のパッケージから構成されます。

API

APIパッケージは、計装に使われるcross-cuttingな公開インターフェースから構成されます。サードパーティのライブラリやアプリケーションコードにインポートされるOpenTelemetryクライアントの部分は、すべてAPIの一部とみなされます。

SDK

SDKは、OpenTelemetryプロジェクトが提供するAPIの実装です。アプリケーション内では、SDKはアプリケーション所有者によってインストールおよび管理されます。SDKには、cross-cutting concernではないためAPIパッケージの一部とはみなされない追加の公開インターフェースが含まれることに注意してください。これらの公開インターフェースはコンストラクタとプラグインインターフェースとして定義されます。アプリケーション所有者はSDKコンストラクタを使い、プラグイン作者はSDKプラグインインターフェースを使います。計装作者は、いかなる種類のSDKパッケージも直接参照してはならず（MUST NOT）、APIのみを参照するものとします。

セマンティック規約

セマンティック規約は、アプリケーションが使用する一般的な概念、プロトコル、操作を記述するキーと値を定義します。

セマンティック規約は現在、独自のリポジトリに置かれています。 https://github.com/open-telemetry/semantic-conventions

CollectorとクライアントライブラリはいずれもSHOULD、セマンティック規約のキーと列挙値を定数（あるいは言語に応じた等価な形式）へ自動生成するものとします。生成された値は、セマンティック規約が安定するまで、安定版パッケージで配布すべきではありません。YAMLファイルは生成の際の信頼できる情報源としてMUST使用されるものとします。各言語の実装はSHOULD、コードジェネレーターに言語固有のサポートを提供するものとします。

さらに、仕様書が要求する属性はこちらに一覧化されます。

コアパッケージ

コアパッケージは追加のパッケージ種別ではありません。この用語は、これらのカテゴリ（APIパッケージ、SDKパッケージ、そしてエクスポーターやプロパゲーターなどのプラグインパッケージ）にわたって仕様が定義するコンポーネントを実装するOpenTelemetryクライアントパッケージを指します。

コアパッケージはOpenTelemetryのSIGによって保守され、オプションであるContribパッケージとは区別されます。この用語は仕様が定義するデリバラブルを表すものであり、言語実装ごとの特定のリポジトリ、パッケージ、モジュール、アーティファクト、リリースバンドルのレイアウトを規定するものではありません。

Contribパッケージ

OpenTelemetryプロジェクトは、最新のWebサービスをオブザーブする上で重要と判断された人気のOSSプロジェクトとの統合を保守しています。API統合の例としては、Webフレームワーク、データベースクライアント、メッセージキュー向けの計装があります。SDK統合の例としては、人気の分析ツールやテレメトリーストレージシステムへのテレメトリーのエクスポートを行うプラグインがあります。

一部のプラグイン、例えばOTLPエクスポーターやTraceContextプロパゲーターは、OpenTelemetryの仕様によって定義されていることに注意してください。これらのプラグインはコアパッケージと呼ばれます。

SDKとは別にオプションで提供されるプラグインや計装パッケージはContribパッケージと呼ばれます。API ContribはAPIのみに依存するパッケージを指し、SDK ContribはSDKにも依存するパッケージを指します。

Contribという用語は、OpenTelemetryプロジェクトが保守するプラグインと計装の集合のみを指し、他所でホストされるサードパーティのプラグインを指すものではありません。

バージョニングと安定性

OpenTelemetryは安定性と後方互換性を重視しています。詳細はバージョニングと安定性のガイドを参照してください。

トレーシングシグナル

分散トレースとは、単一の論理的な操作の結果として発生し、アプリケーションの様々なコンポーネントを横断して集約された、イベントの集合です。分散トレースには、プロセス、ネットワーク、セキュリティの境界を越えるイベントが含まれます。分散トレースは、あるサイトで何かの操作を開始するためにボタンが押されたときに開始される場合があります。この例では、トレースはこのボタン押下によって開始された一連のリクエストを処理する、下流のサービス間で行われた呼び出しを表します。

トレース

OpenTelemetryにおけるトレースは、そのスパンによって暗黙的に定義されます。特に、トレースはスパンの有向非巡回グラフ（DAG）と考えることができ、スパン間のエッジは親子関係として定義されます。

例えば、以下は6つのスパンからなるトレースの例です。

Causal relationships between Spans in a single Trace

        [Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C is a `child` of Span A)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F]

トレースは、下図のように時間軸で可視化するとわかりやすい場合もあります。

Temporal relationships between Spans in a single Trace

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time

 [Span A···················································]
   [Span B··········································]
      [Span D······································]
    [Span C····················································]
         [Span E·······]        [Span F··]

スパン

スパンは、トランザクション内の1つの操作を表します。各スパンは以下の状態をカプセル化します。

  • 操作名
  • 開始と終了のタイムスタンプ
  • 属性: キーと値のペアのリスト
  • ゼロ個以上のイベントの集合。各イベント自体は（タイムスタンプ、名前、属性）のタプルです。名前は文字列でなければなりません。
  • 親のスパン識別子
  • 因果関係を持つゼロ個以上のスパンへのリンク（それらの関連するスパンのSpanContextを介する）
  • スパンを参照するために必要なSpanContext情報。以下を参照。

SpanContext

トレース内でスパンを識別するすべての情報を表し、子スパンへ、そしてプロセス境界を越えてMUST伝搬されるものとします。SpanContextには、親から子のスパンへ伝搬されるトレース識別子と各種のオプションが含まれます。

  • TraceIdはトレースの識別子です。16バイトのランダムに生成されたバイト列として作られるため、実用上十分な確率で世界的に一意です。TraceIdは、すべてのプロセスにわたって、特定のトレースに属するすべてのスパンをグループ化するために使われます。
  • SpanIdはスパンの識別子です。8バイトのランダムに生成されたバイト列として作られるため、実用上十分な確率で全体的に一意です。子スパンに渡されると、この識別子は子スパンの親スパンIDになります。
  • TraceFlagsはトレースのオプションを表します。1バイト（ビットマップ）として表現されます。
    • サンプリングビット - トレースがサンプリングされているかどうかを表すビット（マスク 0x1）。
  • Tracestateは、トレーシングシステム固有のコンテキストをキーと値のペアのリストで運びます。Tracestateは、異なるベンダーが追加の情報を伝搬し、それぞれのレガシーなID形式と相互運用できるようにします。詳細はこちらを参照してください。

スパン間のリンク

スパンは、因果関係を持つゼロ個以上の他のスパン（SpanContextによって定義される）にリンクできます。リンクは、単一のトレース内のスパンにも、異なるトレースをまたいだスパンにも張れます。リンクは、バッチ処理された操作を表現するために使うことができます。この場合、スパンはバッチ内で処理されている個々の受信項目をそれぞれ表す複数の起点となるスパンによって開始されます。

リンクを使う別の例として、起点となるトレースとそれに続くトレースの関係を宣言する用途があります。これは、トレースがサービスの信頼境界に入り、サービスのポリシーが受信したトレースコンテキストを信頼するのではなく新しいトレースの生成を要求する場合に使えます。この新しくリンクされたトレースは、複数の高速な受信リクエストの1つによって開始された、長時間実行される非同期のデータ処理操作を表す場合もあります。

scatter/gather（fork/joinとも呼ばれる）パターンを使う場合、ルート操作は複数の下流の処理操作を開始し、それらはすべて単一のスパンに集約されます。この最後のスパンは、それが集約する多くの操作にリンクします。それらはすべて同一のトレースからのスパンです。そしてスパンのParentフィールドと似ています。しかし、このシナリオではスパンの親を設定しないことが推奨されます。なぜなら、意味的にはParentフィールドは単一の親というシナリオを表し、また多くの場合親スパンは子スパンを完全に包含するためです。scatter/gatherとバッチのシナリオでは、これは当てはまりません。

メトリックシグナル

OpenTelemetryは、生の測定値、または事前に定義された集約と属性の集合を伴うメトリクスを記録できます。

OpenTelemetry APIを使って生の測定値を記録することで、エンドユーザーは特定のメトリクスに対する集約アルゴリズムを選択する柔軟性を得られます。この機能は、gRPCのようなクライアントライブラリで特に有用です。gRPCでは、“server_latency"や"received_bytes"のような生の測定値を記録できます。エンドユーザーは、これらの生の測定値に対する集約方法を、単純な平均から、より複雑なヒストグラム計算まで、自分の裁量で決められます。

生の測定値の記録

OpenTelemetry APIを使って生の測定値を記録する際に関わる主要なコンポーネントは、Measurement、Instrument、Meterです。MeterはMeterProviderから取得され、Instrumentを作成するために使われます。Instrumentは、続いて測定値を捕捉する責務を持ちます。

+------------------+
| MeterProvider    |                 +-----------------+             +--------------+
|   Meter A        | Measurements... |                 | Metrics...  |              |
|     Instrument X +-----------------> In-memory state +-------------> MetricReader |
|     Instrument Y |                 |                 |             |              |
|   Meter B        |                 +-----------------+             +--------------+
|     Instrument Z |
|     ...          |                 +-----------------+             +--------------+
|     ...          | Measurements... |                 | Metrics...  |              |
|     ...          +-----------------> In-memory state +-------------> MetricReader |
|     ...          |                 |                 |             |              |
|     ...          |                 +-----------------+             +--------------+
+------------------+

Instrument

InstrumentはMeasurementを報告するために使われ、名前、種別、説明、値の単位によって識別されます。

特定の用途向けに複数の種類のメトリックInstrumentがあります。値を増分するカウンター、現在の値を捕捉するゲージ、測定値の分布を捕捉するヒストグラムなどです。Instrumentは同期的にすることもできます。これはアプリケーションロジックによってインラインで呼び出されることを意味します。あるいは非同期にすることもできます。この場合、ユーザーはコールバック関数を登録し、SDKによって必要に応じて呼び出されます。

メトリクスのデータモデルとSDK

メトリクスのデータモデルはこちらで規定されており、metrics.protoに基づいています。このデータモデルは3つのセマンティクスを定義します。APIが使うEventモデル、SDKとOTLPが使うin-flightデータモデル、そしてエクスポーターがin-flightモデルをどのように解釈すべきかを示すTimeSeriesモデルです。

エクスポーターごとに、異なる能力（例えばどのデータ型をサポートするか）と異なる制約（例えば属性キーにどの文字を使えるか）があります。メトリクスは、どこでもサポートされる最小公倍数ではなく、可能なことすべての上位集合となることを意図しています。すべてのエクスポーターは、OpenTelemetry SDKで定義されたMetric Producerインターフェースを介してメトリクスのデータモデルからデータを消費します。

このため、メトリクスはデータ（例えばキーで使える文字）に対する制約を最小限にとどめており、メトリクスを扱うコードは検証やサニタイズを避けるべきです。代わりに、データをバックエンドへ渡し、バックエンドに検証を任せて、バックエンドからのエラーを呼び出し元に返すようにします。

詳細はメトリクスのデータモデル仕様を参照してください。

View

Viewは、Instrumentからのデータをどのように処理、集約、エクスポートするかを指定する設定です。MeterProviderを通じて設定できます。Viewにより、既定の収集動作を超えて、特定の集約、変換、フィルタリングをメトリクスデータに適用できます。

ログシグナル

データモデル

Log Data Modelは、OpenTelemetryがログとイベントをどのように理解するかを定義します。

バゲージシグナル

トレースの伝搬に加えて、OpenTelemetryはBaggageと呼ばれる名前と値のペアを伝搬するためのシンプルな仕組みを提供します。Baggageは、あるサービスで発生したオブザーバビリティイベントに、同一トランザクション内の先行するサービスから提供された属性でインデックスを付けることを意図しています。これは、これらのイベント間の因果関係を確立する助けになります。

Baggageは他のcross-cutting concernを試作するために使えますが、この仕組みは主にOpenTelemetryのオブザーバビリティシステムのための値を伝えることを意図しています。

これらの値はBaggageから取り出して、メトリクスの追加の属性や、ログとトレースの追加のコンテキストとして使えます。いくつかの例を示します。

  • Webサービスは、どのサービスがリクエストを送信したかに関するコンテキストを含めることで利益を得られる
  • SaaSプロバイダーは、リクエストの責任を負うAPIユーザーやトークンに関するコンテキストを含められる
  • 特定のブラウザバージョンが画像処理サービスの障害と関連していることを判定できる

OpenTracingとの後方互換性のため、OpenTracingブリッジを使用する際、BaggageはBaggageとして伝搬されます。異なる基準を持つ新たな関心事は、W3Cのエンコーディング形式を活かしつつも新しいHTTPヘッダーでデータを分散トレース全体に伝えるという、新たなcross-cutting concernの作成を検討すべきです。

リソース

Resourceは、テレメトリーが記録される対象のエンティティに関する情報を捕捉します。例えば、Kubernetesのコンテナから公開されるメトリクスは、クラスタ、名前空間、Pod、コンテナ名を指定するリソースに結び付けられます。

Resourceは、エンティティ識別の階層全体を捕捉することがあります。クラウド上のホストと、プロセス内で実行されている特定のコンテナやアプリケーションを記述する場合もあります。

プロセス識別情報の一部は、OpenTelemetry SDKによって自動的にテレメトリーに関連付けられることがあることに注意してください。

コンテキスト伝搬

トレースやメトリクスといったOpenTelemetryのすべてのcross-cutting concernは、分散トランザクションの寿命にわたって状態を保存しデータにアクセスするための、基盤となるContextの仕組みを共有します。

詳細はContextを参照してください。

プロパゲーター

OpenTelemetryはPropagatorを使って、Span（通常はSpanContext部分のみ）やBaggageといったcross-cutting concernの値をシリアライズおよびデシリアライズします。異なるPropagatorの種類は、特定のトランスポートによって課される制約を定義し、あるデータ型に結び付けられます。

Propagators APIは現在1つのPropagatorの種類を定義しています。

  • TextMapPropagatorは、値をキャリアに対してテキストとして注入し、また抽出します。

Collector

OpenTelemetry Collectorは、OpenTelemetryまたは他の監視・トレーシングライブラリ（Jaeger、Prometheusなど）で計装されたプロセスからトレース、メトリクス、そして将来的には他のテレメトリーデータ（ログなど）を収集し、集約とスマートサンプリングを行い、トレースとメトリクスを1つ以上の監視・トレーシングのバックエンドへエクスポートする一連のコンポーネントです。Collectorは、収集したテレメトリーを（追加の属性を付与したり個人情報を除去したりして）拡充・変換できるようにします。

OpenTelemetry Collectorには主に2つの動作モードがあります。Agent（アプリケーションと一緒にローカルで動くデーモン）とCollector（スタンドアロンで動く常駐サービス）です。

詳細はOpenTelemetry Collectorの長期的なビジョンを参照してください。

Instrumentation Library

このプロジェクトの発想は、すべてのライブラリとアプリケーションにOpenTelemetry APIを直接呼び出させることで、標準で（out of the box）オブザーバブルにすることです。しかし、多くのライブラリにはそのような統合がないため、そうした呼び出しを注入する別のライブラリが必要になります。これには、インターフェースのラッピング、ライブラリ固有のコールバックへの登録、既存のテレメトリーのOpenTelemetryモデルへの変換といった仕組みが使われます。

あるライブラリに対してOpenTelemetryによるオブザーバビリティを可能にするライブラリは、Instrumentation Libraryと呼ばれます。

Instrumentation Libraryは、計装対象のライブラリの命名規則に従って名付けるべきです（例えば、Webフレームワークであれば’middleware’とする）。

OpenTelemetryのリポジトリでホストされる計装については、“opentelemetry-instrumentation"というプレフィックスに、計装対象のライブラリ名自体を続けることが推奨されます。例を示します。

  • opentelemetry-instrumentation-flask（Python）
  • @opentelemetry/instrumentation-grpc（JavaScript）

OpenTelemetryでホストされていないInstrumentation Libraryは、OpenTelemetryでホストされているパッケージとの名前の衝突を避けるべきです。例えば、自社名やプロジェクト名を計装パッケージ名にプレフィックスとして付けることが考えられます。

  • {company}-opentelemetry-instrumentation-{component}（Python）
  • @{company}/opentelemetry-instrumentation-{component}（JavaScript）

詳細はInstrumentation Libraryを参照してください。