用 SQL 查日志：炬鲸 OBSERVE 日志检索能力详解

为什么用 SQL 查日志

日志排查最耗时的往往不是“找到问题”，而是“从几十万行日志里捞出那几行关键记录”。关键字搜索只能告诉你某条日志存不存在，回答不了“过去 1 小时 5xx 错误按服务如何分布”“某个 traceId 下耗时最长的 span 是哪个”这类问题。

炬鲸 OBSERVE 的日志检索底层是列式存储，对外提供类 SQL 查询语法，直接写 SELECT、WHERE、GROUP BY 就能过滤、聚合、排序、跨字段关联，一条排查思路可以直接落成一条查询语句。

语法与常用操作符

语法和标准 SQL 高度一致，字段直接写名字（level、service、trace_id、status_code），配合操作符：

• 比较：= != > < >= <=；模糊：LIKE 'payment%'，支持 % 和 _ 通配符
• 范围：status_code IN (500, 502, 503)、latency BETWEEN 1000 AND 5000
• 正则：message REGEXP 'timeout|refused'
• 逻辑：AND、OR、NOT，括号控制优先级

聚合与管道函数

聚合是日志检索最常用的场景，GROUP BY 加聚合函数直接得到分布：

SELECT service, count(*) AS err_count
FROM logs
WHERE level = 'ERROR' AND timestamp >= now() - 900
GROUP BY service
ORDER BY err_count DESC

管道函数处理统计与时序：histogram(timestamp, '1m') 按分钟分桶、percentile(latency, 99) 算 P99、topk(5, count) 取前 5，一次查询同时拿到趋势和异常点。

三个可直接套用的排障查询

按接口统计慢请求：

SELECT path, avg(latency) AS avg_ms, percentile(latency, 99) AS p99
FROM logs
WHERE latency > 1000 AND timestamp >= now() - 1800
GROUP BY path
ORDER BY p99 DESC

沿 traceId 还原调用链：

SELECT timestamp, service, span_name, duration_ms
FROM logs
WHERE trace_id = '8f3a2c...'
ORDER BY timestamp

找出突增的异常日志：

SELECT error_type, count(*) AS n
FROM logs
WHERE level = 'ERROR' AND timestamp >= now() - 300
GROUP BY error_type
HAVING n > 20

实践建议：把高频排障场景固化成“保存的查询”，出问题时点一下就能出结果。检索框支持命令历史和语法补全，团队可共享查询模板。聚合查询务必带上时间范围，避免全表扫描拖慢检索。