logrotate 配置文件应放在 /etc/logrotate.d/ 下，而非修改 /etc/logrotate.conf；每个服务建独立文件（如 nginx），需确保主配置含 include /etc/logrotate.d 且目录权限正确。
logrotate 配置文件该放哪儿？别动 /etc/logrotate.conf 主文件
绝大多数情况下，你**不该直接修改 /etc/logrotate.conf**。它只负责全局默认值（比如默认压缩、默认保留几份），真正要管某个服务（如 nginx、redis、自研应用）的日志，必须在 /etc/logrotate.d/ 下建独立配置文件——这样既解耦，又避免升级时被覆盖。
常见错误是把所有规则堆进主配置，结果某次系统更新重装了 logrotate 包，/etc/logrotate.conf 被替换成默认版，所有轮转突然失效。
-
/etc/logrotate.d/目录下每个文件名无特殊要求，但建议用服务名（如nginx、myapp），方便识别 - 确保该目录可读：
ls -l /etc/logrotate.d/，权限应为drwxr-xr-x，且 root 所有 - 主配置中必须存在
include /etc/logrotate.d行（注意没有结尾斜杠），否则子目录配置不会被加载
daily + rotate 7 不等于“保留最近 7 天”
很多人以为 daily 和 rotate 7 组合就能稳稳留 7 天日志，其实不是：logrotate 每次轮转会重命名旧文件为 access.log.1、access.log.2……直到 access.log.7，第 8 次轮转时，access.log.7 会被直接删除。
这意味着：如果某天因故障没触发轮转（比如 cron 挂了、磁盘满导致失败），那缺失的那一天就永远空缺，编号不连续，但保留总数仍是 7 个归档文件——不是 7 个自然日。
- 想严格按日期归档（如
access_20260122.log.gz），必须加dateext，并配合dateformat %Y%m%d - 若服务不支持日志重载（比如某些 Java 应用没监听 USR1），光靠
daily轮转会导致新日志继续写进旧文件（已被 rename），必须用copytruncate安全截断 -
delaycompress很关键：它让最新一轮转出的.1文件先不压缩，等下次轮转变成.2再压，避免应用还在写.1时被 gzip 锁住
postrotate 脚本里 kill -USR1 为什么常失败？
nginx、rsyslog 等服务靠接收 SIGUSR1 信号重新打开日志文件，但 postrotate 脚本执行时，PID 文件可能不存在、路径不对、权限不足，或进程已用 systemd 管理而不用 PID 文件。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
典型报错：cat: /var/run/nginx.pid: No such file or directory 或 kill: (12345): No such process。
- 先确认 PID 文件真实路径：
systemctl show --property=PIDFile nginx.service或查服务文档 - 用
if [ -f ... ] && kill -USR1 $(cat ...)包裹，避免因文件缺失导致整个脚本中断 - systemd 服务更推荐用
systemctl reload（需服务单元定义了ReloadExecStart）：systemctl reload nginx.service - 务必加
sharedscripts：否则通配符匹配多个日志文件（如access.log和error.log）时，postrotate会执行多次，造成重复 reload
手动测试配置前，先跑 logrotate -d 看懂它到底想干啥
-d（debug）模式不改任何文件，只输出 logrotate 的完整决策逻辑，是排查配置问题最有效的手段。比盲目 -f 强制执行安全十倍。
常见 debug 输出线索：
-
rotating pattern: /var/log/nginx/*.log daily→ 确认路径和策略已识别 -
empty log files are not rotated, old logs are removed→ 因notifempty且文件为空，跳过本次 -
log needs rotating→ 条件满足，下一步可用-v -f实测 -
error: error creating output file /var/log/nginx/access.log.1→ 权限或磁盘问题，立刻停手
真正上线前，至少用 sudo logrotate -d /etc/logrotate.d/myapp 过一遍；如果涉及生产服务，再补一次 sudo logrotate -v -f /etc/logrotate.d/myapp 观察实际行为——尤其是检查新日志是否生成、旧日志是否被 rename、postrotate 是否成功执行。
最易被忽略的一点：logrotate 的状态记录存在 /var/lib/logrotate/status，它决定“上次轮转时间”。如果你反复删日志文件又不清理这个状态，logrotate 可能误判“还没到轮转周期”，死活不干活。
