資料面試：如何設計 OpenTelemetry 指數直方圖管道並控制成本？

題目

為多區域服務設計延遲指標管道：SDK 產生 OpenTelemetry ExponentialHistogram，Collector 聚合，後端寫入 Prometheus 原生直方圖。請說明資料語義、降級與成本控制。

場景與限制

延遲範圍從微秒到數分鐘，服務有高基數標籤。部分後端只支援經典桶，網路可能丟批，查詢需要 p50、p95 和跨區域聚合。指標不能暴露租戶隱私，也不能無限增加時間序列。

核心考點

考察指數邊界、scale、正負桶、zero count、count/sum 與 temporality，以及跨程序合併的可交換性。OpenTelemetry 指數直方圖用指數公式壓縮桶邊界，在近似大小下涵蓋高動態範圍；Prometheus 原生直方圖可映射該模型，但轉換與查詢必須保留語義。

參考解法

SDK 只記錄允許的業務維度和原始觀測，Collector 按服務、區域與固定時間窗合併同 schema 資料。不支援原生直方圖的後端明確轉成經典桶並記錄精度損失。限制 scale、桶數、標籤集合和每租戶預算；超限時降採樣或拒絕新標籤，不靜默截斷。

關鍵細節

合併前檢查 temporality、aggregation temporality、schema、正負桶和時間範圍；不同 schema 不能直接拼接。查詢層對 p95 使用直方圖分位數近似，面板顯示樣本量、誤差和降級標記。丟批時用批次序號和重試，避免同一批重複計數。

常見誤區

把指數桶當成精確分位數；把不同 temporality 相加；無界標籤直接進入維度；所有資料轉成最細 scale；忽略負值、零桶和重試重複；只看儲存量不看查詢放大。

評估標準

優秀答案能畫出 SDK、Collector、遠端寫入、查詢和預算控制邊界，給出合併不變量、降級策略與 p95 誤差說明。一般答案只說「用 histogram_quantile」，沒有解釋資料模型與成本。

追問

為什麼不能直接合併不同 schema 的指數直方圖？

桶索引與邊界映射不同，直接相加會把觀測放進錯誤區間；應依規範重映射到相容 schema，並記錄精度變化。

如何處理累計 temporality 與 delta temporality 混用？

在 Collector 明確轉換並保存每個流的起點與上次值；缺少連續性時丟棄不完整窗口或標記缺口，不能把累計值當 delta 重複相加。

何時應退回經典直方圖？

下游不支援原生格式、合規要求固定桶或查詢生態無法解釋指數桶時，選擇有限經典桶並公開誤差與成本，而非讓消費者猜轉換規則。