日志检索的正确打开方式：字段提取、全文搜索与检索式告警

为什么日志检索总是不顺

日志是最原始的排查手段，也是最容易失控的：格式五花八门，字段名各写各的，全文搜一遍动辄十几秒，还经常漏结果。检索不好用的根源往往不是引擎慢，而是数据没有结构化——字段没提取出来，只能靠模糊匹配，又慢又漏。

一个很常见的场景：生产环境报错，你想查「过去一小时里，支付服务返回了 5xx 的请求」。如果 status 和 service 都没有被提取成字段，你只能全文搜 500 再人工过滤，几百条日志里翻半天。字段提取做好之后，这只是一个两行查询的事。

字段提取：把文本变成可查的结构

炬鲸 OBSERVE 在采集端做字段提取，而不是查询时临时解析。常见的三种做法：

• 自动解析 JSON：日志本身是 JSON 时，自动打平嵌套字段，{"user":{"id":123}} 变成可以直接查询的 user.id。
• 正则提取：对非结构化文本定义正则，把关键信息抽成字段。以 Nginx access log 为例：

(?P<ip>\S+) .* \[(?P<time>[^\]]+)\] "(?P<method>\S+) (?P<uri>\S+) .*" (?P<status>\d+) .* (?P<upstream_time>[\d.]+)$

抽出的 status、uri、upstream_time 都能直接参与过滤和聚合。

• 字段别名：把不同服务里叫法不一的字段归一到统一名称。responseTime、cost、latency 都映射成 duration，跨服务查询就不用记三套字段名。

提取规则建议配成模板挂在日志源上，一条规则对一批日志生效，而不是查询时逐个现写。字段提取做得越早，后面的检索、告警、聚合都越省事。

全文检索与检索式告警

单靠结构化字段不够，日志里总有「说不清属于哪个字段」的内容，这时候用全文检索兜底：

level:ERROR AND service:order AND "connection reset"

先按结构化条件过滤，再在过滤后的集合里做全文匹配，比纯全文快一个数量级。查询语法支持 AND/OR/NOT、范围查询和通配符，也能按 trace_id 一键跳到对应链路，从日志直接进到调用链详情。

反复用的检索式别每次重写。保存成视图团队共享，新人点开就能看到「支付服务错误日志」这类固定视角。更进一步，把检索式挂到告警上：窗口内命中日志数超过阈值就触发。这样日志里的异常模式——某类报错突然爆发——也能变成告警信号，而不是事后翻查。

落地建议

1. 先给核心服务的日志源配好字段提取，跑一周看字段覆盖率。
2. 把高频排查场景固化成保存视图，省掉「每次现查」的时间。
3. 用检索式告警盯住已知会出事的模式，别等用户来报。

日志检索的目标是「问一次就有答案」，不是「翻半小时找到那条日志」。