日志检索查询语言：把 grep 升级成结构化分析

grep 只能找日志，查不出结论

排查问题最常见的动作是打开检索框输入一个关键词，然后翻几十页日志。关键词搜索能回答「有没有」，回答不了「多少、多频繁、谁最慢、什么趋势」这类问题。而这些恰恰是定位根因需要的信息。

炬鲸 OBSERVE 的查询语言做的事很简单：像 Unix 管道一样，把一次检索拆成过滤、提取、聚合、排序、可视化几个步骤，前一步的输出是后一步的输入。一条查询既能查出数据，也能直接算出结论。

管道语法：五步走完一次排查

查询从数据源和过滤开始，逐步收敛：

source="order-service"
| level != "debug"
| parse json
| stats count() by status, error_type
| sort -count

这条查询的含义：取 order-service 的日志，过滤掉 debug，解析 JSON 字段，按 status 和 error_type 分组计数，再按计数倒序排列。几秒钟就能看出「哪个状态码、哪种错误最多」。

管道运算符不多，常用的就几个：

• parse：从原始文本里提取结构化字段
• stats：聚合，支持 count、sum、avg、p99、distinct 等
• where：条件过滤
• sort / top：排序、取前 N
• timechart：按时间分桶画趋势

字段提取：让日志从文本变成数据

全文检索的天花板在字段。日志里明明写着「耗时 230ms」「用户 ID 10023」，但 grep 只把它们当字符串。用 parse 把这些值提取成字段后，就可以聚合、比较、告警了：

source="order-service" level="error"
| parse "took *ms" as latency
| parse "user_id=*" as user_id
| stats avg(latency) by user_id

提取出来的字段进入平台的字段库，之后检索、告警、仪表盘都能直接引用，不用每查一次都重新解析。

把好查询沉淀成资产

查过一次的好查询，别用完就丢。炬鲸 OBSERVE 支持把查询保存为模板、设置参数占位符，团队共享；也能直接把查询固化成告警规则或仪表盘图表。

几个建议：

1. 高频排查场景（比如「某服务最近的报错分布」）固化成模板，值班时一键出结论
2. 把字段提取写进采集规范，统一字段名，避免 user_id 和 userId 各写一套
3. 聚合类查询加时间范围，避免全量扫描拖慢集群

查询语言的本质是把排查经验固化成可复用的资产，而不是每次从零开始翻日志。