題幹與適用場景
多個團隊使用不同日誌函式庫和代理，級別名稱從 TRACE、DEBUG 到 CRITICAL 不一致。請說明如何映射到 OpenTelemetry 的 SeverityNumber 與 SeverityText，如何保留原始資訊，並處理例外、取樣、查詢和版本遷移。
面試官考察點
- 是否區分標準化的 SeverityNumber、原始 SeverityText 和日誌正文。
- 是否理解數值區間表達嚴重度，而不是把所有系統的同名級別硬編碼成一一對應。
- 是否能結合例外事件、資源屬性、trace/span 關聯和採集器轉換。
- 是否考慮未知級別、取樣偏差、查詢相容、告警閾值和回放驗證。
回答前需要釐清的問題
- 每種來源的級別定義、數值範圍和升級規則是什麼？是否存在自訂級別？
- 需要保留原始級別字串、日誌函式庫名稱和版本嗎？下游查詢依賴哪些欄位？
- 例外是獨立事件還是普通日誌正文？是否需要關聯 trace、span 和 request ID？
- 映射會影響告警、取樣、儲存成本和合規留存嗎？如何回放歷史日誌驗證結果？
30 秒回答框架
我會先為每個來源建立語義字典，區分日誌級別的含義和名稱，再映射到 OpenTelemetry SeverityNumber 區間，同時保留原始 SeverityText 與來源元資料。例外使用標準例外語義並關聯 trace/span，不把整段堆疊塞進級別欄位。採集器負責轉換和驗證，未知級別進入可觀測的降級路徑。上線前用代表性樣本回放，檢查告警閾值、取樣、查詢和成本，避免一次性重新解釋所有歷史資料。
分步驟深入解答
1. 先定義標準欄位
OpenTelemetry Logs Data Model 將嚴重度拆成 SeverityNumber 和 SeverityText。Number 用於可比較的嚴重度範圍，Text 保留產生方的原始或顯示名稱；正文、屬性、資源和時間戳承擔其他語義。映射表應記錄來源系統、原級別、目標範圍和理由，而不是只寫一段轉換程式碼。
2. 建立來源到範圍的映射
不同框架的 WARN、ERROR 或 FATAL 可能對應不同營運動作。按語義將它們映射到連續區間，保留無法確認的級別為未定義或低信心，並把原始值放入 SeverityText 或受控屬性。不要把數字本身跨系統直接比較，先驗證每個來源的文件和樣本。
3. 處理例外與關聯資訊
OpenTelemetry 例外語義建議記錄例外型別、訊息和堆疊等欄位，並按例外是否導致應用失敗選擇合適嚴重度。日誌應攜帶 trace ID、span ID、服務和部署版本等關聯資訊，讓查詢能區分同一請求中的多條日誌。例外堆疊屬於診斷資料，應按敏感資訊和留存策略處理。
4. 驗證採集、告警與遷移
在 Collector 或邊緣代理中執行映射、欄位驗證和相容轉換，記錄無效值與丟棄原因。用歷史樣本和合成故障回放，驗證告警閾值、取樣規則、查詢結果和儲存成本。版本升級時保留映射版本與原始欄位，讓下游可以按版本解釋歷史資料，而不是靜默改變告警含義。
高品質示範回答
我會先為 Java、Python、Nginx 等來源建立有文件依據的語義映射，目標是 OpenTelemetry SeverityNumber，原始名稱保留在 SeverityText 和受控屬性中。數字只用於同一標準內比較，未知或自訂級別進入低信心路徑並告警。例外按 OpenTelemetry 例外語義記錄型別、訊息和堆疊，同時關聯 trace/span 和服務版本。Collector 負責轉換、驗證和指標記錄；上線前回放歷史與故障樣本，驗證告警、取樣、查詢和成本。映射版本與原始欄位長期保留，保證遷移可追溯。
常見錯誤
- 把所有來源的 ERROR、WARN 或 FATAL 直接一一映射，沒有核對語義。
- 只保留 SeverityNumber，丟棄原始級別和來源版本。
- 用日誌正文代替例外欄位，導致堆疊無法檢索或洩漏敏感內容。
- 忽略 trace/span 關聯，無法把日誌與請求鏈路對齊。
- 映射失敗時靜默丟棄或強行降為 INFO，沒有指標和告警。
- 修改映射後直接重算歷史告警，卻沒有版本和回放記錄。
追問及應對
未知級別應該映射到哪個數值？
先保留原始文字並標記未知或低信心，不應隨意塞進 ERROR。若業務必須排序，定義明確的預設區間並記錄映射版本，同時監控未知值比例，推動來源補齊語義。
取樣會不會改變嚴重度分布？
會。按嚴重度和例外事件設計優先級，保留高價值故障樣本，並記錄取樣決策和輸入分母。比較取樣前後的級別分布，避免用取樣後的計數直接代表真實錯誤率。
如何相容舊查詢？
在轉換層保留原始欄位和舊別名一段時間，提供版本化視圖或查詢函式。遷移期間對告警和報表做雙寫或對照回放，確認新舊結果差異後再下線舊欄位。