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

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

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

本頁內容
  1. 警示輸入模型:一個時間序列訊號
  2. 評估順序
  3. 儲存的查詢和探索源
  4. 最新點排除
  5. 點選擇和聚合
  6. 狀態轉換和通知
  7. 併發和宣告行為
  8. 故障排除清單
  9. 解釋邊界

Telemetry 如何評估 SQL 警示

有用的警示不僅僅是圖表上附加的閾值。評估者必須決定查詢何時到期、執行哪個 SQL、計算哪些行、如何將這些行減少到一個值、狀態是否更改以及何時通知。

本指南記錄了 Telemetry 實施的評估路徑。它是可檢查的行為描述,而不是正常執行時間、延遲或交付保證。

警示輸入模型:一個時間序列訊號

Telemetry 的警示建立工作流程有意從一行開始:一個有序的時間軸、一個數值軸,並且沒有分組或分割維度。探索需要沒有分割的折線圖。 SQL 結果需要折線圖,其中具有明確的時間 x 軸、數字 y 軸,並且 分組依據設定為

此約束使評估者的輸入易於理解。每個結果行都是一個時間點,所選指標具有一種含義和單位,設定的閾值會產生一種警示狀態。多系列結果將需要額外的策略:是否任何或所有系列控制狀態,每個系列是否擁有獨立的歷史記錄,通知如何分組,以及丟失或新出現的系列意味著什麼。 Telemetry 避免隱式發明這些語義。

計算訊號的SQL仍然可以很複雜。它可以連線資料表、過濾特定服務或路線、計算比率或強制執行最小樣本量。暴露給警示的最終結果應該很簡單:一個時間段和每行一個數字訊號。在儀表板上保留分組比較,或者在每個組都有自己的閾值、所有者和回應時建立單獨的警示。

評估順序

評估器使用鏈式一分鐘排程迴圈。每個通道都會載入已啟用的警示,與隔離的故障處理同時評估它們,記錄通道結果,並在當前通道完成後安排下一個通道。一分鐘迴圈是輪詢節奏;每個警示仍然有其自己設定的間隔。

對於每個啟用的警示:

  1. 檢查警示是否是從其上次評估時間和設定的時間間隔開始的。
  2. 使用當前版本宣告警示,以便其他評估者無法同時宣告相同版本。
  3. 解析查詢:使用精確儲存的 SQL 來獲取支援查詢的警示,或從儲存的探索設定重新生成 SQL。
  4. 拒絕包含寫入語句的支援查詢的 SQL。
  5. 執行查詢並檢查結果列和行。
  6. 當最新行代表不完整的時間段時,可以選擇刪除它。
  7. 獲取設定的最近點數量並將它們聚合為一個觀察值。
  8. 將該值與閾值和運算子進行比較。
  9. 儲存新狀態、觀測值、評估時間和任何受控誤差。
  10. 僅在狀態轉換時新增歷史記錄並嘗試傳送電子郵件。

排除故障時此順序很重要。有效的查詢仍然不會產生可用值,可用值可以保持在閾值以下,並且當警示已經觸發時,違反閾值可以保持沉默。

儲存的查詢和探索源

支援查詢的警示執行與警示一起儲存的 SQL。評估器不會默默地將其替換為更新的查詢修訂版。當儀表板和警示出現不一致時,請檢視附加到警示的 SQL。

Explore 支援的警示儲存 Explore 設定並透過 Explore 使用的相同查詢建置邊界重新生成 SQL。因此,對架構、過濾器、分組或聚合的更改可能會影響儲存的設定是否仍然可以解析。

對於支援查詢的警示,拒絕面向寫入的語句。警示旨在觀察結果,而不是改變資料表或管理狀態。即使 SQL 是隻讀的,也要保持警惕,SQL 受時間和結果大小的限制。

最新點排除

時間桶查詢通常首先返回當前的、不完整的桶。將部分分鐘或小時與完整歷史儲存桶進行比較可能會產生錯誤的恢復或錯誤的違規訊號。

exclude latest incomplete point 啟用時,評估器首先對最新的行進行排序,並在選擇設定的點數之前刪除最新的結果行。僅當每行真正代表一個時間段並且最新行不完整時,該設定才是正確的。

