非贪婪模式下多行正则匹配日志截断问题求解（Fluent Bit环境）

问题根因 #

匹配截断由三个规则冲突共同导致：

• 原正则message分组使用的.*默认 不匹配换行符，即使开启multiline模式，.的匹配范围也不包含换行，遇到换行符就会终止匹配
• 全局开启Ungreedy（非贪婪）模式时，量词会尽可能匹配最短内容，就算替换.为可匹配换行的写法，也会在第一个换行位置直接停止，不会向后扫描到下一条日志的起始位置
• 原正则末尾的$锚点在multiline模式下会匹配任意换行符位置，进一步把匹配范围限制在单条换行之前，无法覆盖多行内容

适配Fluent Bit的可用正则 #

由于(?-U)修饰符会导致Fluent Bit崩溃，方案完全不依赖贪婪模式切换，通过负向前瞻断言明确划定消息边界：匹配所有字符直到碰到下一条日志起始标记（[ns_server:/[error_logger:）或文本末尾为止，不受全局非贪婪模式影响。
替换后的完整正则如下：

^\[(?<type>\w+):(?<severity>\w+),(?<timestamp>\d+-\d+-\d+T\d+:\d+:\d+\.\d+Z),(?<node_name>[^:]*):([^:]+):(?<source>[^\]]+)\](?<message>(?:(?!\[(?:ns_server|error_logger):)[\s\S])*)

核心修改说明 #

• 移除原正则末尾的$锚点，避免multiline模式下提前在换行位置截断
• 将原message分组的.*替换为(?:(?!\[(?:ns_server|error_logger):)[\s\S])*：
  • 用[\s\S]匹配包含换行符在内的任意字符，无需额外开启dotall/singleline模式
  • 嵌套负向前瞻断言，每匹配一个字符前先校验后续内容是否为下一条日志的开头，命中边界立刻终止匹配，匹配逻辑完全不依赖量词的贪婪/非贪婪属性，适配全局开启U模式的环境
• 修正原正则时间戳部分未转义的.：将.\d+Z改为\.\d+Z，避免通配符匹配到非法时间戳格式

配置注意事项 #

• 在Fluent Bit/Google Cloud OPS Agent的多行解析规则中，将该正则设为日志首行匹配规则即可，无需额外编写续行匹配规则，正则本身会完整捕获跨多行的消息内容
• 保留原有global、multiline标志即可，无需调整默认的非贪婪配置，不会触发服务崩溃
• 如果后续新增其他日志类型前缀，只需在(?:ns_server|error_logger)的枚举列表中追加对应type值即可，扩展成本极低

匹配效果 #

针对提供的样例日志，可完整拆分出3条独立日志：

• 第一条debug级别日志的message分组完整捕获单行提示内容
• 第二条info级别日志的message分组完整捕获从换行开始的整段INFO REPORT结构化内容，包含所有换行、嵌套格式，直到第三条日志开头前截止
• 第三条info级别日志的message分组完整捕获单行提示内容
  不会再出现多行日志被拆分为多个无效独立条目的问题。

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