系統設計：如何設計支援 Trace 關聯的 OpenTelemetry 日誌管道？

題幹與適用場景

面試官可能會問：「請設計一條支援 Trace 關聯的 OpenTelemetry 日誌管道，並說明資料模型、背壓、租戶隔離與故障恢復。」

這道系統設計題考察你能否把日誌從應用內事件變成可治理的遙測訊號。OpenTelemetry Logs Data Model 分開定義 Timestamp、TraceId、SpanId、SeverityNumber、Body、Resource 和 Attributes；OTLP 則規定日誌可以經由 agent、Collector 和後端逐跳傳輸。重點是維持語義、容量和安全邊界，不是簡單堆一條 Kafka 管道。

面試官考察點

是否能區分 Resource、Attributes、Body 和 Trace Context 的職責。
是否能設計應用、agent、Collector、佇列和後端之間的可靠路徑。
是否處理高峰背壓、批量、重試、丟棄等級和磁碟緩衝。
是否避免跨租戶資料洩露，並對日誌內容做脫敏和存取控制。
是否能解釋重複、亂序、採樣和 TraceId 缺失時的查詢體驗。

回答前需要釐清的問題

日誌來源是 SDK、現有檔案、容器 stdout，還是多種來源並存？
需要多少租戶、吞吐、保留期和查詢延遲？
TraceId 是否由應用統一注入，缺失時是否允許生成關聯鍵？
哪些欄位包含個人資料、密鑰或業務機密，脫敏應在哪一層完成？
後端不可用時，允許丟棄哪些等級，恢復後是否需要盡力重播？

30 秒回答框架

可以這樣回答：

我會採用應用或檔案採集器到本地 Collector，再到佇列和後端的分層管道。每條日誌保留時間、嚴重性、Body、Resource、Attributes，並在有上下文時寫入 TraceId 和 SpanId。Collector 負責批量、限流、脫敏和路由，佇列與磁碟緩衝吸收後端抖動。租戶標識進入 Resource 和授權索引，查詢層按租戶隔離。高峰時按嚴重性丟棄 debug，再處理採樣、重試、重複和恢復讀取路徑。

分步驟深入解答

先定義統一記錄

不要把整行文字當作唯一契約。可以用如下邏輯結構表達：

json

{
  "timestamp": "2026-08-01T10:00:00Z",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7",
  "severityNumber": 17,
  "severityText": "ERROR",
  "body": {"message": "payment declined", "code": "CARD_DECLINED"},
  "resource": {"service.name": "checkout", "tenant.id": "t-7"},
  "attributes": {"region": "us-east-1"}
}

Resource 描述產生日誌的實體，Attributes 描述事件實例，Body 保留結構化內容。嚴重性比較使用 SeverityNumber，展示時可同時保留原始 SeverityText。

設計採集與傳輸層

應用 SDK 或檔案接收器先把日誌轉成 OTLP；節點級 agent 負責本地批量和初步限流，Collector 負責解析、資源補全、脫敏、路由和導出。OTLP 支援經由中間 Collector 傳輸，長鏈路要明確逾時、認證和壓縮。佇列不是必選元件，但後端吞吐不穩時可作為持久化緩衝和租戶配額邊界。

處理背壓與資料等級

每個租戶和服務設定速率、批大小、記憶體上限和磁碟上限。後端變慢時先暫停低優先級導出，保留 error、audit 和安全事件；debug 允許採樣或丟棄。重試要有指數退避和最大保留時間，避免 Collector 重試風暴。批量失敗時記錄可重播範圍，並用冪等鍵或後端去重降低重複。

做安全、隔離與查詢關聯

在邊緣或 Collector 早期刪除密鑰、令牌和個人資料；租戶 ID 由受信 Resource 注入，不能接受任意客戶端覆寫。索引層按租戶和時間分區，TraceId、SpanId 建立可選關聯索引。沒有 TraceId 的日誌仍可按服務、時間和請求標識查詢，不能偽造一個看似真實的 TraceId。

高品質示範回答

我會把系統拆成記錄契約、採集、緩衝、處理和查詢五層。記錄按 OpenTelemetry Logs Data Model 保存時間、嚴重性、Body、Resource、Attributes，並在應用已有上下文時填充 TraceId 和 SpanId。應用或 filelog receiver 發送到節點 Collector；Collector 做批量、脫敏、租戶配額和路由，再透過 OTLP 導出到後端，必要時在中間加入按租戶限流的持久化佇列。後端抖動時，記憶體和磁碟緩衝吸收短峰，超過預算後按 debug、info、error、audit 的優先級丟棄，並監控丟棄率和最老資料年齡。查詢索引按租戶和時間隔離，TraceId 關聯是加速路徑，不把缺失上下文的日誌偽裝成鏈路資料。恢復時依賴批次範圍、退避和冪等去重，稽核與安全日誌使用獨立保留和存取策略。

常見錯誤

把所有欄位塞進 Body，失去 Resource、Attributes 和 Trace Context 的語義。
只畫應用到後端的直線，沒有 agent、Collector、佇列或磁碟緩衝。
後端故障時無限重試，造成記憶體耗盡和級聯放大。
讓客戶端直接提交租戶屬性，造成跨租戶查詢或索引污染。
為缺失 TraceId 的日誌隨機生成鏈路 ID，誤導排障。
只講吞吐，不定義優先級丟棄、脫敏、重複和恢復指標。

追問及應對

1. TraceId 缺失時怎麼辦？

保留原始日誌並標記上下文缺失，使用服務、時間、請求 ID 等可驗證欄位輔助查詢。只有應用或受信代理能提供關聯資訊時才填充 TraceId，不能隨機偽造。

2. 如何避免日誌洩露密鑰？

在 SDK、agent 或 Collector 早期執行欄位規則和正則脫敏，拒絕明顯的密鑰格式，並對後端做租戶級存取控制。抽樣保留原文時也要走更嚴格的隔離和稽核。

3. 什麼時候允許丟日誌？

先定義業務等級：安全、稽核和關鍵錯誤通常保留；debug 和高基數診斷欄位可採樣。每次丟棄都記錄原因、租戶、時間範圍和數量，讓容量壓力可解釋、可告警。