用 SQL 查日志：炬鲸 OBSERVE 的检索引擎设计

为什么用 SQL 查日志

日志检索工具最大的问题是每家一套查询语法。Lucene、DSL、自定义表达式，新同事上手先翻半天文档，写错一个括号又得从头查。炬鲸 OBSERVE 把日志当成一张宽表，直接用工程师最熟的 SQL 来查。SELECT、WHERE、GROUP BY、ORDER BY、LIMIT 全部可用，会写 SQL 就会查日志，培训成本几乎为零。

更重要的是，SQL 意味着日志存储背后是一个真正的查询引擎——有执行计划、有索引、有可预期的开销，而不是一个偶尔超时的关键字搜索框。深夜值班时，这种可预期性比什么都值钱。

基础查询

最简单的排查从一条 SELECT 开始：

SELECT * FROM logs
WHERE level = 'ERROR'
  AND service = 'order-service'
  AND timestamp >= now() - interval '1 hour'
ORDER BY timestamp DESC
LIMIT 100;

字段覆盖时间戳、级别、服务名、trace_id、span_id、主机名、容器名、消息内容，以及日志里的任意 JSON 结构化字段。操作符支持 =、!=、LIKE、IN、BETWEEN，正则用 REGEXP。比如查所有包含超时关键字的慢查询日志：

SELECT timestamp, host, message
FROM logs
WHERE message REGEXP '(timeout|timed out)'
  AND service = 'payment-service'
ORDER BY timestamp DESC;

结构化字段支持是隐藏的杀手锏。现在大多数应用以 JSON 输出日志，逐字段可查意味着可以直接用 status_code = 500 或 user_id = 42 过滤，不必写正则硬抠。

聚合统计

排障时真正要回答的是"这个错误出现了多少次、集中在哪个节点、什么时候开始爆发"。这些用聚合一句话搞定：

SELECT host, count(*) AS cnt
FROM logs
WHERE level = 'ERROR'
  AND timestamp >= now() - interval '5 minute'
GROUP BY host
ORDER BY cnt DESC;

按时间桶聚合直接画出错误趋势曲线：

SELECT time_bucket('1 minute', timestamp) AS t, count(*) AS cnt
FROM logs
WHERE level = 'ERROR'
GROUP BY t
ORDER BY t;

不用再把数据导出到 Excel 画图，前端直接把聚合结果渲染成图表，保存成视图后还能作为看板面板持续刷新。

跨数据关联

日志、指标、链路共享同一个查询引擎，这是 SQL 化最大的收益。拿到一个 trace_id，一条 SQL 同时捞出链路上的所有日志和 span：

SELECT 'log' AS type, timestamp, message
FROM logs WHERE trace_id = 'a1b2c3'
UNION ALL
SELECT 'span' AS type, start_time, name
FROM spans WHERE trace_id = 'a1b2c3'
ORDER BY timestamp;

过去要在日志、链路两个页面来回跳，脑子里重建时间线；现在一次查询拿到完整上下文，定位故障路径从十几分钟缩到一两分钟。

实践建议

• 高频查询存成视图，团队共享，避免每个人重复写同样的 SQL。
• 查日志先按 trace_id 或 request_id 过滤，再放大时间窗口，比盲目翻页效率高得多。
• 用 LIMIT 控制返回行数，大结果集交给聚合语句，不要让页面渲染十万行。
• 慎用 REGEXP：高 QPS 服务上前导通配的正则扫描的数据量远大于结构化字段过滤。