API reliability monitoring：從實施到決策
完整的 api reliability monitoring 測量迴圈連線一個擁有的工作流程、一個有界事件契約、一個受控裝置和一個有人可以採取行動的問題。
- 1
設定邊界
記錄來自伺服器處理程式的已完成和失敗的 API 請求。
- 2
捕捉結果
Begin with api_request_started, api_request_completed, api_request_failed and document the grain of each event.
- 3
證明行數
建立錯誤率、p95 延遲和最失敗路由的儀表板和警示。
- 4
做出決定
哪些路由的 p95 延遲最慢？
用例與範本
選擇要衡量的內容
使用用例指南來選擇結果、事件邊界和分析問題。當您準備好接受較短的複製貼上實施簡介時，請開啟匹配的範本。
代理提示
將其貼上到您的編碼代理中
更換 YOUR_API_KEY 註冊後，然後要求代理執行產品流程並驗證第一個事件。
API reliability monitoring 設定提示
新增 Telemetry 儀器以確保 API 可靠性。
使用 /skill.md 和此 Telemetry API 金鑰：YOUR_API_KEY
請使用 route_template、method、status_code、status、latency_ms、user_id 或 team_id（如果可用）、request_size_bytes、response_size_bytes 和 error_type 記錄每個重要的 API 端點。
建立：
1. API請求事件資料表。
2. 請求量、錯誤率、p50 和 p95 延遲以及排名靠前的失敗端點的圖表。
3. 5xx 速率升高、p95 延遲緩慢和流量突然下降的警示。
不要記錄請求正文、身分驗證標頭、cookie、機密或原始使用者內容。設定步驟
- 1記錄來自伺服器處理程式的已完成和失敗的 API 請求。
- 2使用路由範本而不是原始 URL 來保持基數乾淨。
- 3捕獲狀態、延遲、方法、功能、團隊和錯誤型別。
- 4建立錯誤率、p95 延遲和最失敗路由的儀表板和警示。
要捕獲的事件
由此解鎖的問題
- 哪些路由的 p95 延遲最慢？
- 哪些客戶帳戶會受到錯誤的影響？
- 哪裡的流量突然下降或激增？
事件結構描述範例
此工作流程的事件結構描述
在將查詢或程式碼片段適應生產之前，請檢查行粒度、發出邊界、所需型別、隱私類、範例有效負載和驗證清單。
相關產品功能
繼續此工作流程 警示
將經過審查的可靠性查詢提升到擁有的閾值和回應工作流程中。
相關 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% 可用性預算的速度有多快？
開啟查詢範例按版本比較 API 可靠性
哪些版本會出現更嚴重的 API 錯誤或尾部延遲？
開啟查詢範例按客戶影響對錯誤指紋進行排名
哪些錯誤組影響最多的客戶帳戶？
開啟查詢範例比較功能推出錯誤率
功能標誌的推出是否不如其對照群體可靠？
開啟查詢範例按計劃衡量事件對客戶的影響
每個計劃中有多少個帳戶受到該事件的影響？
開啟查詢範例客戶案例
相關客戶案例
相關頁面