プロンプト
マルチリージョンサービス向けのレイテンシメトリクスパイプラインを設計してください：SDK が OpenTelemetry の ExponentialHistogram データを送信し、Collector がそれを集約し、バックエンドが Prometheus ネイティブヒストグラムを書き込みます。セマンティクス、ダウングレードパス、コスト制御について説明してください。
シナリオと制約
レイテンシはマイクロ秒から数分に及び、サービスには高カーディナリティのラベルが存在します。一部のバックエンドはクラシックバケットのみをサポートし、バッチが失われる可能性があり、クエリには p50、p95、およびリージョン間集約が必要です。メトリクスはテナントデータを公開してはならず、無制限の時系列を作成してはなりません。
この質問でテストされること
このテストでは、指数境界、スケール、正および負のバケット、ゼロカウント、count/sum、テンポラリティ（時間性）、およびプロセス間のマージ可能性をカバーします。OpenTelemetry は、小さな相対誤差で高ダイナミックレンジを実現するために指数境界を圧縮します。Prometheus ネイティブヒストグラムはそのモデルをマッピングできますが、変換とクエリは意味を維持する必要があります。
参考アプローチ
SDK では承認されたビジネスディメンションと観測値のみを記録します。Collector において、サービス、リージョン、固定ウィンドウごとに同一スキーマをマージします。サポートされていないバックエンド向けには明示的に有界なクラシックバケットに変換し、精度の低下を記録します。スケール、バケット数、ラベルセット、テナントごとのバジェットを制限します。制限値に達した場合は、サイレントに切り詰めるのではなく、ダウンサンプリングするか新しいラベルを拒否します。
重要な詳細
マージする前に、テンポラリティ、集約テンポラリティ、スキーマ、正および負のバケット、時間範囲を確認します。異なるスキーマを直接加算することはできません。p95 を近似値としてクエリし、サンプル数、誤差、ダウングレードマーカーを表示します。バッチを重複してカウントしないように、バッチシーケンス番号と再試行を使用します。
よくある落とし穴
指数バケットを正確な分位値と呼ぶこと、異なるテンポラリティを加算すること、無制限のラベルを許可すること、すべてを最も細かいスケールに変換すること、負の値、ゼロバケット、再試行の重複を無視すること、およびクエリ増幅を考慮せずにストレージのみを測定することです。
評価基準
優れた回答は、SDK、Collector、remote-write、クエリ、バジェット制御の境界を定義し、マージの不変条件とダウングレードポリシーを明記し、p95 の誤差を説明します。データモデルやコスト分析なしに「histogram_quantile を使用する」とだけ答えるのは不十分です。
フォローアップ質問
なぜ異なる指数スキーマを直接マージできないのですか？
バケットのインデックスが異なる境界にマッピングされているため、加算すると観測値が誤った範囲に配置されてしまいます。仕様に従って互換性のあるスキーマに再マッピングし、精度の変更を記録してください。
cumulative テンポラリティと delta テンポラリティをどのように一緒に処理しますか？
各ストリームの開始値と前回の値を保持しながら、Collector で明示的に変換します。連続性が失われている場合は、不完全なウィンドウをドロップするかマークします。cumulative の値を delta として加算してはなりません。
どのような場合にクラシックヒストグラムへフォールバックすべきですか？
バックエンドがネイティブサポートを欠いている場合、コンプライアンスで固定範囲が要求される場合、またはクエリエコシステムが指数バケットを解釈できない場合に、有界なクラシックバケットを使用します。コンシューマーに推測させるのではなく、誤差とコストのトレードオフを公開してください。