像写 SQL 一样查日志：炬鲸 OBSERVE 日志检索详解

为什么需要结构化日志检索

排障最怕两件事：日志散落在几十台机器上，以及只能靠关键词模糊匹配。grep 能解决"找到含某关键字的行"，但当你要"找出最近 10 分钟响应超过 2 秒的 /api/order 请求"时，grep 就开始吃力了。炬鲸 OBSERVE 把日志当表来查，用类 SQL 语法做过滤、聚合、排序，一行语句顶几十行脚本。

检索语法速览

OBSERVE 支持 SELECT ... WHERE ... GROUP BY ... ORDER BY 的管道写法。内置字段有 timestamp、level、service、trace_id、message，以及接入时声明的自定义字段，如 user_id、order_id、cost_ms。几个高频查询：

-- 查错误日志
SELECT * FROM log WHERE level = 'ERROR' AND service = 'order-service'
ORDER BY timestamp DESC LIMIT 100

-- 按状态码聚合
SELECT status, count(*) AS cnt FROM log
WHERE service = 'gateway'
GROUP BY status ORDER BY cnt DESC

-- 找慢请求
SELECT trace_id, cost_ms, path FROM log
WHERE cost_ms > 2000 ORDER BY cost_ms DESC LIMIT 50

字段名大小写不敏感，* 返回全部字段。时间范围由界面时间选择器控制，SQL 只负责过滤与聚合，避免在查询里手写时间戳。

索引与性能

检索快慢取决于索引。OBSERVE 对 level、service、trace_id 等高频字段自动建索引，对文本字段做倒排索引支持全文匹配。两点建议：

• trace_id、order_id 这类高频过滤字段，接入时声明为索引字段，查询走索引而非全表扫描。
• 全文搜索用 message CONTAINS '关键字'，比 message LIKE '%关键字%' 更快，前者走倒排索引。

对于 JSON 格式的结构化日志，OBSERVE 会自动展开嵌套字段，可以直接用 request.headers.user_agent CONTAINS 'bot' 这种路径写法下钻，不必先做二次解析。另外要注意字段基数：每条都不同的原始请求 ID 索引成本高、过滤价值低，只给真正会过滤的字段建索引。实测在 10 亿条日志规模下，带 trace_id 的等值查询稳定在 1 秒内返回；不带条件的全表扫描会慢很多，务必用字段过滤先缩小范围。

检索结果与告警联动

查询结果可导出 CSV，也能"保存为视图"固化常用查询。视图有两个用途：作为仪表盘数据源，或作为告警规则数据源——比如"过去 5 分钟 ERROR 日志超过 100 条就触发告警"。这样日志检索就从人工排障工具，变成告警链路的一环，值班同学在告警详情里能直接点开对应的日志视图，顺着 trace_id 一路查下去，也省掉了新同学反复摸索常用查询的时间。