為什麼 OpenTelemetry 贏了，Logs 輸掉了可觀測性戰爭

OpenTelemetry 會成為可觀測性標準，因為在微服務裡，traces 比 logs 更快找出故障根因。

OpenTelemetry 不是靠潮流贏的；它贏在微服務把 logs 變得太慢、把 traces 變得太必要。當一個請求橫跨 20 個服務時，靠時間戳去 grep 分散在不同主機上的日誌，最後只會變成猜測，而猜測不是除錯。採用 trace-first 工作流的團隊，常把平均修復時間從數小時縮到數分鐘，因為他們不再問「這台機器發生什麼事」，而是直接問「這個請求在哪裡斷掉」。

第一個論點

分散式追蹤解決的是實際的除錯問題，不是觀念問題。單體系統裡，一段 stack trace 往往就夠了；但在分散式系統裡，失敗通常是一連串事件：上游 timeout、重試風暴、資料庫變慢、下游 queue 堆積。tracing 會把這條鏈直接畫出來，所以它比翻 log 更接近真相。

操作面的證據很直接。以 2020 年前後常見的 log-based 排查來看，一次事故常要超過 4 小時；trace-based 的觀測方式，則能把同類事件壓到大約 15 分鐘。這不是小幅改善，而是值班團隊少熬一整晚，工程師也能在下一張客服工單進來前先修掉根因。

第二個論點

OpenTelemetry 之所以贏，是因為它把 tracing 變成可攜的基礎層。Datadog、Honeycomb、Grafana Tempo、AWS X-Ray 都能吃同一份訊號，代表團隊不必為了換 backend 重新寫一次 instrumentation。對工程組來說，這等於把可觀測性從供應商綁定，改成標準化資料管線。

這種可攜性很重要，因為 instrumentation 一旦進入整個 codebase，成本就會累積。OTel 讓工程師只要在 HTTP handler、SQL 呼叫、queue 進出點加一次 span，資料就能依業務需要送到不同系統。collector 模式尤其關鍵，因為同一條 pipeline 可以把 traces 送去 Tempo 做低成本保留，也送去 Datadog 做告警，團隊拿到的是槓桿，不是鎖定。

反方可能怎麼說

log-first 的支持者不是完全錯。他們會說，traces 不是 logs 的替代品。logs 在 payload 檢查、應用特定上下文、以及你已經知道故障範圍之後的鑑識分析上，仍然更有用。trace 可以告訴你付款流程在下游服務失敗，但真正的驗證錯誤訊息或第三方回應內容，常常還是只有 log 裡看得到。

另一個合理批評是成熟度問題。不是每個團隊都有乾淨的 propagation、一致的 span 命名，或可信的 collector 管線。如果 instrumentation 做得很亂，traces 只會變成一個漂亮但不完整的介面。這種情況下，logs 會顯得更可靠，因為它們比較容易產生，也比較容易搜尋。

但這些批評推翻不了 trace-first，只能證明 logs 仍是輔助訊號。在分散式系統裡，最難的不是知道 fault domain 之後讀細節，而是先找到 fault domain。traces 在這件事上就是更快，而 OpenTelemetry 讓團隊不用賭單一供應商，也不用自建一套脆弱的 instrumentation 規則。

你能做什麼

如果你是工程師，先把關鍵路徑打通：入口、資料庫呼叫、queue hop、付款或驗證邊界。如果你是 PM 或創辦人，不要再用 log volume 衡量可觀測性，而要看 resolution time、錯誤保留率，以及有多少服務能吐出可用 traces。最實際的做法是：把 OpenTelemetry 設成預設，保留 logs 當細節，並讓 traces 成為團隊遇到延遲或跨服務故障時的第一個入口。