应为每个服务在 /etc/logrotate.d/ 下单独创建无扩展名配置文件（如 myapp），权限644、属主root；内容须以完全匹配的日志路径开头，必含 copytruncate 以防应用不重开文件，并用 logrotate -d 验证加载。
在 /etc/logrotate.d/ 下创建服务专属配置文件
logrotate 不会自动为每个日志文件生成规则，必须显式声明。最稳妥的做法是为指定日志（比如 /var/log/myapp/app.log）单独建一个配置文件，放在 /etc/logrotate.d/ 目录下，文件名不能带扩展名（如 myapp.conf 会被忽略），推荐用服务名本身，例如 myapp。
该文件权限应为 644，属主 root；否则 logrotate 可能跳过加载。
- 配置文件内容必须以日志路径开头，且路径要完全匹配（支持通配符，但不建议初用）
- 不要把多个服务规则写进同一个文件——logrotate 按文件粒度加载，冲突难排查
- 若日志路径含空格或特殊字符，需用引号包裹，但实际中应避免这类路径
配置项要覆盖服务重启与日志清空场景
很多应用（如 Java 进程、Nginx）不会自动重打开新日志文件，切割后继续往旧文件描述符写，导致 copytruncate 成为刚需。不加这行，切完的日志可能仍是空的，而原文件还在疯长。
典型配置示例：
/var/log/myapp/app.log {
daily
missingok
rotate 30
compress
delaycompress
copytruncate
create 644 root root
}
-
missingok：防止日志文件暂不存在时报错中断整个 logrotate 流程 -
delaycompress：和compress配合，让最新一份（.1）先不压缩，方便调试 -
create参数必须显式指定权限和用户，否则新建日志可能属错用户，导致应用无法写入
验证配置是否被正确加载
logrotate 加载配置时静默失败很常见。直接执行 logrotate -d /etc/logrotate.conf（debug 模式）可看到它实际读了哪些文件、是否识别到你的日志路径、有没有报 warning。
关键检查点：
- 输出中是否出现类似
reading config file myapp的行 - 是否显示
adding /var/log/myapp/app.log to config - 有无
error: cannot access或skipping提示（常因权限或路径拼写错误）
别依赖 logrotate -f /etc/logrotate.d/myapp 单独测试——它不走全局配置链，可能绕过 include 和全局参数，结果不可靠。
避免和应用自身日志滚动策略冲突
如果应用（如 Log4j2、Python logging.handlers.RotatingFileHandler）已启用按大小或时间滚动，再用 logrotate 切割，极可能造成日志丢失或重复归档。必须确认：
- 应用是否关闭了内部滚动（设为单文件 + 不轮转）
- 若保留应用滚动，logrotate 应只做归档压缩（
nocreate+compress），不碰当前活跃文件 - 两者触发时机接近时（如都设 daily），可能因竞态导致某天日志被跳过
最安全的组合是：应用只写单个日志文件，全部交由 logrotate 管理生命周期——这是生产环境主流做法，也最容易审计和排障。
