編寫第一個 Telemetry SQL 查詢
從一個問題開始，您可以從已知的合成行中驗證其答案。本演練查詢在前面的入門步驟中建立的 api_request_completed 資料表。
檢查最近的行
從事件粒度而不是聚合開始：
SELECT
timestamp_utc,
request_id,
route_template,
status_code,
latency_ms,
release,
environment
FROM api_request_completed
WHERE environment = 'development'
ORDER BY timestamp_utc DESC
LIMIT 100;
找到合成的 req_demo_001 行。如果缺失或輸入錯誤，請返回 驗證事件攝取和架構。
計算請求量和錯誤
一旦原始行看起來正確，就在路由粒度處聚合：
SELECT
route_template,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS server_errors,
ROUND(
100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0),
2
) AS server_error_pct
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'development'
GROUP BY route_template
ORDER BY requests DESC;
分母是同一時間視窗內每條路線的請求量。如果查詢稍後適應連線或使用空桶生成時間脊柱，NULLIF 會保護該劃分。
僅在檢查裝置後新增延遲
SELECT
route_template,
COUNT(*) AS requests,
approx_percentile_cont(0.5) WITHIN GROUP (ORDER BY latency_ms)
AS p50_latency_ms,
approx_percentile_cont(0.95) WITHIN GROUP (ORDER BY latency_ms)
AS p95_latency_ms
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'development'
GROUP BY route_template
ORDER BY p95_latency_ms DESC;
在解釋百分位數之前，請確認 latency_ms 是數字並且始終以毫秒為單位進行測量。請閱讀 SQL 百分位數 瞭解稀疏組、近似函式和樣本大小注意事項。
儲存前驗證
使用一個帶有已知成功和失敗請求的小裝置。手動計算預期請求數和錯誤率，然後與 SQL 結果進行比較。
檢查四件事：
- Grain： 一行代表一個已完成的請求。
- 分母： 故意包含或排除重試和內部流量。
- **視窗：**最新的不完整桶不與完整桶進行比較。
- 維度： 路由範本、版本和環境使用穩定值。
有效的SQL仍然可以回答錯誤的業務問題。將定義和排除與查詢一起儲存。
繼續
使用 API 錯誤率配方 獲得完整的架構、夾具、視覺化和警示推薦。要在連線的合成資料庫上進行練習，請開啟 SaaS SQL實驗室。然後繼續 建立您的第一個儀表板和警示。