日誌、指標、追蹤和結構化事件
可觀測性訊號重疊，但不可互換。選擇能夠回答問題的最小訊號可以使儀器易於理解並控制成本。
每個訊號的優點
文字日誌 保留特定處理程序和時間的詳細診斷上下文。它們對於異常、異常分支和人類可讀的生命週期訊息非常有用。
指標總結了一段時間內的數字測量。計數器、儀資料表和直方圖對於服務範圍的速率、飽和度和延遲趨勢非常有效，但它們故意丟棄行級上下文。
追蹤跨請求路徑連線。它們顯示了哪些服務或依賴項消耗了時間，並且當一項操作跨多個系統時是有價值的。
結構化事件將已完成的業務或應用程式事實描述為可查詢的行。它們非常適合工作成果、Webhook 交付、LLM 請求、啟用里程碑以及影響客戶的錯誤，其中 SQL 應按帳戶、功能、模型、路線或版本進行分組。
從調查開始
對於“服務是否不健康？”，指標和警示可能就足夠了。對於“這個請求在哪裡花費了時間？”，使用追蹤。對於“此過程中到底發生了什麼？”，請檢查日誌。對於“哪些帳戶在發布後遇到同步失敗？”，查詢結構化事件。
您可以連線訊號，而無需到處複製每個屬性。將安全的 request_id 或 trace_id 放在結構化事件和診斷日誌上。在指標中保持低基數服務的健康狀況。在追蹤中儲存跨度特定的時序。這在系統之間建立了路徑，同時保留了每個系統的用途。
Telemetry 適合的地方
Telemetry 圍繞結構化事件資料表和 SQL 進行設計。它補充而不是取代基礎設施指標或分散式追蹤。在工作流程具有有用結果的邊界處發出事件，然後查詢該資料表以獲取比率、百分位數、群組和最近的範例。
例如，追蹤可以解釋為什麼一次結帳需要四秒鐘。 checkout_completed 事件可以顯示版本 v2 是否增加了所有客戶的 p95 延遲或支付失敗。