容器化 nginx 日志切割需全链路对齐：容器不轮转，须用 logrotate sidecar 或宿主机统一轮转；采集器正则、解压、路径监控须匹配归档规则；命名须用确定性 iso 时间戳；上线前须闭环验证轮转、采集、存储与告警。
在容器化环境中，Nginx 日志切割不能只盯着“切没切”，关键是要和整个日志收集链路对齐：从容器内写入、宿主机轮转、采集器抓取，到后端存储与检索，每环都得严丝合缝。否则容易出现日志丢失、时间错乱、重复采集或归档失败等问题。
容器内 Nginx 不直接管理日志文件生命周期
容器中运行的 Nginx 默认把 access_log 和 error_log 写入 /var/log/nginx/（通常是 emptyDir 或 hostPath 挂载），但容器本身不负责轮转——它只管持续追加。一旦不干预，单个日志文件会不断膨胀，最终撑爆节点磁盘或触发 kubelet 驱逐。
因此，必须引入外部轮转机制，且不能依赖 Nginx 自身 reload 或 reopen（容器重启时 PID 变更，信号易失效）。推荐做法是：
- 用 logrotate sidecar 容器（如 realz/logrotate）共享日志目录，定时或按大小触发切割
- 或在宿主机上通过 hostPath 挂载 + 全局 logrotate 配置统一管理所有 Nginx 实例日志
- 避免在容器内跑 cron + shell 脚本——违反容器不可变原则，也难统一管控
日志路径与采集器必须双向对齐
Fluentd、Filebeat 或 Loki 的采集配置，必须和 logrotate 的归档行为完全匹配，否则会漏采或重复采：
- 若 logrotate 启用 dateext + dateyesterday，归档名如
access.log-2026-09-04，采集器正则需识别该格式，且跳过正在写入的access.log - 若启用 compress，采集器默认不读 .gz 文件——需显式配置解压支持，或改用 delaycompress 确保当前轮转周期内仍为明文
- sidecar 场景下，采集器应监控 挂载路径下的归档文件变动，而非仅 watch 原始日志名；同时注意文件权限，确保采集用户可读
归档命名必须带确定性时间戳
容器环境动态性强，PID、启动顺序、时区都可能漂移。靠 nginx -s reopen + 动态文件名（如 access_$time_iso8601.log）风险高：
- open_log_file_cache off 不稳定，高频请求下易产生竞态
- 时间戳来自请求头或系统时间，跨节点可能不同步，导致日志排序错乱
- Loki 等基于流标签的系统，要求日志文件名或路径能稳定映射到 label（如
env=prod,app=nginx-ingress）
更稳妥的做法是：由 logrotate 统一生成 ISO 格式日期后缀（access.log-2026-09-04），再让采集器提取该日期作为 @timestamp 或自定义 label，确保时间语义准确、可聚合。
闭环验证：从轮转到告警全链路可测
上线前必须验证整条链路是否真正打通：
- 手动触发一次 logrotate（
logrotate -vf /etc/logrotate.d/nginx），确认归档文件生成、原始日志清空、Nginx 继续写入新文件 - 检查采集器日志，确认归档文件被识别并发送，且
timestamp字段与文件名日期一致 - 在 Grafana 中查 Loki 或 ES，验证是否有
2026-09-04时间窗口的日志，并对比原始访问量是否无损 - 设置告警：若某 Pod 连续 24 小时未产生新归档文件，说明 sidecar 失效或挂载异常
