验证Nginx日志切割脚本有效性需确认三件事：旧日志停写、新日志开始写入、异常时有兜底；容灾恢复能力体现在磁盘满、进程卡死、并发冲突等故障下不丢日志、不中断服务。
验证 Nginx 日志切割脚本是否真正有效，不能只看“没报错”或“文件名变了”，关键要确认三件事：旧日志停写、新日志开始写入、异常时有兜底。容灾恢复能力则体现在磁盘满、进程卡死、并发冲突等真实故障下，脚本能不丢日志、不中断服务。
验证是否真正完成切割
执行脚本后，立刻检查以下三项：
-
文件名与时间戳匹配：运行
ls -lt /var/log/nginx/*.log*，确认新生成的文件（如access.log.20260904-15）时间戳是当前小时，且比原access.log文件更新时间早（说明它已被重命名） -
原 access.log 是否为空且持续增长：用
stat /var/log/nginx/access.log查看 inode 和 mtime；再发几个请求（如curl -I localhost），然后tail -n1 /var/log/nginx/access.log，确认新条目已写入且文件大小在变 -
旧文件是否停止增长：对比
stat输出中旧文件（如access.log.20260904-14）的 size 和 mtime，确认其大小不再变化、修改时间停留在切割时刻
验证容灾机制是否生效
手动模拟常见故障，观察脚本行为：
-
磁盘空间不足时是否跳过并告警：用
df --output=pcent /var/log | tail -1 | sed 's/%$//'检查使用率；临时填充磁盘至 95%+，再运行脚本，确认输出含“disk full”提示且未执行 mv/kill 步骤 -
并发执行是否被锁住：开两个终端，同时运行脚本；其中一个应立即退出并提示“another instance is running”，
/tmp/nginx-cut.lock文件存在时间应短于脚本总耗时 -
nginx 进程不可达时是否安全终止：先
kill -STOP $(cat /var/run/nginx.pid)暂停主进程，再运行脚本；脚本应检测到kill -USR1失败，记录错误但不删除或覆盖任何文件
验证恢复能力：模拟日志丢失场景
这是容灾验证的核心环节，需主动破坏后检验能否自愈：
-
删掉原始 access.log 后是否自动重建：手动
rm /var/log/nginx/access.log，再触发一次切割脚本（或等下一轮 cron）；脚本中的touch /var/log/nginx/access.log步骤应生效，且 Nginx 在收到 USR1 后能正常打开该空文件继续写入 -
旧日志被误删后，新日志是否仍可独立归档：删除某个历史文件（如
access.log.20260903-10），运行清理命令find /var/log/nginx -name "*.log.*" -mtime +7 -delete，确认其余文件不受影响，且新切割仍按规则生成 -
验证日志连续性：切割前后各发 5 个请求，分别
grep时间戳段落（如grep "04/Sep/2026:15:.*:.."），确认所有请求都落在对应的新旧文件中，无遗漏
日常巡检建议
把验证动作固化为轻量检查项，每周快速过一遍：
- 查看
/var/log/nginx/cut.log最近 3 条记录，确认时间、文件名、无 ERROR 关键字 - 运行
find /var/log/nginx -name "access.log.*" -mmin -65 | wc -l，检查最近一小时内是否生成了预期的新文件（按小时切应为 1） - 用
lsof -p $(cat /var/run/nginx.pid) | grep log确认 Nginx 工作进程打开的日志文件路径与配置中access_log指令完全一致
