作为一名尽职尽责的服务器管理员，我们对日志文件可谓是“爱恨交加”。一方面，我们爱它。当网站出现502错误、应用无故崩溃、或者服务器遭遇可疑的访问时，这些静静躺在<code>/var/log</code>目录下的日志文件，就是我们的“第一案发现场”和“黑匣子”，是排查问题的关键线索。我们甚至会专门撰写指南来探讨如何<a href=”/blog/nginx-apache-log-analysis/”>分析这些日志</a>。但另一方面，我们也恨它。如果放任不管，这些日志文件会像打了激素的野草一样疯狂生长，日积月累，直到有一天，你突然收到告警——“磁盘空间不足！”，或者更糟的，数据库因为无法写入日志而崩溃，整个网站随之瘫痪。这种突如其来的“磁盘爆炸”，绝对是运维工作中最令人沮ăpadă的场景之一。那么，有没有一种方法，可以让我们既能保留必要的日志以备追溯，又能避免它们撑爆我们的硬盘呢？当然有！今天，Hostol就来为你详细解读Linux系统中那位默默无闻但功勋卓著的“日志管家”——<code>logrotate</code>，并手把手教你如何通过配置实战，让你的服务器日志实现自动轮转、压缩与清理，彻底告别“磁盘爆炸”的噩梦！
揭秘 logrotate：它是如何工作的？
在深入配置之前，我们先来搞清楚<code>logrotate</code>这位“管家”的工作模式。它并非一个持续运行的后台守护进程，而是一个非常聪明的工具，其核心职责就是对指定的日志文件进行系统化的管理。
核心“三板斧”：轮转、压缩、清理
<code>logrotate</code>的管理哲学，可以概括为简单有效的三板斧：
- 轮转 (Rotate): 这是最核心的动作。当满足特定条件时（比如每天一次，或者文件达到一定大小），<code>logrotate</code>会把当前的日志文件“挪个窝”，通常是给它改个名。例如，将<code>nginx.log</code>重命名为<code>nginx.log.1</code>。然后，它会创建一个新的、空的<code>nginx.log</code>文件，让Nginx服务继续往这个新文件里写日志。这样，旧的日志就被完整地“封存”起来了。
- 压缩 (Compress): “封存”起来的旧日志文件（如<code>nginx.log.1</code>），虽然不再增长，但仍然占用着宝贵的磁盘空间。<code>logrotate</code>的第二板斧，就是将这些被轮转出去的旧日志文件进行压缩，通常是使用<code>gzip</code>。于是，<code>nginx.log.1</code>就变成了<code>nginx.log.1.gz</code>，体积大大减小。
- 清理 (Remove): 随着时间的推移，压缩过的旧日志文件会越积越多（<code>nginx.log.1.gz</code>, <code>nginx.log.2.gz</code>, …）。当旧日志的数量超过了我们设定的保留份数时，<code>logrotate</code>就会挥出第三板斧，将最古老的那个日志文件（比如<code>nginx.log.15.gz</code>）毫不留情地删除，从而释放磁盘空间，完成一次完美的生命周期循环。
幕后推手：cron 的定时调度
那么，<code>logrotate</code>是什么时候来施展这套“三板斧”的呢？答案是cron，Linux的计划任务系统。在大多数Linux发行版中，系统都会预设一个每日执行的cron任务。你可以查看<code>/etc/cron.daily/</code>目录，里面通常会有一个名为<code>logrotate</code>的可执行脚本。这个脚本每天会被<code>cron</code>守护进程在某个固定的时间点（具体时间取决于系统配置）调用一次。而这个脚本的核心内容，就是执行<code>/usr/sbin/logrotate /etc/logrotate.conf</code>这条命令。这意味着，<code>logrotate</code>每天都会根据它的主配置文件<code>/etc/logrotate.conf</code>以及其中包含的其他配置文件，来检查所有需要管理的日志，并对满足条件的日志执行轮转操作。
logrotate 配置实战：定制你的日志管理策略
理解了工作原理，接下来就是激动人心的实战环节了！<code>logrotate</code>的强大之处在于其高度可定制的配置文件。
它的主配置文件是<code>/etc/logrotate.conf</code>，这个文件通常定义了一些全局的默认设置。但更重要的，也是我们日常打交道最多的，是位于<code>/etc/logrotate.d/</code>目录下的、针对各个应用程序的独立配置文件。几乎所有通过包管理器安装的服务（如Nginx, Apache, rsyslog, yum等），在安装时都会自动在这个目录下创建一个属于自己的日志轮转配置文件。这种模块化的设计，使得管理非常清晰。
### 解读一个典型的配置文件 (以 Nginx 为例)
我们打开一个常见的Nginx日志轮转配置文件<code>/etc/logrotate.d/nginx</code>来看看，它可能长这样：
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 nginx adm
sharedscripts
postrotate
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}
第一行<code>/var/log/nginx/.log</code>指定了这条规则要管理的文件路径，这里的<code></code>是通配符，意味着<code>/var/log/nginx/</code>目录下所有以<code>.log</code>结尾的文件（如<code>access.log</code>, <code>error.log</code>）都适用此规则。花括号<code>{…}</code>内部就是具体的指令。
核心配置指令“点将台”
- 轮转周期 (Rotation Frequency):
daily: 每天轮转一次。weekly: 每周轮转一次。monthly: 每月轮转一次。yearly: 每年轮转一次。
- 轮转时机 (Size-based Rotation):
size <size>: 当日志文件大小超过指定大小时，就进行轮转。例如<code>size 100M</code>表示超过100MB就轮转。这个指令可以和周期指令一起使用，满足任一条件即触发。
- 保留份数 (Rotation Count):
rotate <count>: 指定保留多少份旧的日志文件。例如<code>rotate 14</code>表示保留14份，当生成第15份时，最老的那一份就会被删除。
- 压缩选项 (Compression Options):
compress: 启用压缩，默认使用<code>gzip</code>。nocompress: 禁用压缩。delaycompress: 延迟压缩。这是一个很实用的选项，它会让最近一次被轮转出去的日志文件（比如<code>nginx.log.1</code>）暂时不压缩，等到下一次轮转时再压缩它。这样做的好处是，如果你需要分析最近一两天的日志，可以直接查看未压缩的文本文件，比较方便。
- 文件处理 (File Handling):
missingok: 如果日志文件不存在，不要报错，继续处理下一个。notifempty: 如果日志文件是空的，就不进行轮转。create [mode owner group]: 轮转后，立即创建一个新的空日志文件，并可以指定其权限模式、所有者和所属组。例如<code>create 0640 nginx adm</code>。
- 脚本钩子 (Script Hooks):
prerotate/endscript: 在轮转所有匹配的日志文件之前执行的脚本。postrotate/endscript: 在轮转所有匹配的日志文件之后执行的脚本。sharedscripts: 如果一个配置块匹配了多个日志文件，这个选项确保<code>prerotate</code>和<code>postrotate</code>脚本只会被执行一次，而不是每个文件都执行一次。postrotate脚本至关重要，因为很多服务在启动时会一直“咬住”一个日志文件的句柄不放。即使你把旧日志文件改名了，服务可能还会继续往那个改了名的旧文件里写。<code>postrotate</code>脚本里的任务，通常就是给服务发送一个信号，告诉它：“嗨，你的日志文件换新的了，请重新打开一下！” 对于Nginx，就是<code>kill -USR1 <Nginx主进程ID></code>这个信号。
为你的自定义应用配置 logrotate
现在，假设你有一个自己开发的应用，它会把日志写到<code>/var/log/myapp/app.log</code>。我们来从零开始为它创建一个logrotate配置。
从零开始创建一个新的 logrotate 配置文件
- 创建一个新文件： Bash
sudo nano /etc/logrotate.d/myapp - 写入配置内容：
/var/log/myapp/*.log { daily size 50M rotate 7 compress delaycompress copytruncate notifempty missingok }这份配置的意思是：每天检查一次<code>/var/log/myapp/</code>目录下所有<code>.log</code>文件，如果文件大小超过50MB或者满足每日轮转的条件，就进行轮转。总共保留7份旧日志，旧日志会被压缩，并且最近的一份会延迟压缩。 这里我们用了一个新的指令：copytruncate。copytruncatevs.create+postrotate：不同的应用，不同的“通知”方式create+postrotate的组合，是“先搬家，再通知主人”的模式。它先把旧日志文件改名，再创建一个新文件，然后通过脚本通知应用程序来使用这个新文件。这种方式对Nginx、Apache这类设计良好、能响应信号的服务非常有效。- 但有些应用程序可能没有提供这样的信号机制，你没法“通知”它。如果你强行把它的日志文件改名，它可能就找不到地方写日志，或者继续往那个改了名的旧文件里写，导致日志丢失。
- 这种情况下，
copytruncate就派上用场了。它采用的是“复印一份，再把原稿擦干净”的模式。它会先把当前日志文件的内容复制到一个新的备份文件中，然后将原始的日志文件清空（truncate）。这样，应用程序手里的那个文件句柄始终有效，可以继续往那个（现在是空的）原始文件里写，无需被通知。 copytruncate的唯一小缺点是，在“复制”和“清空”这两个动作之间有一个极小的时间窗口，如果此时有新的日志写入，这部分日志可能会丢失。但在大多数场景下，这种风险是可以接受的。
测试你的新配置：--debug 与 --force
修改或创建了配置文件后，我们总想立刻知道它能不能按预期工作，而不是等到第二天早上才发现问题。<code>logrotate</code>提供了两个非常有用的测试参数：
- 模拟运行 (
--debug或-d): Bashsudo logrotate --debug /etc/logrotate.conf这个命令会模拟一次完整的轮转过程，但不会真正执行任何文件操作。它会详细地告诉你，它打算对哪些文件进行轮转、压缩或删除。这是检查你的配置文件语法是否正确、逻辑是否符合预期的最佳方式。 - 强制执行 (
--force或-f): Bashsudo logrotate --force /etc/logrotate.conf这个命令会强制<code>logrotate</code>立即执行一次轮转，即使时间和大小等条件尚未满足。这对于测试你的<code>postrotate</code>脚本或<code>copytruncate</code>是否正常工作非常有用。
常见问题解答 (FAQ)
问：<code>logrotate` 每天到底是什么时候运行的？ 答：这取决于你系统中<code>cron.daily</code>任务的调度时间。你可以查看<code>/etc/crontab</code>或<code>/etc/anacrontab</code>文件来了解每日任务的大致执行时间。通常是在服务器负载较低的凌晨时分。
问：我修改了<code>/etc/logrotate.d/</code>下的配置文件，为什么第二天没生效？ 答：最常见的原因是配置文件存在语法错误。请使用<code>sudo logrotate –debug /etc/logrotate.conf</code>命令来检查，它会明确指出哪个配置文件的哪一行出了问题。其次，检查你修改的文件的权限是否正确，以及配置的日志文件路径是否正确。
**问：<code>copytruncate和create+postrotate到底该用哪个？** 答：首选<code>create</code> +postrotate`。这是一种更“优雅”、更可靠的方式，能保证日志的完整性。只有当你确定你的应用程序不支持通过信号来重新打开日志文件句柄时，再考虑使用<code>copytruncate</code>作为替代方案。
**问：<code>logrotate能管理二进制日志吗？比如MySQL的binlog？** 答：不建议。<code>logrotate 设计初衷是管理基于文本的日志文件。对于像MySQL二进制日志（binlog）这类有特殊格式和管理机制的文件，应该使用数据库自带的工具和参数（如<code>expire_logs_days</code>）来进行管理和清理，以确保数据库主从复制等功能不受影响。
对于日志的价值，不仅仅在于管理，更在于<a href=”/blog/nginx-apache-log-analysis/”>分析这些日志</a>来获取洞见。而日志管理的最终目的，是保障服务器的稳定运行，这与您<a href=”/products/cloud-server/”>选择合适的服务器方案</a>同样重要。如果您在服务器管理上需要任何帮助，随时可以<a href=”/contact-us/”>联系我们</a>。
现在，你已经掌握了<code>logrotate这位“日志管家”的核心技能。它就像一个设定好程序的机器人，日复一日、不知疲倦地为你整理服务器的“历史档案”，让你既能保留宝贵的追溯线索，又无需担心被海量的日志淹没，最终导致“磁盘爆炸”的惨剧。让自动化工具去做那些重复性的脏活累活，我们才能把更多精力投入到更有创造性的工作中。去检查一下你的服务器，看看logrotate</code>是否已经为你辛勤工作吧！如果没有，现在就动手配置起来！