nginx高并发日志丢失主因是缓冲溢出、轮转错位与采集脱节，需同步优化缓冲策略（如buffer=64k flush=3s）、统一轮转逻辑（dateext+sharedscripts+usr1）及采集韧性（filebeat close_inactive=30s等）。
高并发下 Nginx 日志丢失，核心不是“写得慢”，而是写入链路在压力下出现缓冲溢出、轮转错位或采集脱节。必须从缓冲策略、轮转协同、采集韧性三方面同步加固，单点调优效果有限。
优化日志写入缓冲，防内存滞留
默认 buffer=8k 在高并发时极易积压，进程异常退出会导致缓冲区数据永久丢失。
- 显式启用 flush：将 access_log 配置改为
access_log /var/log/nginx/access.log main buffer=64k flush=3s;，确保最多 3 秒内强制落盘 - 禁用 HUP 重载触发 reopen：所有日志 reopen 必须由 logrotate 发送 USR1 完成，避免 reload 时缓冲未清空就切换文件句柄
- 确认 worker 进程用户与日志目录权限一致（如 nginx:adm），否则缓冲写入失败静默丢弃，不报错
统一轮转逻辑，防主备冲突
Keepalived 主备切换后，若两节点各自执行 logrotate，可能生成同名文件、覆盖内容或权限错乱，导致部分日志被截断或无法读取。
- 所有节点共用同一份 logrotate 配置，强制启用
dateext和高精度格式：dateformat -%Y%m%d-%H%M%S - 配置
sharedscripts+postrotate脚本，脚本内先校验/var/run/nginx.pid是否存在且对应进程存活，再发 USR1 - 设置
create 0600 nginx adm，不依赖 umask；同时启用delaycompress，保留上一轮未压缩日志供紧急审计
增强采集端稳定性，保 at-least-once
Filebeat 等采集器在高并发下容易因队列满、超时或 inode 变更漏采——尤其 nginx 日志轮转时旧文件被 rename，而 harvester 未及时跟进新文件。
- 调大关键参数：
close_inactive: 30s（避免轮转后延迟发现新文件）、scan_frequency: 2s、harvester_buffer_size: 65536 - 禁用
max_bytes: 1mb（默认 10MB 易引发内存抖动），改用小块稳定读取 - 启用持久化 registry（Filebeat 默认开启），并确保其存储路径所在磁盘不饱和；传输链路必须走 TLS，避免网络抖动丢包
补充验证手段，定位真实瓶颈
别只看 Filebeat 日志，要分层确认：
- 查原始日志文件是否真有缺失：对比
tail -n 100 /var/log/nginx/access.log与 ES/ZincSearch 中最近 100 条，看时间戳是否连续 - 检查 inode 是否复用：
ls -i /var/log/nginx/access.log*，若轮转后新文件 inode 与旧文件相同，说明 logrotate 用了 copytruncate，会丢数据 - 观察采集器指标：Filebeat 的
libbeat.pipeline.queue.acked与libbeat.pipeline.events.active若长期高位，说明输出端（ZincSearch）写入慢或不可达
