Fluent Bit中Kubernetes日志过滤与清理的最佳实践

问题背景

在使用Fluent Bit处理Kubernetes容器日志时，许多开发者会遇到一个常见需求：既要保留Kubernetes元数据（如Pod名称、容器名称）用于日志流命名，又要清理掉原始日志中的冗余字段，只保留实际日志内容。这种需求在将日志发送到CloudWatch等日志服务时尤为常见。

问题现象

当用户尝试同时使用以下两个配置时会出现问题：

1. log_stream_template：基于Kubernetes元数据动态生成日志流名称
2. log_key：指定只提取日志中的特定字段作为实际输出内容

配置冲突会导致日志流模板无法正确获取Kubernetes元数据字段，因为log_key操作会移除其他所有字段。

解决方案

1. 使用正确的Fluent Bit版本

经过验证，Fluent Bit的社区版3.2.4版本可以完美解决这个问题，而AWS提供的2.32.4镜像则存在兼容性问题。建议使用最新稳定版的Fluent Bit社区镜像。

2. 配置示例

以下是经过验证的有效配置片段：

[FILTER]
    Name                kubernetes
    Match               application.*
    Kube_Tag_Prefix     application.var.log.containers.
    Merge_Log           On
    Merge_Log_Key       log_processed
    K8S-Logging.Parser  On
    K8S-Logging.Exclude Off

[OUTPUT]
    Name                cloudwatch_logs
    Match               application.*
    region              us-east-1
    log_group_name      /eks/app-logs
    log_stream_template $kubernetes['pod_name'].$kubernetes['container_name']
    log_key             log

3. 关键配置说明

• Kubernetes过滤器：负责从日志中提取Kubernetes元数据，包括Pod名称、容器名称等
• log_stream_template：使用提取的元数据动态生成日志流名称
• log_key：指定只输出日志中的"log"字段内容，过滤掉其他元数据

实现原理

Fluent Bit在处理日志时会经历以下流程：

1. 原始日志被Tail插件收集，包含完整的JSON结构
2. Kubernetes过滤器解析并添加Kubernetes元数据
3. 在输出阶段，log_key会提取指定字段，但保留上下文中的元数据用于流命名
4. CloudWatch插件使用保留的元数据生成日志流名称，同时只上传指定的日志内容

最佳实践建议

1. 版本选择：始终使用Fluent Bit的最新稳定版本
2. 日志保留策略：考虑同时保留原始日志和精简日志到不同的日志组
3. 性能考量：对于高流量环境，适当调整缓冲区大小和刷新间隔
4. 错误处理：配置适当的错误处理和重试机制，确保日志不会丢失

总结

通过合理配置Fluent Bit的过滤器和输出插件，开发者可以实现既保留Kubernetes元数据用于日志管理，又精简日志内容的目标。关键在于使用正确的版本和配置组合，确保各插件间的数据流不会意外丢失关键信息。