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

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

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

動機

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

解説

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

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

内部の詳細

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

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

トレードオフと緩和策

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

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

先行技術と代替技術

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

未解決の問題

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

Collector における変換の将来的な実装については、まだ議論が続いています。デルタから累積への変換のための解決策を提案する Metric Aggregation Processor を Collector に追加するという提案があります。

今後の課題

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