nginx日志切割与归档最佳实践

Nginx日志切割与归档最佳实践

一、日志切割的核心必要性

Nginx作为高性能Web服务器，其access.log（访问日志）和error.log（错误日志）会随时间持续增长。未管理的日志文件可能导致：磁盘空间被占满（引发服务中断）、日志分析效率低下（无法快速定位特定时间段问题）、备份成本上升等问题。日志切割（Log Rotation）通过定期重命名当前日志文件、创建新文件并清理旧文件的循环过程，是解决这些痛点的关键手段。

二、主流工具选择：logrotate（系统自带，推荐）

Linux系统自带logrotate工具，具备定时执行、按时间/大小切割、压缩、删除过期日志、通知服务重启等功能，无需额外安装第三方依赖，是Nginx日志管理的最佳选择。其配置文件路径为：

主配置文件：/etc/logrotate.conf（全局默认参数）
自定义配置目录：/etc/logrotate.d/（第三方服务配置，推荐将Nginx配置放在此目录）。

三、logrotate配置详解（Nginx专用）

以下是一个按天轮转的Nginx日志配置示例（保存为/etc/logrotate.d/nginx），包含核心参数及说明：

/usr/local/nginx/logs/*.log {  # 监控Nginx日志目录下的所有.log文件
    daily                      # 每天轮转一次（可选：weekly/monthly/yearly）
    missingok                  # 日志文件不存在时不报错（避免因Nginx未启动导致切割失败）
    rotate 30                  # 保留最近30个归档日志（超过则删除最旧的）
    compress                   # 使用gzip压缩旧日志（节省约60%-80%存储空间）
    delaycompress              # 延迟压缩：当天切割的日志不立即压缩（避免影响Nginx写入）
    notifempty                 # 日志为空时不轮转（减少不必要的操作）
    create 0644 nginx nginx    # 切割后创建新日志文件，权限644，属主/组为nginx（需与Nginx运行用户一致）
    sharedscripts              # 所有日志文件处理完毕后，只执行一次postrotate脚本（避免重复发送信号）
    postrotate                 # 切割后执行的命令（关键：通知Nginx重新打开日志文件）
        if [ -f /usr/local/nginx/logs/nginx.pid ]; then  # 检查Nginx PID文件是否存在
            kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid)  # 发送USR1信号，Nginx会自动切换到新日志文件
        fi
    endscript
}

参数关键说明：

delaycompress：避免当天日志被压缩，防止Nginx因无法写入压缩文件而报错；
sharedscripts：确保postrotate脚本只执行一次，避免多次发送信号导致Nginx异常；
create：必须指定正确的属主和权限，否则Nginx无法写入新日志文件。

四、不同场景的切割策略

根据业务需求，可选择不同的切割频率：

中小站点（日均日志<1GB）：使用daily+rotate 30+compress，保留30天日志，满足日常分析需求；
大流量站点（日均日志>1GB）：结合size 100M（当日志文件超过100MB时立即切割），防止单文件过大导致磁盘IO瓶颈；
合规需求（长期归档）：使用monthly+rotate 24（保留2年），或yearly+rotate 10（保留10年），满足《网络安全法》等法规要求。

五、测试与自动化

测试配置有效性：
- 模拟运行（不实际执行）：logrotate -d /etc/logrotate.d/nginx（查看执行流程，确认参数是否正确）；
- 强制立即执行：logrotate -f /etc/logrotate.d/nginx（强制切割，用于测试配置是否生效）。
设置定时任务：
编辑/etc/crontab，添加以下内容（每天23:59执行，避免跨天导致日期错误）：
```
59 23 * * * root /usr/sbin/logrotate -f /etc/logrotate.d/nginx > /dev/null 2>&1
```
重启crontab服务使配置生效：systemctl restart crond。

六、常见问题与解决方案

问题：日志未切割
- 原因：logrotate未运行（检查/etc/cron.daily/logrotate是否存在）；
- 解决：手动执行logrotate -f /etc/logrotate.d/nginx，确认配置是否正确。
问题：切割后Nginx不写新日志
- 原因：postrotate脚本未正确发送USR1信号；
- 解决：检查postrotate中的PID文件路径（需与Nginx实际路径一致），确保kill -USR1命令能正常执行。
问题：权限错误（新日志无法写入）
- 原因：create参数指定的属主/组或权限不正确；
- 解决：将属主设置为Nginx运行用户（通常为nginx），权限设置为0644（如create 0644 nginx nginx）。
问题：日志被重复压缩
- 原因：缺少delaycompress参数；
- 解决：添加delaycompress，延迟压缩当天切割的日志。

七、最佳实践建议

中小站点：使用daily+rotate 30+compress，满足基本日志管理需求；
大流量站点：结合size 100M，防止单文件过大导致磁盘IO瓶颈；
合规需求：按月/年归档，保留5~10年，满足法规要求；
集中管理：将切割后的日志同步到ELK（Elasticsearch+Logstash+Kibana）、Splunk等日志分析平台，实现统一的日志存储、分析与可视化；
监控告警：通过Zabbix、Prometheus等工具监控日志目录大小（如/usr/local/nginx/logs），当磁盘使用率超过80%时触发告警，提前处理。