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

为什么日志检索要用 SQL

日志排查最常见的场景是「我大概知道发生了什么，但要在一堆结果里筛出关键几行」。传统全文检索能查关键词，但做不了跨字段的条件组合，也做不了统计聚合。炬鲸 OBSERVE 的日志查询引擎直接引入类 SQL 语法，让运维和开发用熟悉的 WHERE、GROUP BY 完成检索与聚合，不用再学一套查询语言。

基础查询

日志写入时会自动解析出结构化字段，例如 level、service、host、trace_id 和时间戳。直接写条件即可：

SELECT * FROM logs
WHERE service = 'order-service'
  AND level = 'ERROR'
  AND timestamp > now() - interval '15 minute'

支持 =、!=、LIKE、IN、BETWEEN 和正则 REGEXP 等操作符，多个条件用 AND/OR 组合。字段值区分大小写，字符串字面量需要加单引号。

聚合与统计

想知道错误集中在哪个服务、哪台主机，用 GROUP BY：

SELECT service, count(*) AS cnt
FROM logs
WHERE level = 'ERROR'
  AND timestamp > now() - interval '1 hour'
GROUP BY service
ORDER BY cnt DESC
LIMIT 10

这类查询比「肉眼翻几百条日志」快得多，也是告警收敛的第一步：先聚合出热点，再下钻到具体 trace。

全文检索与字段提取结合

纯关键词搜索仍然可用，message LIKE '%timeout%' 或全文检索即可。更实用的是查询时做字段提取，把半结构化日志里的关键值抽出来当作筛选条件：

SELECT * FROM logs
WHERE service = 'payment-service'
  AND message REGEXP 'card_no=[0-9]{4}'

配合自动脱敏，敏感字段在结果里会被打码，检索能力不受影响。

实践建议

把常用查询保存为视图或快捷搜索，按「错误 TOP 服务」「慢请求 TOP 接口」「某 trace 全链路日志」分组。新同事不用从零写 SQL，点一下模板就能定位到最近的异常。也可以给 GROUP BY 的结果加 HAVING cnt > 5 过滤噪声，只保留真正值得看的热点。