Nginx多进程日志切割需主进程协调、USR1信号触发worker重开文件，禁用buffer/flush保障实时写入，pipe模式实现真正异步；禁用copytruncate，配合监控确保可靠性。
在 Nginx 多进程模型中，日志切割和异步写入不能依赖单进程常规方式（如 logrotate 直接 kill -USR1），必须兼顾主进程协调、工作进程协作与磁盘 I/O 安全性。核心在于：由外部工具触发信号 + Nginx 原生 reload 机制配合 + 日志文件按时间/大小滚动 + 写入不阻塞请求处理。
日志切割：利用 USR1 信号 + 时间戳命名
Nginx 工作进程收到 USR1 信号后，会各自关闭当前打开的 access.log/error.log 文件句柄，并基于配置中的路径重新打开新文件。注意：该行为需主进程存在且未被终止。
- 确保 nginx.conf 中日志路径不含动态变量（如 $time_iso8601），否则各 worker 可能生成不同名文件，导致切割混乱
- 推荐使用固定路径 + 外部脚本重命名归档，例如：access.log → access.log.20240520_103000
- 执行切割前先备份原日志（避免 USR1 发送后、重开前丢失最后一段日志），再发信号：
mv access.log access.log.$(date +\%Y\%m\%d_\%H\%M\%S) && kill -USR1 $(cat /var/run/nginx.pid)
避免写入阻塞：禁用 buffer 和 flush，交由内核调度
Nginx 默认对 access_log 启用缓冲（buffer=64k）和延迟刷盘（flush=1s），这虽提升性能但增加日志延迟和丢失风险。若需更实时或可控的写入行为，应显式控制：
- 关闭缓冲：
access_log /var/log/nginx/access.log main buffer=0; - 禁用自动刷盘：
access_log /var/log/nginx/access.log main flush=0; - 注意：关闭 buffer 后，每次写日志都是一次系统调用，高并发下可能轻微影响吞吐，但可确保每条记录即时落盘（配合 O_APPEND 和 ext4/xfs 日志模式）
异步写入增强：通过 pipe + 用户态日志进程解耦
真正意义上的“异步”需将日志写入从 worker 进程中剥离。Nginx 支持 pipe 类型日志目标，将日志行发送至管道，由独立进程消费：
- 配置示例：
access_log pipe:/var/log/nginx/access_pipe.log main; - 需提前创建命名管道：
mkfifo /var/log/nginx/access_pipe.log - 启动一个持久化消费者（如用 Python/Go 编写的日志收集器），读取 pipe 并批量写入文件、压缩、上传或转发到 Kafka
- 优势：worker 进程仅做 write() 系统调用（内核级非阻塞），实际落盘由消费者控制；支持日志采样、字段过滤、格式转换等高级能力
生产建议：组合使用 + 监控兜底
单一方案难以兼顾可靠性、实时性与运维便利性，推荐分层设计：
- 日常切割用 USR1 + 定时 cron（如每小时）+ 归档压缩脚本
- 关键业务日志启用 pipe 模式，接入轻量 collector 实现异步落地与告警联动
- 监控 /proc/*/fd 下各 worker 对日志文件的 fd 状态，确认是否全部完成 reopen；检查 error.log 是否出现 open() failed (24: Too many open files) 等错误
- 避免在 logrotate 中使用 copytruncate —— Nginx 不感知该操作，worker 仍向旧 inode 写入，造成日志丢失