不要為單行聚合啟用它,例如:

SELECT
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '15 minutes';

刪除唯一的行不會留下任何可評估的值。對於時間序列,返回一個顯式儲存桶列和一個數值列:

SELECT
  date_bin(INTERVAL '5 minutes', completed_at, TIMESTAMP '1970-01-01') AS bucket,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '35 minutes'
GROUP BY bucket
ORDER BY bucket DESC;

點選擇和聚合

最新點處理後,評估器將獲取設定的最近行數。它提取選定的數值並使用警示聚合設定減少這些點。

當 SQL 已經計算出完整的決策視窗時,使用單點。當警示有意需要跨多個儲存桶進行持久化時,請使用多個點。聚合應與操作問題相匹配:

  • maximum 詢問是否有任何選定點被破壞。
  • minimum 詢問每個選定點是否位於樓層之上。
  • average 平滑了短暫的變化,但可以隱藏一個嚴重的點。
  • sum 適合非重疊桶中累積的計數。
  • latest使用最新的剩餘完整點。

在回應過程中記錄此選擇。 “失敗率高於 5”是不明確的,除非團隊知道這是否意味著最近五分鐘的時間段、三個時間段的平均值或這些時間段的最大值。

狀態轉換和通知

Telemetry 將警示狀態與單個評估分開儲存。成功評估可產生okfiring;執行、提取或設定問題會產生錯誤結果。

歷史記錄和通知是面向過渡的。從 okfiring 的移動會建立觸發轉換。從 firingok 的移動會建立解析度轉換。同一狀態下的重複評估會更新評估記錄,而無需在每次輪詢時傳送相同的轉換電子郵件。

該評估員當前的通知傳送方式是電子郵件。儲存狀態轉換後嘗試傳送。傳送失敗不能消除警示已轉換的事實,這就是為什麼應單獨調查警示歷史記錄和電子郵件傳送的原因。

併發和宣告行為

每個警示均使用其當前版本以樂觀併發方式宣告。如果版本已更改或其他評估者已宣告該版本,則宣告不會成功。這可以防止兩個評估者故意同時處理相同的警示版本。

排程程式使用已確定的承諾來評估已啟用的警示集,因此一個被拒絕的警示不會阻止該通道中其餘警示的完成。該迴圈僅在當前傳遞完成後才安排下一個傳遞,從而避免一個處理程序內的重疊傳遞。

這些控制解釋了評估者的行為;它們不是分散式服務可用性宣告。部署拓撲、流程重新啟動、電子郵件提供商行為和未來的實施更改仍然屬於操作審查。

故障排除清單

當警示未按預期執行時:

  1. 執行附加的 SQL 並確認它是隻讀的。
  2. 檢查所選值列是否為數字並且存在於每個相關行中。
  3. 檢查結果排序;最新點邏輯取決於知道哪一行是最新的。
  4. 確認查詢返回的是一行聚合還是多個時間段。
  5. 一起回顧 exclude latest incomplete point、點數和聚合。
  6. 驗證運算子和閾值使用與所選值相同的單位。
  7. 檢查警示歷史記錄以瞭解最近的狀態轉換和受控錯誤。
  8. 將查詢/評估失敗與電子郵件傳送失敗分開。
  9. 確認警示已啟用,並且其設定的時間間隔已經過去了足夠的時間。
  10. 在閾值兩側使用合成事件固定裝置進行測試。

對於特定於交付的調查,請繼續 警示傳送故障排除。對於事件和查詢設計,請使用 警示建立您的第一個儀表板和警示

解釋邊界

評估者可以一致地執行設定的決策,但無法決定業務定義是否正確。事件粒度、分母、時間視窗、閾值、缺失資料策略和回應所有者仍然是警示合約的一部分。

在架構更改、查詢編輯、版本更改、流量變化和事件回顧後重新審查警示。具有過時閾值或分母的技術上有效的警示仍然是不可靠的警示。

相關產品功能

將審查的 SQL 提升到自有閾值和回應工作流程中。

內容責任與技術參考

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

檢視編輯規範