问题出现得很突然，日志倒是留得挺全。logrotate 每天把 nginx 与应用的 access.log 压成 .gz，运维用 grep 搜昨天的请求 id 一条都搜不到，加 -r 也没用，看目录里确实有 access.log-20261110.gz，文件大小 1.2GB。
刚开始盯着「压缩任务在凌晨跑，昨天的记录跨了两个文件」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。grep 默认不读 gzip 压缩内容，需要 zgrep 或 zcat 管道。少数情况下是日志被切割后新写入进了新文件，搜的是当前那个空文件。
少数情况下是搜索目录没带对，实际文件在别的挂载点。
第一件事是确认目标文件是不是压缩格式
file /var/log/nginx/access.log-20261110.gz随后用 zgrep 直接搜压缩文件
zgrep -c 'req-20261110-8821' /var/log/nginx/access.log-20261110.gz跨多个归档一起搜
zcat /var/log/nginx/access.log-*.gz | grep -c 'req-20261110-8821'末了确认切割时间点与检索范围是否匹配
ls -l --time-style=full-iso /var/log/nginx/access.log*怎么算真的好了，看的是同一批现象。zgrep 能在归档里搜到目标请求 id，条数与网关统计一致，跨天边界的两段记录都能被找到。
这里还有个坑。归档文件是压缩的，grep 看不见内容也不会报错，搜索脚本里统一用 zgrep 能省掉这类静默失败。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。