結構化事件與文字日誌
文字日誌描述了程式做了什麼。結構化事件記錄有關工作流程的穩定事實。兩者都很有用，但它們針對不同的問題進行了最佳化。
文字日誌非常適合本地診斷：啟動訊息、意外分支、庫輸出和堆疊追蹤。它的自由格式資訊為狹窄時間範圍內的閱讀者保留了上下文。當必須在多個請求中重複回答同一問題時，結構化事件更適合：按路線的失敗率、按模型的成本、按源的啟用或按佇列的重試。
查詢差異
假設應用程式寫入 invoice sync failed for team_123 in 940ms。搜尋可以找到該句子，但圖表必須首先提取團隊、持續時間和結果。有了結構化欄位，查詢就可以直接操作：
SELECT
error_type,
COUNT(*) AS failures,
approx_percentile_cont(duration_ms, 0.95) AS p95_duration_ms
FROM billing_syncs
WHERE status = 'failed'
AND timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY error_type
ORDER BY failures DESC;
事件契約使欄位型別和類別變得明確。它還可以防止微小的措辭更改破壞已儲存的查詢。
兩者同時使用，無需重複所有內容
保留詳細的、短期的診斷日誌，以便工程師調查事件。在工作流程邊界發出一組較小的持久結構化事件。使用請求 ID、追蹤 ID、作業 ID 或其他安全相關值將兩者連結起來。不要將完整的堆疊追蹤或請求正文複製到每個分析事件中。
一個事件不會因為它是 JSON 而自動變得更好。一堆不斷變化的鍵和任意字串仍然很難分析。該價值來自經過深思熟慮的合約：穩定名稱、記錄欄位、受控類別以及審查更改的所有者。
實用的選擇規則
當您希望根據資料聚合、比較、警示或建置儀表板時，請選擇結構化事件。當主要用途是在特定調查期間閱讀詳細上下文時，選擇文字日誌。如果兩者都需要，請發出共享關聯識別符號的一個緊湊事件和一個診斷記錄。