部署Kubernetes的Fluent-bit Daemonset：非JSON日志转JSON入Elastic方案咨询

最优方案：正则解析+兜底保留策略 #

针对OpenLDAP这类非JSON但有固定结构化特征的日志，最优做法是通过正则规则提取字段，同时配置兜底机制确保不丢失任何日志内容，既实现JSON结构化存储，又避免遗漏未匹配的日志变体。

1. 优先使用parser过滤器插件 #

Fluent-bit的parser插件专门用于解析非JSON格式的结构化日志，比record函数更适配多变体场景，配置示例如下：

[INPUT]
    Name              tail
    Path              /var/log/containers/*ldap*.log
    Tag               kubernetes.ldap
    Parser            docker
    DB                /var/log/flb_ldap.db

[FILTER]
    Name              parser
    Match             kubernetes.ldap
    Parser            ldap_logs
    Reserve_Data      On  # 保留原始日志及K8s元数据字段
    Preserve_Key      On  # 保留原始"log"字段，避免解析失败时丢失内容
    Parser_Fallback   On  # 解析失败时，直接保留原始格式传递到Elastic

[PARSER]
    Name              ldap_logs
    Format            regex
    # 匹配ACCEPT类型日志
    Regex             /^conn=(?<conn>\d+) fd=(?<fd>\d+) (?<action>\w+) from IP=(?<src_ip>[^:]+):(?<src_port>\d+) \(IP=(?<dst_ip>[^:]+):(?<dst_port>\d+)\)$/
    # 匹配BIND类型日志
    Regex             /^conn=(?<conn>\d+) op=(?<op>\d+) (?<operation>\w+) dn="(?<dn>[^"]+)" method=(?<method>\d+)$/
    # 匹配RESULT类型日志
    Regex             /^conn=(?<conn>\d+) op=(?<op>\d+) (?<result>\w+) tag=(?<tag>\d+) err=(?<err>\d+) text=(?<text>.*)$/

• 多正则规则：可针对不同变体的OpenLDAP日志逐一编写匹配规则，插件会依次尝试匹配。
• 兜底配置：Reserve_Data和Parser_Fallback确保即使日志不匹配任何规则，原始内容也会被保留并传入Elastic，不会丢失。

2. 关于record函数的使用 #

record函数仅适合简单的键值提取，对多格式变体的日志处理灵活性极差：

• 若用record提取字段，需配合grep插件做条件匹配，否则不匹配的日志会生成空字段。
• 无法同时处理多种日志格式，维护成本高，且容易因规则覆盖不全导致日志内容丢失。因此不推荐用record处理这类场景。

3. 核心注意事项 #

无论采用哪种解析方式，必须确保原始日志字段被保留：

• 用parser插件时开启Reserve_Data和Parser_Fallback。
• 自定义处理逻辑时，务必将原始log字段保留在最终JSON结构中，确保解析失败的日志依然可查。

总结 #

1. 首选parser插件+多正则规则，适配多变体非JSON日志的结构化解析。
2. 强制开启兜底配置，杜绝日志丢失风险。
3. 避免用record函数处理多格式日志，维护成本高且易丢数据。

内容的提问来源于stack exchange，提问作者M.S.