类 SQL 日志检索：一条 SELECT 定位线上故障

为什么日志检索要“学 SQL”

查日志最大的障碍不是数据量大，而是查询语法。Elasticsearch 是 Lucene 语法，Splunk 是 SPL，Loki 是 LogQL——各有各的规则：关键词要加引号、字段要带冒号、通配符要用 *，换个平台就全忘。团队里真正会写这些语法的人，往往不超过两个，于是每次线上出问题，大家都去排队找那两个人，那两个人也就成了瓶颈。

炬鲸 OBSERVE 的日志检索选了更朴素的路：直接支持类 SQL。会写 SELECT ... WHERE ... 就能查日志，而几乎每个后端工程师都会写 SQL。它省掉的不是语法学习，而是故障排查时那几分钟翻文档、试语法的时间；而且 SQL 是团队里人人都会的语言，凌晨两点出故障时，这正是你想要的。

类 SQL 检索长什么样

在控制台里查“支付服务最近一小时的 ERROR 日志，按时间倒序取 100 条”，写成这样：

SELECT * FROM logs
WHERE service = 'pay-service'
  AND level = 'ERROR'
  AND ts > now() - 1h
ORDER BY ts DESC
LIMIT 100

当前支持的能力：

• WHERE：字段等值、范围、LIKE 模糊匹配、IN 集合
• 时间过滤：ts > now() - 1h 相对时间，或绝对时间区间
• 聚合：GROUP BY level, COUNT(*) 秒出错误分布
• ORDER BY / LIMIT / OFFSET 分页

和传统语法最大的区别：字段名就是日志里真实的字段名，不需要额外记映射表，你在原始日志里看到什么，就按什么字段过滤。

和链路追踪串起来

查到一条错误日志只是起点。定位之后，往往要顺着它看整条调用链。在检索结果里点开任意一条日志，可以直接按 trace_id 跳到链路追踪页，看到这次请求经过的每个服务、每一段耗时、每一个 Span 的状态。这个跳转不是另起一次搜索——日志行本身就带着 trace 上下文，点一下就到。

反过来，在链路追踪里发现某个 Span 报错，也能一键下钻到它打印的日志。日志与 Trace 双向跳转，是线上排查最省时间的两个动作，因为大多数故障既要日志里的“发生了什么”，也要 Trace 里的“发生在链路的哪一环”。

几条实战技巧

• 先聚合，再看明细：别急着翻逐条日志，先 GROUP BY level 或按服务聚合，看错误集中在哪。
• 用 LIKE 缩小范围：查异常堆栈 message LIKE '%NullPointerException%'，比全文搜索快得多。
• 注意默认时间窗：查询自带一个默认时间范围，太老的日志查不到，先确认时间窗。
• 存查询模板：经常用的几条 SQL 保存成模板，下次点开即用，也方便在团队里分享，让新人不用从零摸索。

底层怎么保证快

类 SQL 会先解析成结构化查询，再落到按时间分片的索引上，配合字段级别的倒排索引和列式聚合，单条查询在几十亿行日志上也能在秒级返回。查询超时会自动降级到采样模式，优先保证可用性，而不是直接报错。

类 SQL 检索不是炫技，是为了让团队里每个人都能自己查日志，而不是每次都等那个“会写查询语法的人”。