API error and latency monitor：實施到決策
將提示視為實施概要。有用的工件不僅僅是複製的程式碼，而是經過審查的事件契約，可以產生值得信賴的答案。
- 1
設定邊界
Instrument the point where api_request_started becomes final.
- 2
建立合約
Start with api_request_started, api_request_completed, api_request_failed and keep every field typed, bounded, and privacy-reviewed.
- 3
執行夾具
在依賴彙總結果之前，先練習已知的成功、失敗、重試和空結果案例。
- 4
回答問題
哪些路由的 p95 延遲最慢？
範本與用例
使用此範本加入事件
當測量目標已經明確時，複製此範本。使用匹配的用例指南來檢視事件邊界、成功定義以及生成的 SQL 應支援的決策。
範本
將其貼上到您的編碼代理中
更換 YOUR_API_KEY，在本地執行流程，然後驗證生成的事件和儀表板。
API錯誤和延遲監視器
將 Telemetry 新增到 API 請求處理。
使用 /skill.md 和此 Telemetry API 金鑰：YOUR_API_KEY
記錄每個重要的 API 請求：
route_template、method、status_code、status、latency_ms、user_id、team_id、request_size_bytes、response_size_bytes、error_type 和 feature。
建立請求量、錯誤率、p50 延遲、p95 延遲和主要故障端點的圖表。新增針對 5xx 峰值、慢 p95 延遲和流量下降的警示。
不要記錄請求正文、cookie、身分驗證標頭、機密或原始使用者內容。要捕獲的事件
驗證清單
完整的埋點通行證留下了什麼
活動
綜合事件以穩定的名稱和欄位型別到達預期的資料表。
查詢
第一個 SQL 查詢返回具有明確時間視窗的合理行。
意見
儀表板使用真實欄位幷包含足夠的上下文來解釋更改。
安全
檢查提示、正文、憑據、簽名和私人內容是否經過編輯。
事件結構描述範例
此工作流程的事件結構描述
在將查詢或程式碼片段適應生產之前，請檢查行粒度、發出邊界、所需型別、隱私類、範例有效負載和驗證清單。
相關產品功能
繼續此工作流程 警示
將經過審查的可靠性查詢提升到擁有的閾值和回應工作流程中。
相關 SQL 查詢範例
更多 SQL 範例
針對此工作流程中的結構化欄位執行查詢，檢查範例結果，並將有用的答案轉換為儀表板或警示。
按路由計算 API 請求吞吐量
哪些 API 路由每分鐘處理的請求最多？
開啟查詢範例測量 API 429 速率限制恢復
收到 HTTP 429 的請求重試後能否成功恢復？
開啟查詢範例計算事件檢測和恢復時間
每項服務需要多長時間來檢測事件並從事件中恢復？
開啟查詢範例按路由計算API錯誤率
在至少有 20 次請求的 API 路由中，哪些路由的 5xx 錯誤率最高？
開啟查詢範例計算 p50、p95 和 p99 API 延遲
哪些端點的尾部延遲最差？
開啟查詢範例按路由計算API超時率
哪些 API 路由超時的頻率足以影響使用者？
開啟查詢範例比較依賴性 p95 延遲
哪些下游依賴項的尾部延遲和故障率最差？
開啟查詢範例根據 SLO 衡量 API 可用性
每項服務是否達到其每日可用性目標？
開啟查詢範例計算 API 錯誤預算消耗率
API 消耗其 99.9% 可用性預算的速度有多快？
開啟查詢範例按客戶影響對錯誤指紋進行排名
哪些錯誤組影響最多的客戶帳戶？
開啟查詢範例比較功能推出錯誤率
功能標誌的推出是否不如其對照群體可靠？
開啟查詢範例按計劃衡量事件對客戶的影響
每個計劃中有多少個帳戶受到該事件的影響？
開啟查詢範例更多範本