將 Telemetry 與 OpenTelemetry 配合使用
Telemetry 和 OpenTelemetry 解決可觀測系統的相關但不同的部分。 OpenTelemetry 提供供應商中立的 API、SDK、語義約定以及追蹤、指標和日誌的收集器。 Telemetry 為專用 JSON 應用程式結果、型別資料表、DataFusion SQL、儀表板和警示提供託管路徑。
Telemetry 目前不提供 OTLP 攝取端點，不應被描述為 OpenTelemetry 收集器後端。將 OpenTelemetry 採集器 與 OTLP 相容的可觀測性後端結合使用，以獲取追蹤、指標和日誌。當應用程式達到受益於 SQL 的業務或運營結果時，發出單獨的 Telemetry 事件。
為每個訊號分配一份工作
| 訊號 | 最佳起始問題 |
|---|---|
| 公制 | 總體服務或基礎設施健康狀況是否正在發生變化？ |
| 蹤跡 | 這個分散式請求的時間都去哪兒了？ |
| 診斷日誌 | 哪些本地詳細資訊解釋了此程式碼路徑？ |
| Telemetry事件 | 哪些已完成的結果會影響使用者、帳戶、工作流程或成本中心？ |
結帳追蹤可以顯示資料庫和提供商範圍。 checkout_completed 事件可以儲存收入影響 SQL 所需的終端狀態、安全帳戶 ID、計劃、金額類別、重試計數、釋放和延遲。兩者都不需要複製對方。
與批准的識別符號關聯
讀取應用程式結果邊界處的活動 OpenTelemetry 跨度上下文：
import { trace } from "@opentelemetry/api";
const spanContext = trace.getActiveSpan()?.spanContext();
await telemetry.log("checkout_completed", {
checkout_id: checkoutId,
status: "success",
latency_ms: 684,
trace_id: spanContext?.traceId,
span_id: spanContext?.spanId,
checkout_version: "v2",
release: process.env.APP_RELEASE,
});
將追蹤和跨度 ID 視為查詢欄位，而不是圖表維度。在將跨系統關聯作為事件工作流程的一部分之前，請確認追蹤系統和 Telemetry 具有相容的存取和保留邊界。
不要批次複製跨度事件、資源屬性、包袱、提示、請求正文或堆疊追蹤。使用允許名單。 OpenTelemetry 行李尤其可以跨服務邊界傳播，不應假定分析是安全的。
獨立操作管道
OpenTelemetry 收集器可以批次處理、重試、過濾和匯出其支援的訊號。 Telemetry SDK 或 Log API 有其自己的傳遞行為。監視兩個管道並避免耦合它們的故障模式：
- 失敗的結果事件傳遞不應結束原本成功的請求
- 失敗的追蹤匯出不應觸發遞迴事件記錄
- 關鍵稽核或計費結果應使用明確持久的應用程式路徑
- 取樣決策應針對特定訊號
- 部署驗證應確認相關性和獨立可用性
OpenTelemetry測井規範 解釋了追蹤和日誌上下文之間的相關性。使用 OpenTelemetry整合指南、日誌、指標、追蹤和事件 和 規範廣泛事件 選擇最小的可靠訊號組。