Yoshi Yamaguchi

OTEP-0007: APIから帯域外テレメトリーをレポートする機能を削除する

TL;DR

この節では、このRFCで提案されているすべての変更点を要約します。

  1. 帯域外テレメトリーを報告するためのAPI要件を削除します。
  2. ResourceをSDKに移動します。APIは常に現在のアプリケーションのテレメトリーをレポートするので、計装でResourceを設定する必要はありません。
  3. 新しい API はこの要件なしで設計されるべきです。

動機

現在、APIパッケージは帯域外テレメトリーのレポートをサポートすることを目標に設計されていますが、この要件は多くのトレードオフと不必要な複雑なAPIを強います（たとえば、テレメトリーをテレメトリーのソースと関連付けることを可能にするために、APIパッケージで Resource を公開しなければならない）。

帯域外テレメトリーの報告は、OpenTelemetryエコシステムには必須ですが、これはAPIパッケージを使用する必要のない、いくつかの他のオプションで行うことができます。

  • OpenTelemetryサービスを使えば、OpenTelemetryデータを解析して生成するシンプルなレシーバーを書くことができます。
  • SDK のエクスポーターフレームワークを使えば、ユーザーは OpenTelemetryデータを直接書くことができます。

内部の詳細

以下は、帯域外レポートのサポートに関する決定事項とトレードオフのリストです。

  1. APIに Resource の概念を追加します。

    • メトリクスを作成する例で、ユーザーがリソースを指定できるようにする必要があります。ここを参照してください。 計装を書く開発者は、監視対象のリソースがどこに配置されているか知らないので、適切なリソースを設定する方法がありません。

  2. RFCは SpanData を報告するサポートを削除しました。

    • これは、トレースAPIがAPI経由で設定可能なすべてのフィールドをサポートしなければならないことを要求します。 たとえば、ユーザーが事前に生成した SpanId を設定できるようにする必要がありますが、これは帯域外レポートをサポートしなければ避けられる要件です。

  3. 帯域外スパンのサンプリングロジックは非常に複雑になります。 これらのデータをサンプリングすることが正しくなくなるためです。

  4. テレメトリーのソースとテレメトリーデータの関連付けは非常に簡単になります。 API実装の1つのインスタンスによって生成されたすべてのデータは、ただ1つのアプリケーションに属します。

これは、「1つのAPI実装インスタンス」が、現在のアプリケーションのみに関するテレメトリーをレポートできると言い換えることができます。

リソース（Resource）の変更

このRFCは Resource の概念を削除したり、このインターフェースのAPIを変更することを提案しているのではなく、この概念をSDKレベルに移動することを提案しているだけです。

API（OpenTelemetryの場合はSDK）の各インスタンスは、実行中のアプリケーションを記述する1つの Resource を持ちます。 同じバイナリ内で複数のアプリケーションが動作している場合（Java アプリケーションサーバーなど）、それぞれのアプリケーションは独自の Resource で構成された SDK インスタンスを持つことになります。

関連する問題