日志轮转中missingok选项的作用与使用场景

missingok到底解决了什么问题

在服务器运维过程中，日志文件每天都在不断增长。如果不做处理，磁盘很快就会被占满。logrotate 是 Linux 系统中常用的日志轮转工具，而 missingok 是其中一个重要配置选项。

假设你负责维护一台 Web 服务器，应用部署在非标准路径下，比如 /opt/myapp/logs/access.log。某次发布时，目录结构有变动，日志目录还没来得及创建，但 logrotate 的定时任务已经运行。默认情况下，如果找不到日志文件，logrotate 会报错并退出，还会发一封警告邮件到管理员邮箱。

这时候，missingok 就派上用场了。它告诉 logrotate：”就算这个日志文件暂时不存在，也别报错，正常往下走“。

配置示例

/opt/myapp/logs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 644 www-data www-data
}

上面这段配置里，missingok 表示如果 /opt/myapp/logs/ 下没有任何匹配的 .log 文件，也不视为错误。这在应用刚上线、还未生成首条日志，或临时停机期间特别实用。

和 nomissingok 的区别

不加 missingok 的话，就是默认的 “nomissingok”。只要指定路径下的日志文件不存在，logrotate 就会记录一条错误信息，可能触发监控告警。对于自动化程度高的环境来说，这种误报会影响判断。

比如你在 Ansible 脚本里统一推送 logrotate 配置，覆盖所有主机，但某些测试机上并没有实际运行对应服务。加上 missingok 后，同一份配置就能通吃生产机和空闲机器，不用再区分写法。

实际使用建议

多数情况下推荐加上 missingok。毕竟服务启动顺序、部署时机这些都可能造成短暂的日志缺失，没必要因此触发报警。

但它不能解决根本问题。如果日志长期缺失，可能是应用崩溃或路径写错了。这时候 missingok 会掩盖问题，所以要配合其他手段，比如通过监控日志更新时间来判断服务是否正常输出日志。

简单说，missingok 是个“别为小事吵吵”的选项，让系统更耐操一点，但也得有人盯着大事。”