小服务器日志轮转怎样设置更稳妥

日志轮转这件事，看起来只是改一个配置文件，但真正出问题的时候，往往不是配置语法错了，而是日志把磁盘写满了。小服务器尤其如此，磁盘本来就不大，访问日志、错误日志、应用日志堆在一起，几个月不清理，几GB甚至十几GB就没了。数据库连不上、上传失败、网站响应变慢，很多所谓“莫名其妙”的故障，根源就是磁盘满了。

先明确要管住哪些日志

小服务器上常见的日志有三类：Web服务器（如Nginx、Apache）的访问日志和错误日志，以及应用自身输出的日志。访问日志记录每一次请求，量大但价值密度低；错误日志只在出问题时写入，量小但排查问题时最关键；应用日志则取决于程序怎么写，有的框架会输出调试信息、SQL查询、第三方接口调用记录，量可能比访问日志还大。

设置轮转之前，先搞清楚服务器上到底有哪些日志文件在增长。登录服务器后，用du -sh /var/log/*这类命令按目录看大小，再用ls -lh看具体文件。如果网站部署在Docker容器里，日志可能由容器引擎统一管理，路径和宿主机上的/var/log并不一样。这一步不需要什么技巧，但能避免后面配置了半天，发现管错了文件。

轮转策略怎么定

日志轮转的核心是两条：按大小切，按时间清。按大小切的意思是，单个日志文件超过某个阈值就切分成新文件，避免一个文件无限膨胀；按时间清的意思是，保留最近N天的日志，更早的自动删除。

具体参数取决于服务器的磁盘容量和日志增长速度。判断方法很简单：先看当前磁盘剩余空间，再看日志每天增长多少。假设磁盘还剩5GB，日志每天增长100MB，那么保留30天就需要约3GB，加上系统和其他文件，风险就偏高了。这种情况下保留14天更稳妥。如果日志增长很慢，保留30天甚至60天也没有问题。

访问日志和错误日志的保留周期可以不同。访问日志主要用于短期排查和简单的访问统计，保留7到14天通常足够；错误日志的价值衰减更慢，保留30天以上更有利于追踪间歇性故障。应用日志则看框架的约定，有的框架自带轮转配置，有的需要外部工具配合。

Linux系统上最常用的轮转工具是logrotate。它的配置文件通常位于/etc/logrotate.d/目录下，每个服务可以有一个独立配置。一个典型的配置片段包含日志路径、轮转周期、保留份数、是否压缩等选项。修改配置后，可以用logrotate -d（调试模式）检查语法，用logrotate -f强制触发一次轮转来验证效果。注意，-d只是打印将要执行的动作，并不会真的轮转；-f会强制执行，适合在修改配置后手动验证。

压缩与权限的细节

旧日志建议压缩存储。文本日志的压缩率很高，通常能压到原来的十分之一甚至更低。logrotate中对应的选项是compress，压缩后的文件会以.gz结尾。需要注意的是，压缩只对已经轮转出去的旧文件生效，当前正在写入的日志文件不会压缩。

权限问题也容易踩坑。日志文件通常由服务进程创建，运行用户可能是www-data、nginx或mysql。如果logrotate以root身份运行，轮转后创建的新文件可能属于root，导致服务进程无法继续写入。解决办法是在配置中显式指定create选项，设置新文件的属主、属组和权限位。例如create 640 www-data www-data表示新文件属主为www-data，权限为640。修改配置后，建议观察一下轮转产生的新文件权限是否正确。

另一个容易忽略的点是信号通知。某些服务（如Nginx）在日志被轮转后，仍然持有旧文件的文件描述符，继续往已改名甚至已删除的文件里写数据。logrotate配置中的postrotate脚本可以解决这个问题，通常的做法是执行nginx -s reopen让服务重新打开日志文件。对于其他服务，需要查阅对应文档确认重载或重开日志的方式。如果漏掉这一步，表现就是日志文件被轮转了，但新日志没有写入新文件，磁盘空间也没有释放。

磁盘阈值提醒与恢复边界

轮转配置得再好，也不能完全依赖它。磁盘写满往往发生在日志量突增的时候，比如被爬虫集中抓取、程序出现死循环写日志、或者攻击导致大量错误请求。这种情况下，日志可能在几小时内就涨满磁盘，而定时轮转可能一天才执行一次。

设置磁盘阈值提醒是必要的防线。可以用df -h查看当前磁盘使用率，配合cron定时任务，当使用率超过某个阈值（比如85%或90%）时发送告警。告警方式可以是邮件，也可以是其他通知渠道，取决于服务器上有什么现成工具。关键是阈值要低于磁盘满的临界点，留出人工介入的时间。

恢复边界要提前想清楚：如果磁盘真的满了，第一步做什么？通常的做法是找出最大的日志文件，手动触发一次轮转或直接删除最旧的压缩日志，先释放出可用空间，再排查日志暴涨的原因。不要一上来就删当前正在写入的日志文件，那样可能导致服务进程异常，而且删掉的文件无法恢复。删除旧日志后，确认服务恢复正常，再回头分析为什么日志增长这么快。

验证轮转是否真正生效

配置完成后，验证不能只看配置文件语法正确。最直接的方法是查看日志目录里的文件列表，确认旧日志被压缩、新日志已创建、文件权限正确。具体来说，检查三点：轮转后的新文件是否由正确的用户写入，旧文件是否被压缩，保留份数是否和配置一致。

如果配置了按天轮转，可以手动执行一次logrotate -f来立即触发，而不必等到第二天。执行后观察日志目录的变化，再确认服务进程是否正常写入新日志。如果发现服务没有写入新日志，检查postrotate脚本是否执行成功，以及服务进程是否真的重新打开了日志文件。

长期运行后还要定期检查，因为日志增长速度可能随网站流量变化而变化。原来每天100MB，半年后可能变成每天500MB，保留天数不变的情况下，磁盘占用会明显上升。建议每季度或每半年查看一次日志目录的总大小，和磁盘剩余空间做个对比，必要时调整保留份数或轮转阈值。

记录改动，方便日后恢复

日志轮转配置改动后，值得在服务器上留一份简短记录，写明改了哪些文件、设置了什么参数、验证过哪些路径、出现异常时如何恢复。这份记录不需要很长，几行字即可，但在半年后排查问题或迁移服务器时会非常有用。

小服务器的日志管理，目标不是把配置写得多么复杂，而是让磁盘空间可预期、故障时可追溯。轮转周期、保留份数、压缩策略、权限设置、信号通知、磁盘告警，这几项都确认到位，日志就不会成为拖垮服务器的隐患。