建立您的第一個儀表板和警示

儀表板應保留經過審查的答案。警示應識別具有所有者和有用回應的狀況。不要僅僅因為其圖表看起來合理而推廣未經驗證的查詢。

本演練從 編寫第一個 Telemetry SQL 查詢 中的請求量和錯誤率 SQL 開始。

建立一個面向決策的小工具

在 Telemetry 中執行查詢，選擇與結果匹配的圖表，然後選擇“新增到儀表板”。

對於 API 錯誤率結果：

• 當時間是主要維度時，請使用折線圖。
• 比較一小組路線範本時使用條形圖。
• 當精確值、數量閾值和多個度量必須保持可見時，請使用表格。

在決定之後命名小工具，而不是實施。 “按路由劃分的 API 伺服器錯誤率”比“查詢 7”更清楚。

保持分母可見。在一個請求中出現 1 個錯誤的路由不應默默地超越在 10,000 個請求中出現 500 個錯誤的路由。包括請求量和錯誤百分比，或在 SQL 中強制執行最小量條件。

保持第一個儀表板較小

有用的第一可靠性儀表板可能包含：

1. 隨著時間的推移請求量。
2. 隨著時間的推移，伺服器錯誤百分比。
3. 按路線劃分的 p95 延遲。
4. 主要錯誤類別或指紋。
5. 僅當存取獲得批准時才會顯示受影響帳戶的資料表。

每個小工具應連結回可檢查的行或儲存的 SQL。避免在多種圖表樣式中重複相同的指標。

請參閱 建立儀表板 瞭解佈局和所有權指南。

建立有界警示

從一根時間序列線開始：x 軸上的時間，y 軸上的一個數字指標，並且沒有分組或拆分。 Telemetry 僅為這一狹窄圖表形狀提供建立警示，因為閾值、最近點視窗、狀態和通知均涉及一個有序訊號。分組圖表會讓人不清楚是否有任何一條線、每條線或每條線獨立控制警示。

在儀表板上保留多行比較。對於警示，過濾到一個群體，故意聚合組，或者在組需要不同的閾值或所有者時建立單獨的警示。請參閱 警示 瞭解完整的原理和範例。

開啟經過驗證的單線圖或查詢結果，然後選擇“建立警示”。定義：

• 聚合和測量。
• 最後評估的資料點數量。
• 比較和閾值。
• 評估區間。
• 是否忽略不完整的最新儲存桶。
• 擁有回應的接收者。

對於綜合開發表，從非尋呼電子郵件警示開始。生產範例可能是：

p95 of the last 5 completed data points is greater than 850 ms

或：

server_error_pct is greater than 5% and requests is at least 100

確切的閾值取決於服務目標、流量模式和回應策略。複製的數字不能替代基線。

測試兩邊的條件

傳送受控合成事件應該：

1. 將警示保持在閾值以下。
2. 將結果移至閾值以上。
3. 向預期收件人發出通知。
4. 恢復後返回閾值以下。

記錄查詢、閾值、收件人和回應連結。然後從生產報告中刪除或明確隔離合成行。

定義回應

每個警示都需要一個簡短的操作：

• 開啟相關儀表板。
• 檢查受影響的路由、版本和帳戶。
• 與請求或工作流程識別符號關聯。
• 決定是否緩解、回滾或繼續觀察。
• 分別記錄恢復時間和客戶影響。

有關警示行為和故障排除，請閱讀 警示 和 警示傳送和故障排除。在廣泛部署儀器之前，請完成 生產環境插樁清單。