日志管道：字段抽取与富化规则实战

为什么一条日志要先过管道

原始日志往往是一长串文本，级别、耗时、用户 ID、业务状态码全都挤在一行里。排查问题时如果只能全文模糊匹配，索引会膨胀，检索会变慢，聚合也基本算不出来——你没法对"把 level 和 status 拼在一个字符串里"的数据做统计。

炬鲸的日志管道在写入前对每条日志做一次解析，把文本拆成结构化字段。之后的过滤、统计、告警、下钻全部基于这些字段，而不是靠正则硬扫全文。这就是"查日志"和"查数据"的分界线。

内置解析器与自定义 Grok

炬鲸内置了 Nginx、Apache、JSON、Syslog 等常用格式的解析器，选中即用。JSON 日志会自动展平嵌套字段，{"user":{"id":1001,"region":"cn"}} 会变成 user.id、user.region 两个可直接过滤的字段，不用手写路径。

私有格式则用 Grok 表达式写抽取规则。以一条 Java 应用日志为例：

%{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} \[%{DATA:thread}\] %{DATA:logger} - %{GREEDYDATA:message}

配好之后，这样一行：

2026-10-13 09:00:01 ERROR [http-nio-8080] c.j.order.OrderSvc - 库存不足, sku=1001

会被拆成 ts、level、thread、logger、message 五个字段。随后用 level:ERROR AND logger:OrderSvc 就能精确定位，还能按 level 直接做柱状聚合，查询里一个正则都不用写。

字段富化：字典映射与 GeoIP

抽取只是第一步。富化能把字段翻译成可读信息，省掉查询时的关联计算：

• 内部状态码 0/1/2 通过字典映射成"成功/失败/超时"，大盘显示的是文字而不是魔法数字；
• 来源 IP 走 GeoIP 库补上省份、运营商，方便按地域看报错分布；
• userId 关联部门表打上业务标签，告警时直接带上"哪个团队的哪个服务"。

富化发生在写入阶段，查询侧不用再做 join，检索延迟更低，大盘渲染也更快。成本在入库时付一次，而不是每次查询都付。

落地建议与三个坑

先说三个常见的坑：

1. 抽取规则先在少量样本上跑通再全量启用。一条写错的 Grok 会让解析失败率飙升，失败记录可能被丢进死信队列，反而更难看。
2. 字段名统一小写并约定命名规范。level 和 Level 同时存在时，聚合会分叉，告警条件也会漏。
3. 高基数字段（requestId、traceId、userId）只建精确匹配索引，不要分词。否则索引体积和内存占用会失控。

管道配置建议纳入版本管理：改规则前先在影子通道回放一天历史日志，对比解析成功率与字段分布，确认无误再切换生产。发现异常时回滚一条规则配置即可，不用重刷历史数据。这样改规则才不是"上线即赌"。