以下是影片內容的完整解釋與重點摘要：
Log 是否仍有一席之地？ [05:30]
來賓們討論在現代可觀測性Observability）中 Log 的地位。Ed認為 Log 是「唯一真實的可觀測性訊號」，因為它是最容易獲取的（從 Hello World 就開始用），且無法被完全取代（如 process 的 stdout/stderr）。
Zero Duration Spans (零持續時間的 Span) [08:33]：Jack 提到一種反模式，即人們將 Log 記錄為「持續時間為零」的 Span。他認為如果不具備層級結構且沒有持續時間，那它本質上就是 Log，不應硬套用 Span 的概念。
儘管已有很多成熟的 Log [框架（如 Log4j,Python logging），OpenTelemetry 仍推出了自己的 Logging API。
互操作性（Interoperability）：最初目的是為了橋接現有的 Log 系統（Log Bridge API）。
統一性：讓使用者能用同一套 API 處理 Metrics、Traces 和 Logs。
強型別與結構化：OpenTelemetry 希望推動 Log 往「結構化（Structured）」方向發展，包含明確的事件名稱（Event Name）與屬性（Attributes），而非僅是純文字字串。
兩難：純文字 Log 對人類閱讀除錯很友善，但對機器分析不便；結構化 Log（如 JSON）對機器友善，但人類難以直接閱讀。
建議：Log 應該是結構化的，但保留一個人類可讀的訊息欄位（或將其轉化為 Event Name）。[34:51]
來賓們分享了具體的實戰建議：
撰寫有意義的錯誤訊息[36:52]
直接傳送 vs檔案抓取**[42:50]
Jack 建議應用程式應直接透過網路（OTLP協定）發送Log後端，而不是寫入檔案再由 Agent 去抓取（Tail）。這樣能更無縫地保留 Context（如 Trace ID）。
Ed 補充建議：在應用程式與後端之間最好有一個本地的Collector**。這樣當需要過濾大量垃圾 Log 時，可以在 Coller 端調整設定，而無需重新部署應用程式。
不要濫用 Log
[Log 等級（Severity[01:03:36]：絕對不要記錄沒有等級的 Log。至少要區分 INFO、ERROR、DEBUG，這對過濾和警報至關重要。
安全性 [01:01:53]：小心不要在 Log 中記錄 PII（個人識別資訊）或 Secrets，也不要記錄完整的 HTTP Headers。
影片末尾[[57:12]] 進行了一個快問快答遊戲：
格式化 Log 字串？** 不建議（應使用參數化/結構化）。
將所有 Excetion 都記為 Error？ 同意。
記錄 Request/Response Body？ 通常不建議（成本太高且易洩漏個資，除非有極強烈的除錯需求。
記錄所有細節？ 不建議，每一個 bytes都要錢，請有意識地選擇要記錄的內容（Be intention）。
在 Cloud Native 與微服務架構盛行的 2025 年，Log（日誌）這個最古老的除錯工具，是否已經過時？或者它只是需要一點「現代化」的改造？
最近觀看了 Grafana Labs 與 OpenTelemetry (OTel) 技術委員會成員的一場深度對談（Community Call），主題聚焦於 Logging Best Practices。這場討論並非單純的操作教學，而是對於 Log 在現代可觀測性（Observability）中角色的重新定義。
以下整理了影片中的核心觀點，希望能幫助開發者與維運人員打破舊有的 Log 思維，建立更具「意圖性」的可觀測性策略。
在 Tracing（追蹤）技術日益普及的今天，很多人會問：「我還需要 Log 嗎？」答案是肯定的，而且 Log 是不可取代的「唯一真實訊號」。
然而，為了追求新技術，社群中出現了一種名為 Zero Duration Spans（零持續時間 Span） 的怪現象。
開發者為了利用 Tracing 工具的視覺化，將原本該是 Log 的單點事件，包裝成「開始時間等於結束時間」的 Span。
OpenTelemetry 技術委員會成員 Jack Berg 對此提出了精闢的見解：
"If it walks like a log, talks like a log, it's a log." （如果它走起來像 Log，叫起來像 Log，那它就是 Log，別裝了。）
Span (Traces)：具有層級結構（Hierarchy）與持續時間（Duration）。用來回答「這個請求花了多久？路徑為何？」。
Log：發生在特定時間點的事件。用來回答「當下發生了什麼事？」。
最佳實踐：誠實面對資料的本質，不要硬套用 Span 的概念。Log 依然是一等公民。
傳統的 Log 是一行行給人類閱讀的字串（Text-based），但在微服務與海量資料的場景下，這種模式已經行不通。OpenTelemetry 正推動 Log 往 結構化（Structured） 與 強型別（Strongly typed） 發展。
查詢效率：試想在幾億行 Log 中 grep 字串，與在資料庫中查詢 attributes.http_status_code == 500 的區別。
關聯性：OTel 的目標是讓 Logs、Traces、Metrics 使用統一的語意規範（Semantic Conventions）。
結構化 Log（如 JSON）對機器友善，但對人類閱讀不便。
message 欄位或是將其轉化為易讀的 Event Name 供人類快速瀏覽。你的 Log 是怎麼送到後端的？這涉及到架構的解耦。
應用程式將 Log 寫入磁碟檔案 -> Agent (如 Promtail) 去抓取 (Tail) -> 傳送後端。
應用程式透過網路協定（OTLP）直接將 Log 發送出去。
Grafana Loki 的維護者 Ed 提出了一個極佳的架構建議：在應用程式旁跑一個 Local Collector（作為 Sidecar 或 DaemonSet）。
好處：當你需要將 Log Level 從 INFO 改為 DEBUG 時，你只需要調整 Collector 的過濾規則，完全不需要重新部署應用程式。這實現了極致的維運解耦。
當開發者敲下 logger.error(...) 時，請記住以下原則：
不要只寫「連線失敗」。錯誤訊息必須包含「接下來該做什麼」。
❌ Bad: Connection failed.
✅ Good: Connection to DB failed, retrying in 5s. Please check network config. 精神：同理心。 給半夜修 Bug 的人一條明路。
沒有 Trace ID 或 User ID 的 Log，在高併發環境下幾乎是雜訊。務必確保 Log 包含足夠的上下文屬性。
不要 Log Request Body：除非在開發環境，否則這會導致儲存成本爆炸，且有洩漏 PII（個資）與 Secrets（金鑰）的風險。
不要用 Log 做統計：如果你想知道「API 被呼叫幾次」，請用 Metrics，不要用 Log。
整場討論可以用這兩個字總結："Be Intentional"。
Log 不再是廉價的 printf。每一行 Log 都有儲存成本、傳輸成本與認知成本。
這條 Log 是給誰看的？（人還是機器？）
它的目的是什麼？（除錯、稽核還是統計？）
它包含了足夠的資訊嗎？
在 2025 年，寫好 Log 不僅是技術能力的展現，更是一種對系統架構與團隊協作的深層思考。
參考來源：Grafana & OpenTelemetry Community Call - Logging Best Practices
這太重要了，剛好就看到前輩寫出來了
最近在工作上也是遇到公司有這些問題
像是要把log標準化、結構化、減少不必要的輸出（start/end）
最後還要透過log分級達到自動告警減少人工跟促進即時觀測性
是個很值得研究的題目
影片的大神有講，其實吧log內容沒人可以在一開始完整定義出要記錄哪些（包含欄位跟事件）
都是出事慢慢補上去的。所以結構化是先決條件，後續再加，格式不才會亂。知道level的定義，後續在家才知道怎分級。
ED想表達：
理想情況：大家坐下來開會，列出系統會發生的所有事件（如 USER_LOGIN_FAILED, PAYMENT_PROCESSED），定義好完美的 Schema，然後寫程式。這樣機器讀起來超爽。
現實情況：沒人有時間做這件事。開發者通常是在寫程式碼的過程中，隨手加上 Log 的。你無法在寫程式的第一天就預知未來所有的除錯場景。
所以會用 msg 這欄位去先隨手記錄一些事情。
iThome鐵人賽
看影片追技術