> Source: https://www.ymotongpoo.com/works/oteps/metrics/otep-0131/


# OTEP-0131: OTLPエクスポーターの設定可能なエクスポート動作

OTLPエクスポーターにおいて設定可能なエクスポート動作のサポートを追加します。

必要とされる動作は、1) デフォルトでは開始時刻からの累積値をエクスポートすること、2) 設定に応じて収集間隔ごとのデルタ値をエクスポートすることの2つです。

## 動機 {#motivation}

1. **エクスポート動作は設定可能であるべき**。 Prometheus、Cortex、および Prometheus remote write API からデータを取り込むその他の Prometheus 時系列対応バックエンドなどのメトリクスバックエンドは、累積メトリクスと加算的なメトリクスについて、収集間隔ごとの累積値を必要とします。
   Collector を使って SDK が生成したメトリクスをエクスポートするためには、SDK からの入力値は累積値である必要があります。
   これに対して、Statsd のようなバックエンドは、収集間隔ごとにデルタ値を期待することに注意してください。
   異なるバックエンドの要件をサポートするためには、OTLP のメトリクスエクスポート動作は設定可能である必要があり、デフォルトでは累積値をエクスポートします。
   [#731](https://github.com/open-telemetry/opentelemetry-specification/issues/731) での議論を参照してください。
2. **累積エクスポートはより信頼性が高いため、デフォルトの動作であるべき**。 累積エクスポートは、UpDownCounter のデルタ値が欠落する問題にも対処します。
   UpDownCounter メトリクスの最終的な消費者は、ほとんどの場合、累積値に関心を持ちます。
   Metrics SDK がデルタ値をエクスポートし、消費者側で累積値を集計させるようにすると、転送中に失われたデルタ値はすべて、最終的な値の不正確さにつながります。
   この損失は、アラートが発報されるかどうかの条件に影響を与える可能性があります。
   一方で、累積値をエクスポートすれば、失われるのは解像度のみであることが保証され、最終的な消費者が受け取る値は最終的には正しくなります。
    1. *注:* [Metrics SIG](https://docs.google.com/document/d/1LfDVyBJlIewwm3a0JtDtEjkusZjzQE3IAix8b0Fxy3Y/edit#heading=h.fxqkpi2ya3br) の *7月23日および7月30日のミーティングでは、累積エクスポート動作の方がより信頼性が高いという結論に至りました。*
       たとえば、Bogdan Drutu は [#725](https://github.com/open-telemetry/opentelemetry-specification/issues/725) で次のように述べています。「UpdownCounter インストルメントのデルタ値をエクスポートする場合、エクスポートパイプラインはアラートにとっての単一障害点になります。ドロップされた『デルタ』は、メトリクスの『現在』の値に未定義な形で影響を及ぼします」

## 解説 {#explanation}

累積値を使う Prometheus バックエンドと、デルタ値を使うその他のバックエンドの両方をサポートするためには、SDK は設定可能であり、デフォルトで累積値を、そしてエクスポート用にデルタ値も扱える OTLP エクスポーターをサポートする必要があります。
これが意味するのは、OTLP メトリクスプロトコルが累積とデルタの両方のレポート戦略をサポートするべきだということです。

ユーザーは、OTLP エクスポーターについてこの設定を決定する環境変数または設定フィールドを宣言できるようにするべきです。

## 内部の詳細 {#internal-details}

OTLP エクスポーターは、必要とする動作を Metrics SDK に伝えることができます。
SDK はメトリクスの以前の状態を現在の値とマージし、適切な値をエクスポーターに返すことができます。

設定可能なエクスポート動作は、[Go SDK](https://github.com/open-telemetry/opentelemetry-go/pull/840) の Metrics Processor コンポーネントですでにコード化されています。
しかし、この機能は現在ハードコードされており、ユーザー定義の設定を扱えるように書き直す必要があります。
両方のエクスポート動作をサポートする OTLP のメトリクス定義については、[PR #193](https://github.com/open-telemetry/opentelemetry-proto/pull/193) を参照してください。

## トレードオフと緩和策 {#trade-offs-and-mitigations}

高いメモリ使用量。 累積エクスポートをサポートするためには、SDK は各累積メトリクスに対して状態を維持する必要があります。
これは、高カーディナリティのメトリクスを持つユーザーが高いメモリ使用量を経験する可能性があることを意味します。

高カーディナリティなメトリクスのユースケースは、Collector にメトリクス集約プロセッサーを追加することで対処できます。
これにより、Agent として設定された Collector が、デルタの OTLP を累積の OTLP に変換することをサポートできるようになります。
この機能には、あるメトリクスのすべてのデルタ値が同じ Collector インスタンスによって変換されるように、メトリクスを生成するクライアントごとに単一の Agent が必要です。

## 先行技術と代替技術 {#prior-art-and-alternatives}

議論された解決策の1つは、Agent としても単独のサービスとしても、Collector においてデルタを累積に変換することです。
しかし、Collector が単独のサービスとして動作している場合の変換をサポートするには、同じ累積メトリクスのデルタ値が同じ Collector インスタンスによって集約されることを保証するために、すべての Collector インスタンスにまたがるルーティングメカニズムの実装が必要になります。

## 未解決の問題 {#open-questions}

前のセクションで述べたとおり、Prometheus タイプのバックエンドをサポートするためには、Collector でのデルタから累積への変換が必要です。
Collector は他のソースからデルタ値を報告するメトリクスを受け取ることもあるため、これは将来的に Collector で必要になるかもしれません。
一方で、ソースが累積値を報告している場合は、Statsd タイプのバックエンドをサポートするために累積からデルタへの変換が必要です。

Collector における変換の将来的な実装については、まだ議論が続いています。
デルタから累積への変換のための解決策を提案する [Metric Aggregation Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/4968) を Collector に追加するという提案があります。

## 今後の課題 {#future-possibilities}

検討され得る将来の改善として、起動時に OTLP クライアントの適切なエクスポート戦略を決定する設定サーバーからの動的な設定をサポートすることが挙げられます。