Rook项目RGW操作日志增强：基于Pod名称的日志文件命名方案

背景与需求分析

在Rook项目管理的Ceph对象存储(RGW)场景中，当启用gateway.opsLogSidecar配置时，RGW操作日志会以JSON格式写入主机卷挂载的日志文件中。当前实现存在一个显著缺陷：所有RGW Pod实例共享同一个日志文件路径ops-log-ceph-client.[rgw store instance id].log，导致无法区分具体是哪个Pod实例产生了某条日志记录。

这种设计在以下场景会带来问题：

1. 日志聚合分析时无法关联日志来源
2. 故障排查时难以定位问题Pod
3. 监控指标采集时缺少实例维度

技术方案设计

经过社区讨论，确定采用包含Pod信息的日志文件命名方案。核心设计要点包括：

文件名格式优化

新方案采用三层标识结构：

ops-log.[pod namespace].[pod name].log

示例：

ops-log.rook-ceph.rook-ceph-rgw-my-store2-a-787bd9f8b7-jpnkx.log

技术决策考量

1. 信息完整性：保留namespace确保多租户环境隔离，完整pod name包含deployment名称和随机后缀
2. 可读性：去除冗余的instance id字段，因其已隐含在pod命名规则中
3. 兼容性：255字符的Linux文件名限制下，典型命名长度约65字符，留有充足余量
4. 日志轮转：每个Pod的sidecar容器独立处理自己的日志文件轮转

实现价值

1. 精准定位：运维人员可直接通过文件名定位问题Pod
2. 监控增强：Prometheus等监控系统可基于pod_name标签建立更精确的指标
3. 日志分析：ELK等日志系统能实现基于Pod维度的聚合分析
4. 故障隔离：快速识别异常Pod，缩小故障影响范围

技术细节说明

1. 命名规范：严格遵循Kubernetes命名规则，确保特殊字符正确处理
2. 日志格式：保持现有JSON格式不变，仅变更存储路径
3. 性能影响：单个Pod独立写入文件，避免多实例写入竞争
4. 升级兼容：旧版本日志文件可继续保留，新版本自动启用新命名规则

该方案已通过社区技术评审，将随Rook后续版本发布，为分布式存储运维提供更强大的可观测性支持。