用於結構化事件的 SQL 查詢 API

它是如何運作的

從訊號到決策的可審查工作流程

從一個決定開始

在選擇列之前寫下操作或產品問題。一個集中的問題會產生一個可以解釋和維護的查詢。

檢查結果，而不僅僅是語法

檢查體積、空值、時間視窗、分母和意外組。 SQL可以成功執行，但仍然回答錯誤的問題。

當查詢有用時儲存它

將重複分析轉變為命名查詢、儀表板小工具、匯出或警示，這樣團隊就不會在每次事件期間重新建立它。

在Telemetry中編寫和執行SQL

真實查詢編輯器、自動完成、結果資料表和圖表工作流程的簡短捕獲。

邊界

這不能取代什麼

有效的查詢仍然可能編碼錯誤的分母、連線、時間邊界或業務定義；應審查儲存的分析。
互動式查詢 API 專為分析而設計，而大型提取應使用非同步匯出路徑。
Telemetry 公開 DataFusion SQL，因此來自另一個儲存庫的引擎特定函式可能需要等效表示式。

可檢查的證明路徑

從事件契約到可見的答案

此範例使用宣告的架構、只讀 SQL 和確定性合成結果。它示範了工作流程，但沒有提供範例資料作為客戶基準。

1. 活動合約

一排進入 api_requests，並明確查詢所使用的型別。

timestamp_utc: Timestamp
route_template: Utf8
latency_ms: Float64
status_code: Int64

瀏覽活動合約

2.只讀SQL

哪些端點的尾部延遲最差？

SELECT
  route_template,
  COUNT(*) AS requests,
  approx_percentile_cont(latency_ms, 0.50) AS p50_ms,
  approx_percentile_cont(latency_ms, 0.95) AS p95_ms,
  approx_percentile_cont(latency_ms, 0.99) AS p99_ms
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
  AND status_code < 500
GROUP BY route_template
HAVING COUNT(*) >= 50
ORDER BY p95_ms DESC
LIMIT 10;