跳至主要內容
Telemetry
瀏覽說明文件
指南更新於 2026年7月28日由 Telemetry 編輯團隊和產品團隊審查閱讀約需 5 分鐘

讓程式設計代理使用這篇文件

開啟 Claude Code、Codex、Cursor 或其他編碼代理的集中提示包,然後將其適應此處介紹的工作流程。

本頁內容
  1. 在應用程式邊界發出有界事件
  2. 分開可靠性問題
  3. 故意對映OpenTelemetry資料庫欄位
  4. 按順序調查
  5. 瞭解應用程式端邊界
  6. 將經過驗證的查詢轉化為操作

使用 SQL 進行資料庫可靠性監控

資料庫症狀通常在伺服器指標中變得明顯之前就出現在應用程式中:呼叫者等待連線、一個操作指紋減慢、事務回滾、鎖定阻止使用者工作、副本落後或發布期間遷移失敗。結構化應用程式事件將這些結果與回應所需的服務、發布、路由、租戶影響和受控錯誤類別連線起來。

在應用程式邊界發出有界事件

為每個資料庫操作或邏輯事務記錄一個完成事件。使用受控操作名稱或標準化指紋代替原始 SQL。僅當支援影響分析時,才包括持續時間、結果、資料庫角色、服務、發布和經過隱私審查的帳戶識別符號。

切勿記錄查詢參數、連線字串、憑據、授權資料或不受限制的 SQL 文字。 deadlockserialization_failureconnection_timeout 等錯誤類別比原始異常訊息更安全、更容易分組。

{
  "event_name": "database_query_completed",
  "query_fingerprint": "checkout.select_with_line_items",
  "service": "checkout-api",
  "database_name": "app_production",
  "status": "success",
  "duration_ms": 842,
  "rows_returned": 4,
  "release": "2026.07.2",
  "environment": "production"
}

使用 節點-postgres 整合Prisma 整合 作為起點,然後集中包裝器,以便每個操作都使用相同的欄位名稱、時鐘、狀態值和脫敏策略。

分開可靠性問題

一種通用的“資料庫健康狀況”評分隱藏了不同的故障模式。將焦點事件資料表或穩定事件名稱用於:

  1. 查詢完成:持續時間、標準化指紋、行、結果和發布。
  2. 池狀態:活動、空閒、設定最大值、採集等待和超時。
  3. 事務:邏輯事務識別符號、提交或回滾以及受控錯誤型別。
  4. 鎖等待:阻塞和阻塞指紋、等待持續時間、解析度和死鎖檢測。
  5. 複製或 CDC:消費者、區域、落後的秒數和位元組以及當前狀態。
  6. 遷移:遷移識別符號、版本、持續時間、終端狀態和回滾類別。

資料庫可靠性配方收集 包含每個問題的模式、測試查詢、確定性結果、視覺化、邊緣案例、儀表板計劃和警示指南。您可以在調整之前在只讀 瀏覽器 SQL 遊樂場 中執行包含的燈具。

故意對映OpenTelemetry資料庫欄位

如果應用程式已發出 OpenTelemetry 資料庫跨度,請重用欄位的穩定含義,而不是建立競爭詞彙資料表。當前的OpenTelemetry 資料庫客戶端跨度約定定義了db.system.name、低基數db.operation.namedb.namespacedb.collection.namedb.query.summary和資料庫回應狀態上下文。他們還警告說,查詢文字可能是高基數,需要清理。

實用的結構化事件對映是:

OpenTelemetry 上下文 結構化事件欄位 複習筆記
db.system.name database_system 保留有界資料庫產品識別符號。
db.operation.name operation_name 使用受控動詞,例如 SELECT 或穩定的客戶端操作。
db.query.summary query_fingerprint 更喜歡在收集之前生成低基數摘要。
db.response.status_code database_status_code 僅當其語義已記錄時才保留驅動程式或資料庫程式碼。
跨度持續時間 duration_ms 說明是否包括池獲取和網路時間。
追蹤和跨度上下文 trace_idspan_id 使用識別符號進行關聯,而不復制跨度有效負載。

對映並不能自動證明欄位是安全的。查詢摘要、集合名稱、名稱空間和回應訊息仍然可以在某些系統中公開租戶或架構詳細資訊。檢查實際發出的值、上限基數,並預設保留原始查詢文字和繫結值。

按順序調查

從客戶可見的持續時間和故障率開始,然後檢查池獲取是否可以解釋延遲。按 p95 持續時間和總查詢時間對操作進行排名:執行數千次的中等速度較慢的查詢可能會比罕見的異常值消耗更多的應用程式時間。按操作和發布比較 SQLSTATE 或其他受控驅動程式程式碼,而不是對原始訊息進行分組。

如果失敗是事務性的,則將預期的可重試回滾與終端錯誤分開,並單獨檢查長時間執行的事務類。當涉及併發寫入時,檢查鎖等待和死鎖事件。在將池飽和解釋為大小調整問題之前,比較連線開啟、關閉、獲取超時和受影響的請求。在信任下游讀取模型之前,除了應用程式觀察到的陳舊讀取和故障轉移結果之外,還要檢查副本或 CDC 滯後。將遷移失敗與部署時間戳對齊。

不要僅根據利用率來增加連線池限制。更大的池可以將爭用轉移到資料庫中。要求等待呼叫者或超時,確認資料庫容量並監視更改。

瞭解應用程式端邊界

這些事件回答哪個應用程式工作流程、版本、區域或面向客戶的請求遇到了資料庫症狀。它們不會取代資料庫自己的診斷系統。使用資料庫本機工具用於:

  • 查詢計劃、最佳化器估計、緩衝區和快取行為、資料表統計資訊以及清理或壓縮狀態。
  • 伺服器等待事件、鎖定圖、活動會話檢查、儲存延遲和資源飽和度。
  • 複製拓撲、預寫日誌保留、故障轉移編排、備份驗證和時間點恢復。
  • 資料庫或安全程式所需的權威稽核、存取控制、加密和合規性證據。

在調查過程中結合兩個檢視:使用結構化應用程式事件來定位影響和所有權,然後使用受限資料庫診斷來解釋伺服器端原因。避免僅僅為了方便連線而將敏感的伺服器診斷複製到廣泛的分析資料表中。

將經過驗證的查詢轉化為操作

儀表板應在每個速率旁邊保留交易量,使用完整的 UTC 儲存桶,並保留從聚合到最近安全事件的路徑。警示需要持續的條件、最小數量、所有者和記錄的回應。單個緩慢的查詢、短暫的滯後峰值或預期的回滾很少能證明頁面的合理性。

在依賴查詢之前測試合成成功、超時、死鎖、重複和延遲事件情況。在儀表板旁邊記錄事件版本和閾值。 SQL 方法論 描述了自動配方檢查; 資料庫可靠性用例 將生成的訊號連線到實施工作流程。

相關產品功能

對結構化事件資料表執行只讀 DataFusion SQL 並重用結果。

內容責任與技術參考

Telemetry 編輯團隊負責維護本文;產品團隊審查功能行為、範例和適用範圍。

檢視編輯規範