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

日志平台的检索语法好不好用，往往决定了故障排查的快慢。炬鲸 OBSERVE 把检索设计成贴近 SQL 的写法，让熟悉数据库的人几乎零成本上手。这篇文章讲清楚核心语法，并给出几个高频场景的现成查询。

字段过滤与全文匹配

每条日志在接入时会被解析成字段，比如 level、service、trace_id、status。这些字段来自接入层的解析规则（JSON、键值、正则），一条日志能拆出几十个可查字段。字段过滤用 field = value 的形式，全文匹配直接用关键词。几个常用写法：

level = "ERROR" AND service = "order-api"
message CONTAINS "timeout"
trace_id = "8f3a2c1d9e7b..."
status IN (500, 502, 503)

支持 =、!=、>、<、>=、<=、CONTAINS、IN (...) 等操作符，多个条件用 AND / OR / NOT 组合，括号控制优先级。字符串值建议加引号，避免和关键字冲突。字段名区分大小写，查询结果为空时，先确认该字段是否真的存在于当前日志源的解析 schema 里。

管道聚合：从明细到结论

光有过滤还不够，排查时经常需要"先统计再下钻"。炬鲸 OBSERVE 提供管道语法，用 | 把多个阶段串起来：

service = "order-api" AND level = "ERROR"
| stats count() by error_code
| sort count desc
| limit 10

这条查询先过滤出 order-api 的报错，按 error_code 分组计数，再按数量倒序取前 10。stats 不止有 count()，avg()、p50()、p99()、sum()、distinct_count() 都能用。相比把日志导出来再用脚本处理，管道聚合直接在服务端完成，几十亿条日志也能在秒级返回。

三个高频排查场景

按 trace_id 串起整条调用链：报错后拿到 trace_id，用它检索所有关联日志，再加 | sort timestamp asc 按时间还原一次请求的完整路径。

定位慢请求：| stats avg(latency) by endpoint | sort avg desc，一眼看出哪个接口拖慢整体。健康检查若污染数据，可加过滤条件排除。

看错误分布：| stats count() by level | sort count desc，快速判断问题是集中在某处还是全面爆发。

把查询变成告警和大盘

检索页里任何一条查询，都能一键固定到大盘或转成告警规则。比如把"按接口统计 P99"固定到服务大盘，每次刷新自动更新；把错误率查询挂上阈值做成告警，就能在客户感知前收到通知。检索、大盘、告警共用同一套语法，学一次到处用，告警条件就是你测试过的那条查询，不存在"翻译"带来的偏差。

性能建议

检索前先想清楚"我要找什么"，用最窄的字段过滤锁定范围；能用等值过滤就不用 CONTAINS；聚合时把过滤条件放在管道最前面，减少下游数据量。高基数字段上滥用 CONTAINS 是慢查询的头号来源，如果经常要用，不如加一条解析规则把该值单独抽成字段。把这些习惯练熟，线上问题排查能省下一大半时间。