本篇文章更新時間：2025/12/22
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
編輯前言：這篇文章來自 Logging Sucks - Your Logs Are Lying To You，它點破了我們日常後端開發中最被忽視的真相：多數 Log 根本沒辦法幫你除錯。本篇筆記整理作者的核心觀點，也加入我自己的心得。
內容目錄
核心觀點 (Key Takeaways)
- 傳統 Log 寫法早已不適用現代分散式系統，因為缺乏「完整上下文」。
- Structured Logging、OpenTelemetry 都不是救星——真正關鍵是「Wide Events / Canonical Log Lines」。
- 真正能讓你節省時間、降低成本、快速定位問題的，是高維度、高基數、一次一筆的「完整事件紀錄」。
深入解析
作者以大量實際 log 範例開場，讓人瞬間有感：同一個請求可能產生十幾行訊息，卻依然沒法回答最基本的問題，例如「為什麼 user X 的 checkout 會失敗？」甚至即便你用 grep、正規表示式搜了半天，也不一定找得到答案。
"The fundamental problem: logs are optimized for writing, not for querying."
傳統 logging 思維是「程式跑到哪就 log 到哪」，像是行車記錄器一樣，但在分散式架構裡，此方式產生大量碎片化訊息，既難查詢、又難關聯。
作者指出幾個核心問題：
- String search 本質上是笨的：它不懂 userid、orderid、session_id 的語意，只會做字串比對。
- 高基數資料是 debugging 的關鍵來源：userid、requestid 這類資訊雖然 unique 很多，但恰恰是你定位問題時最需要的。
- OpenTelemetry 不是魔法：OTel 是傳輸協議，不會替你加上業務 context，更不會讓你的 telemetry 自動變好。
作者認為真正的解方，是徹底改變 mental model：不再把 log 當「程式活動記錄」，而是把每個 request 視為「一筆完整的業務事件」。
Wide Events：一次搞定所有上下文
所謂 Wide Event 或 Canonical Log Line，是「一個請求在一個服務中，只產生一行 log，但那一行包含所有關鍵資訊」。
包含：
- request metadata（method、path、duration 等）
- user 資訊（user_id、subscription、LTV…)
- cart 資訊
- payment 資訊
- feature flags
- deployment metadata（service version、git_sha 等）
- 錯誤內容（error type、code、stack）
這種「高維度」事件讓你不必跨 10 個 log line 拼湊故事，而是一眼就能知道整件事的全貌。
Sampling：控制成本的正確方式
作者也誠實提到成本問題：每秒數萬筆 request 的完整事件記錄確實會很貴。因此必須搭配 Tail Sampling：
- 永遠保留錯誤事件
- 永遠保留慢請求（如 > p99）
- 永遠保留特定用戶（VIP、內部測試）
- 其餘請求做隨機取樣（如 1–5%）
Tail Sampling 的關鍵是「結果導向」——你在事件完成後再決定是否保留，而不是盲目取樣。
作者的核心哲學：
"Stop logging what your code is doing. Start logging what happened to this request."
這句話某種程度是對傳統 logging 思維的顛覆。尤其是使用 tracing 的團隊更能理解：服務之間的 flow 用 trace 解決，但服務內的 context 仍要靠你自己補上。
筆者心得與啟發
讀完這篇，我最大的感受是：我們過去太把 logging 當成習慣性的附加動作，而不是設計的一部分。很多團隊雖然自稱「有 structured logging」、「有 OpenTelemetry」，但實際上只是在產生更多格式化的雜訊。
文章最讓我反思的是兩件事：
- Log 的真正價值其實是「可查詢性」而不是「可讀性」。如果一筆 log 不能被有效 query，它再好讀都沒用。
- Wide Events 不只是技術實作，而是產品思維：你必須知道調查問題時真正需要哪些 context，然後在事件發生當下一次補齊。
對正在做 Observability、SRE 或後端平台開發的人，我會強烈建議你把這篇做成團隊讀書會的材料，因為：
- 它會逼你重新檢視 log 的定義
- 它指出 OpenTelemetry 的使用盲點
- 它提供具體的 middleware 範本和 sampling 策略
更重要的是，它把「為什麼我的 log 什麼都查不到」這件事講得非常透徹。這篇文章的核心不是工具，而是思維模式。如果團隊能接受 Wide Events 的理念，你會發現 debugging 流程會從「考古」變成「分析」，速度完全不同。
最後，我非常認同文中的這句：
"Your logs stop lying to you. They start telling the truth."