求适配Kibana传入日志的GROK模式，实现rest字段拆分与过滤

前置解析逻辑 #

整条例日志是标准JSON结构，Elasticsearch Ingest Pipeline可先通过内置json处理器直接抽取外层字段（@timestamp、severity、service、thread、class等），核心需要自定义GROK规则的是rest字段承载的结构化业务日志，无需重复在外层匹配JSON文本，降低解析性能损耗。

待解析的rest字段原始内容：[SmsListener] [sendSMS] [63289e8d-13c9-4622-b1a1-548346dd9427] [synemail] [ABSENT] [synfi] [0:0:0:0:0:0:0:1] [N/A] [N/A] [End Method]

字段拆分对应关系 #

按照rest字段内方括号包裹的分段顺序，拆分后的结构化字段如下：

• log_component：日志所属组件标识（样例值SmsListener）
• business_method：当前执行的业务方法名（样例值sendSMS）
• trace_id：全链路追踪ID（样例值63289e8d-13c9-4622-b1a1-548346dd9427）
• sms_channel：短信发送通道标识（样例值synemail）
• process_status：短信处理结果状态（样例值ABSENT）
• source_system：请求来源系统标识（样例值synfi）
• client_ip：请求发起方IP地址（样例值0:0:0:0:0:0:0:1）
• ext_field1：第一类预留扩展字段（样例值N/A）
• ext_field2：第二类预留扩展字段（样例值N/A）
• method_phase：方法执行阶段标记（样例值End Method）

可直接落地的GROK模式 #

为兼容段间多空格、字段无特殊字符的通用场景，基础匹配规则如下：

\[%{DATA:log_component}\]\s*\[%{DATA:business_method}\]\s*\[%{DATA:trace_id}\]\s*\[%{DATA:sms_channel}\]\s*\[%{DATA:process_status}\]\s*\[%{DATA:source_system}\]\s*\[%{DATA:client_ip}\]\s*\[%{DATA:ext_field1}\]\s*\[%{DATA:ext_field2}\]\s*\[%{DATA:method_phase}\]

精准度优化调整 #

可针对特定字段替换通用DATA Pattern，提升匹配准确率、减少误识别：

• 将trace_id段的%{DATA:trace_id}替换为%{UUID:trace_id}，精准匹配标准UUID格式的链路ID
• 将client_ip段的%{DATA:client_ip}替换为%{IP:client_ip}，同时兼容IPv4、IPv6格式的IP地址校验
• 可根据实际业务枚举值，给process_status增加正则约束，仅识别合法状态值（如ABSENT、SUCCESS、FAILED等）

拆分后的业务过滤场景 #

每个拆分出的字段可直接在Kibana筛选栏配置对应过滤规则，匹配日常业务判定需求：

• 按process_status筛选：快速定位所有处理状态为ABSENT的短信发送异常日志
• 按trace_id筛选：通过指定链路ID拉取单次短信发送请求的全链路日志
• 按sms_channel筛选：分通道统计短信发送成功率、异常占比
• 按client_ip筛选：定位异常来源IP的高频调用请求

内容的提问来源于stack exchange，提问作者user3907963