metrics、logs、traces 三本柱

想像你經營一家忙碌的餐廳，想了解它的運作狀況。你可以記持續累計的數字——每小時上了幾盤菜、平均等候時間（這些是 metrics，度量）。你可以記一本值得注意事件的日記——「晚上七點烤箱壞了」「一大團客人來了」（這些是 logs，日誌）。或者你可以從進門到甜點，全程跟著「某一位」客人，替每個步驟計時（這就是 trace，追蹤）。對同一個廚房的這三種視角，就是人們用來讓系統可觀測的經典「三本柱」。

每根柱子都有精確的形狀與精確的成本。metric 是隨時間量測的一個數字——計數器（已服務的請求數）、量測值（此刻使用中的記憶體）、或直方圖（請求耗時的分佈）。metrics 很小、儲存與彙總都便宜，所以非常適合儀表板與警報，但單一個數字丟掉了任何個別事件的細節。log 是某個離散事件帶時間戳的紀錄，理想上以鍵值欄位結構化（見結構化日誌）；logs 保留了每事件的細節，但它的量與成本會隨流量增長。trace 則跟著「一個」請求流經各函式與各服務，記錄每一步（稱為 span）以及它花了多久；trace 是三者中唯一能向你展示因果路徑、以及單一請求內部時間花在哪裡的那一個。三者互補：metrics 告訴你「有東西變了」，traces 顯示請求中時間「花在哪裡」，logs 在某個特定點給出「為什麼」。

它之所以重要，是因為沒有任何單一柱子能回答每個問題，用錯柱子不是浪費就是辦不到。你不會把每請求的 trace 當成 metric 來存（會丟掉請求身分），也不會去掃數十億筆 log 來算平均延遲（一個 metric 用一個便宜的數字就做到了）。現代誠實的修正是：若把三本柱存成三個彼此斷開的孤島，「三本柱」這個說法反而會誤導你——真正的好處來自於一筆寬的結構化事件可以被彙總成 metric、保留為 log、並縫合進 trace，讓你在各視角間移動而不必重新插樁。OpenTelemetry 的存在很大程度上就是為了統一它們。