Fluent Bit多行日志解析中空行处理问题分析

问题背景

在使用Fluent Bit处理日志文件时，当遇到包含多行内容且其中存在空行的日志条目时，系统会抛出"error packing event : -4"错误。这个问题特别容易出现在包含SQL查询语句的日志中，因为这些日志通常由多行组成，且不同查询之间可能存在空行分隔。

问题现象

当日志文件包含如下结构时会出现解析错误：

2025-03-26T13:51:29,075+0000 [*dat-job-thread-17, SOMEUSER, #null, #103806, dab1a05a-7d2c-4dba-af7c-80536f1bb97e*]: [data-source="MY-DATA-SOURCE"] 
SELECT
   V1."Case_Id" AS "CASEID",
   V1."Case_Team" AS "CASETEAM"
FROM
   "cache"."dbo"."V_CASE_TEAMS" V1

2025-03-26T13:51:29,081+0000 [*dat-job-thread-28, SOMEUSER, #null, #103809, 2724feb7-7165-410d-a5bc-a3c9f8949b26*]: 10000 rows Processed

而如果两个日志条目之间没有空行，或者空行中包含至少一个空白字符（如空格或制表符），则解析可以正常进行。

技术分析

这个问题源于Fluent Bit对多行日志的处理机制。当启用多行模式(Multiline on)时，Fluent Bit会使用Parser_Firstline指定的解析器来识别日志条目的起始行，然后将后续行作为该条目的内容，直到遇到下一个匹配起始模式的行。

空行在这种情况下会被视为日志条目的分隔符，导致解析器无法正确判断多行日志的边界。错误代码"-4"通常表示数据打包过程中出现了格式问题。

解决方案

在Fluent Bit的输入配置中添加Skip_Empty_Lines On参数可以解决这个问题。这个配置会使Fluent Bit在处理日志时自动跳过空行，从而避免空行对多行日志解析的干扰。

修改后的配置示例：

[INPUT]
    Name                tail
    Alias               sqllog.log
    Tag                 sqllog.log
    Multiline           on
    Multiline_Flush     1
    Parser_Firstline    tss.sqllog
    Skip_Empty_Lines    On
    Path                logs/sql.log
    Db                  logs/fluentbit.db
    read_from_head      true
    Buffer_Max_Size     64KB

注意事项

1. 使用Skip_Empty_Lines On后，日志中的所有空行都会被忽略，这可能在某些情况下影响日志的可读性。

2. 如果确实需要保留空行作为日志格式的一部分，可以考虑在日志生成阶段确保空行至少包含一个空白字符。

3. 对于复杂的多行日志模式，可能需要调整Parser_Firstline的正则表达式以更精确地匹配日志起始行。

最佳实践建议

1. 在开发环境中充分测试日志解析配置，特别是处理包含多行内容的日志时。

2. 考虑在日志生成端规范日志格式，避免使用纯空行作为分隔符。

3. 对于关键业务日志，建议添加足够的上下文信息，即使存在解析问题也能追踪完整的日志流。

4. 定期检查Fluent Bit的错误日志，及时发现并处理解析异常。