用于结构化事件的 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;