EKS环境Fluent Bit生成超千个Cloudwatch日志流，如何按应用维度合并日志流

问题根因 #

默认Fluent Bit的CloudWatch输出插件以Pod名称作为日志流命名依据，EKS中Deployment完成代码迭代、重新部署生成的新Pod会附带随机哈希后缀，与历史Pod名称不一致，因此每次发布都会创建独立日志流，长期累积形成大量冗余流。

具体配置改造步骤 #

1. 前置检查 #

确认所有业务Deployment的Pod都绑定了统一标识的应用名标签（例如通用的app、app.kubernetes.io/name标签），未打标签的Deployment需先补打对应标签，否则无法准确识别应用归属。

2. 开启Kubernetes标签提取能力 #

在Fluent Bit的Pipeline配置中加入Kubernetes Filter，开启标签采集能力，将Pod标签注入日志上下文，配置片段：

[FILTER]
    Name                kubernetes
    Match               kubernetes.*
    Merge_Log           On
    K8S-Logging.Parser  On
    K8S-Logging.Exclude On
    Labels              On
    Annotations         On

开启Labels On后，Pod的所有标签会被存储到日志记录的kubernetes.labels字段下。

3. 增加标签值兜底逻辑 #

避免未打应用标签的Pod生成空值日志流名，增加Modify Filter对应用名字段做兜底处理，配置片段：

[FILTER]
    Name          modify
    Match         kubernetes.*
    # 提取应用名标签为统一引用字段
    Rename        kubernetes.labels.app  app_name
    # 无匹配应用标签时，写入默认兜底值
    Add           app_name  unknown-app
    Condition     Key_value_matches app_name ""

4. 修改CloudWatch日志流命名规则 #

移除默认按Pod名生成日志流的逻辑，直接引用提取到的应用名字段作为统一日志流名，输出插件配置片段：

[OUTPUT]
    Name                  cloudwatch
    Match                 kubernetes.*
    region                对应AWS运行区域
    log_group_name        EKS集群对应的CloudWatch日志组名称
    # 直接引用日志上下文中的应用名字段作为日志流名
    log_stream_name       ${app_name}
    log_stream_prefix     ""
    auto_create_group     On

配置生效后，示例中应用A的两个历史PodA-72371723、A-44444，以及未来重建的所有同应用Pod产生的日志，都会统一写入以应用A命名的单一日志流，完全匹配合并需求。

上线注意事项 #

• 配置修改完成后需滚动更新Fluent Bit DaemonSet，让新配置在所有节点生效
• 历史生成的冗余Pod名日志流不会自动合并，可根据需求选择直接清理（降低CloudWatch存储成本），或通过CloudWatch日志的跨流复制能力将历史数据迁移到新的统一日志流中
• 需确认Fluent Bit绑定的IAM角色具备logs:CreateLogStream、logs:PutLogEvents的操作权限，避免日志写入失败

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