FluentBit：Pod日志字段来源及批量添加MachineName字段问题

现有FluentBit配置 #

custom_parsers.conf: |
    [PARSER]
        Name docker_no_time
        Format json
        Time_Keep Off
        Time_Key time
        Time_Format %Y-%m-%dT%H:%M:%S.%L
  fluent-bit.conf: |
    [SERVICE]
        Daemon Off
        Flush 1
        Log_Level info
        Parsers_File parsers.conf
        Parsers_File custom_parsers.conf
        HTTP_Server On
        HTTP_Listen 0.0.0.0
        HTTP_Port 2020
        Health_Check On

    [INPUT]
        Name tail
        Path /var/log/containers/*.log
        Tag kube.*
        DB /var/log/fluent-bit-kube.sqlite
        Mem_Buf_Limit 5MB
        Skip_Long_Lines On

    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        Keep_Log Off
        K8S-Logging.Parser On
        K8S-Logging.Exclude On

    [FILTER]
        Name modify
        Match kube.*
        Add kube_cluster_name dev-k8s

    [OUTPUT]
        Name gelf
        Match kube.*
        Host log.my-graylog.ru
        Port 12201
        Mode udp
        Gelf_Short_Message_Key log
        Gelf_Host_Key dev.k8s
        Compress false

问题现象 #

1. 单个Pod的日志中存在额外的MachineName字段，且该Pod日志是正确的多行格式；其他Pod日志无此字段，但多行日志损坏。
2. /var/log/containers/下的所有日志文件（包括该特殊Pod的）都没有MachineName字段。

可能修改日志内容的配置/组件 #

1. FluentBit Kubernetes过滤器 #

你配置的kubernetes过滤器开启了Merge_Log On和K8S-Logging.Parser On，会：

• 自动识别Pod annotations里的kubernetes.io/log-parser指定的解析器
• 合并容器日志到顶层字段，可能触发额外字段的添加或覆盖
• 该特殊Pod可能配置了专属日志annotation，触发了额外解析逻辑，导致MachineName被注入

2. 容器侧日志处理 #

部分容器可能自带日志包装程序，在输出日志到stdout/stderr时自动添加MachineName字段——这些字段被Docker的JSON结构包裹，FluentBit解析后才会显现（你看到的日志文件是Docker封装后的，原始日志内容在log字段中）。

3. FluentBit默认解析器 #

加载的官方parsers.conf包含docker、cri等默认解析规则，若Pod日志格式匹配这些规则，可能触发额外字段提取。

4. Graylog侧处理规则 #

Graylog的GELF输入配置或流水线（Pipeline）可能针对部分日志添加MachineName字段，需检查对应规则。

需要排查的内容 #

1. 特殊Pod的Annotations

   • 检查该Pod的kubernetes.io/log-parser annotation，确认是否指定了自定义解析器，是否与现有配置冲突
   • 查看Pod的第三方日志相关annotations，比如fluentbit.io/parser等

2. 容器原始日志输出

   • 用kubectl logs <特殊Pod名>直接查看容器 stdout/stderr 的原始内容，确认是否自带MachineName字段
   • 解析容器日志文件的JSON内容：执行jq '.log' /var/log/containers/<特殊Pod日志文件>.log，查看原始日志文本是否包含目标字段

3. FluentBit运行日志与状态

   • 将FluentBit日志级别改为trace（修改SERVICE块的Log_Level trace），查看解析流程的详细日志定位MachineName的添加环节
   • 调用FluentBit HTTP API：curl http://<节点IP>:2020/api/v1/filters，查看过滤器实际运行配置

4. Graylog处理规则

   • 检查GELF输入的默认字段配置，是否有自动添加/提取规则
   • 查看Graylog中是否存在针对该Pod日志的流水线规则，是否自动注入了MachineName

5. 多行日志损坏排查

   • 检查其他Pod的日志格式，若为非JSON多行日志，需配置多行解析器（比如multiline过滤器或自定义解析规则）
   • 当前配置的Skip_Long_Lines On会截断长行，可能导致多行日志损坏，建议关闭该选项并配置正确的多行解析逻辑

实现所有Pod日志添加MachineName字段的方案 #

方法1：通过modify过滤器统一添加 #

在现有modify过滤器中追加字段，或新增过滤器：

[FILTER]
    Name modify
    Match kube.*
    Add kube_cluster_name dev-k8s
    Add MachineName <自定义集群/节点标识>

如果需要动态获取节点名称，可在DaemonSet的Pod模板中注入节点环境变量，再在配置中引用：

[FILTER]
    Name modify
    Match kube.*
    Add kube_cluster_name dev-k8s
    Add MachineName ${NODE_NAME}

同时在DaemonSet的env段添加：

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

方法2：通过Kubernetes过滤器获取节点信息 #

修改kubernetes过滤器开启节点名称采集，再用rename过滤器重命名为MachineName：

[FILTER]
    Name kubernetes
    Match kube.*
    Merge_Log On
    Keep_Log Off
    K8S-Logging.Parser On
    K8S-Logging.Exclude On
    K8S-Node-Name On

[FILTER]
    Name rename
    Match kube.*
    Rename kubernetes_node_name MachineName

内容的提问来源于stack exchange，提问作者Радик Фахриев