像查数据库一样查日志：炬鲸 OBSERVE 日志检索能力详解

为什么日志检索要 SQL 化

运维排查故障时，最常做的事是「从海量日志里捞出几条关键记录」。传统全文搜索靠关键词命中，遇到「找出 /api/order 接口里耗时超过 500ms 且状态码非 200 的请求」这类需求就无能为力了——要么写正则，要么把日志导到别处分析。

炬鲸 OBSERVE 的日志检索把日志当成一张表来查，支持类 SQL 语法。你不再需要记住厂商特有的查询 DSL，会写 SQL 就能上手。字段在采集时自动提取，检索时直接 WHERE、GROUP BY、ORDER BY。

这层设计的意义不在「语法更像 SQL」，而在把排查门槛降到一线同学能独立完成的高度。告警来了，值班的人自己就能查，不用再等 DBA 出数。

核心能力拆解

字段自动提取：接入日志后，系统按规则把 JSON 字段、key=value、时间戳解析成结构化字段，检索时直接引用。比如 Nginx 日志的 status、request_time、upstream_addr 都是可直接查询的字段，嵌套 JSON 也能用点号展开成 data.user.id 这种路径。

全文与结构化混查：message LIKE '%timeout%' 和 status >= 500 可以组合在一条查询里，既能模糊搜也能精确筛，不用在两种检索模式之间来回切。

聚合分析：GROUP BY 配合聚合函数（count/sum/avg/max/min）能在亿级日志上秒级出结果，不用先把数据搬到外部分析工具。

几个实用查询

排查接口慢请求：

SELECT status, avg(request_time) AS avg_rt, count(*) AS cnt
FROM nginx_access
WHERE request_time > 0.5
GROUP BY status
ORDER BY cnt DESC

定位某服务最近 1 小时报错：

SELECT * FROM app_log
WHERE level = 'ERROR'
  AND service = 'order-service'
  AND timestamp >= now() - INTERVAL 1 HOUR
ORDER BY timestamp DESC
LIMIT 100

分析调用方来源：

SELECT client_ip, count(*) AS cnt
FROM gateway_log
GROUP BY client_ip
ORDER BY cnt DESC
LIMIT 20

查询结果可以一键跳转到关联 Trace，也可以直接保存为告警条件，避免在多个页面之间来回切。

性能与资源控制建议

检索性能取决于索引设计。几条经验：

1. 高频查询字段（如 service、level、status）建索引，别对 message 这种大字段做全量索引。
2. 时间范围尽量窄，WHERE timestamp 是性价比最高的过滤条件，能加就加。
3. 大范围聚合用采样或预聚合，避免每次都对原始明细全表扫描。
4. 给查询设超时和结果上限，防止一条大查询拖慢整个集群。

日志检索的价值不在「能不能搜」，而在「能不能让一线同学独立完成排查」。把查询门槛降到 SQL，就是让告警响应不再卡在等别人出数这一步。