題幹與適用場景
一個服務準備接入 OpenTelemetry，團隊想把 userid、requestid 和 URL 全部作為指標屬性。請設計基數預算，說明哪些欄位保留、超限時如何處理，以及如何證明告警仍然有用。
OpenTelemetry 指標由屬性組合形成時間序列；SDK 的 cardinality limit 是每個指標在一次收集週期內可追蹤的指標點上限。高基數欄位會放大記憶體、匯出、儲存和查詢成本，因此預算必須同時保護成本與診斷價值。
面試官考察點
面試官會看你是否能區分指標、日誌和 trace 的適用維度，理解屬性組合而非單欄位數量，設計硬上限和降級策略，並用服務圖、告警、取樣和去識別化約束證明方案可營運。
回答前需要釐清的問題
先確認指標用途、查詢窗口、告警延遲、租戶規模、端點數量、收集週期、後端保留期限和預算。再確認是否已有 trace/log 關聯欄位、哪些身份欄位受隱私限制，以及超限時更重視新值、舊值還是聚合準確性。
30 秒回答框架
「我先按指標用途定義允許的維度，不把所有上下文都塞進指標。保留穩定、低基數且能分組告警的欄位，例如服務、區域、路由模板和狀態類；userid、requestid 和原始 URL 放到 trace 或日誌。為每個指標設定 cardinality limit、成本告警和超限觀測，選擇有解釋性的聚合或丟棄策略。最後用歷史流量回放驗證告警召回、誤報、查詢成本和隱私要求。」
分步驟深入解答
第一步：定義指標問題
先寫出要回答的問題：錯誤率是否升高、哪個路由受影響、某區域是否退化，還是某個使用者的單次請求細節。前幾類適合指標，最後一類通常由 trace 或日誌提供。
第二步：估算組合基數
基數是屬性組合形成的唯一集合，不是每個屬性取值數量簡單相加。估算服務、區域、路由模板、狀態碼、方法和租戶等級的乘積，再用真實分布、長尾和突發流量校正。
第三步：建立欄位分層
保留穩定且可聚合的欄位；把使用者、請求和完整 URL 放入 trace/log；對高基數租戶標識採用分桶、雜湊或取樣，前提是仍符合存取控制和調查需求。不要用原始路徑參數製造無限新序列。
第四步：配置 SDK 與後端預算
在 SDK、Collector、時序後端和查詢層分別設定預算，避免只在最後一層截斷。OpenTelemetry 的指標 cardinality limit 是硬上限，具體保留哪些屬性集合必須在實作和告警中可觀察。
第五步：設計超限行為
明確超限時保留哪些屬性組合、是否回退到溢出桶、是否丟棄新集合，以及如何計數。策略要穩定、可解釋，並向維運發出「預算耗盡」信號，不能靜默丟資料。
第六步：把關聯性放到正確信號
用 traceid 關聯單次請求，用日誌保存原始 URL 或 userid，並透過 exemplars 或連結從指標跳到樣本。指標負責趨勢和告警，不能取代逐請求診斷。
第七步：管理服務圖與成本
服務圖和自動儀表化可能產生多組指標。為邊、用戶端、伺服器端和異常狀態設定獨立預算，控制匯出頻率、保留期和高基數屬性。成本報表應按服務和指標歸因，而不是只看總量。
第八步：驗證告警品質與隱私
用歷史回放和故障注入比較有無預算時的召回、誤報、延遲和查詢成本。檢查去識別化、存取控制、刪除請求和跨租戶隔離，驗證超限事件、配置變更和資料遺失都可追蹤。
高品質示範回答
我會先把問題分成趨勢告警和單請求調查。服務、區域、路由模板、方法和狀態類通常穩定且低基數，適合作為指標屬性；userid、requestid 和帶參數 URL 不放在指標中，而透過 trace、日誌和 exemplars 關聯。估算屬性組合乘積並用真實長尾修正，為 SDK、Collector 和後端設定 cardinality limit 與成本預算。超限時採用明確溢出或丟棄規則，記錄預算耗盡指標，不能靜默失敗。服務圖邊、用戶端和異常狀態分別設預算，控制收集頻率與保留期。上線前用歷史流量回放和故障注入比較告警召回、誤報、查詢成本、隱私和跨租戶隔離，確認預算不會掩蓋關鍵故障。
常見錯誤
只計算單欄位取值數量
指標序列由屬性組合形成，多個中等基數欄位相乘後也可能爆炸。必須估算組合、長尾和突發，不是逐欄看起來都可接受。
把 user_id 放進所有指標
使用者級調查更適合 trace 和日誌。把身份標識放進指標會增加成本、隱私風險和查詢噪音。
超限時靜默丟棄
靜默遺失會讓告警看似正常。要記錄預算耗盡、保留規則和配置版本，並驗證降級後的診斷能力。
延伸追問與參考答案
路由模板和完整 URL 應如何區分？
指標使用規範化路由模板，避免每個路徑參數產生新序列；完整 URL 放到受控日誌或 trace，並按隱私策略去識別化。
cardinality limit 觸發時應保留舊值還是新值？
取決於告警目標和聚合器，但必須固定、可解釋且可觀察。記錄溢出計數，避免不同實例採用不一致規則。
如何關聯指標、trace 和日誌？
使用 traceid、spanid 或 exemplars 連結樣本；指標保留穩定維度，日誌和 trace 承擔逐請求上下文，並在權限邊界內跳轉。
服務圖為什麼需要獨立預算？
自動產生的邊、用戶端和異常維度會成倍增加序列。按邊類型、收集頻率和保留期拆分預算，避免服務圖擠占業務指標。
如何證明預算沒有隱藏故障？
回放真實流量並注入高基數、錯誤峰值和租戶長尾，比較預算前後的召回、誤報、延遲和查詢結果，同時觀察預算耗盡事件。
什麼時候應增加日誌而不是指標？
當問題需要單次請求、原始輸入或使用者級上下文時，增加受控日誌或 trace；指標只承載可聚合的趨勢和告警維度。