一、为什么需要日志切割
日志文件就像是我们系统的日记本，记录着服务器运行的点点滴滴。但是如果不加管理，这个日记本就会变得越来越厚，最后变成一本永远翻不完的大部头。想象一下，一个日志文件动辄几十GB，不仅占用磁盘空间，查找问题的时候更是像大海捞针。
OpenResty作为Nginx的增强版本，默认情况下会把所有日志都写到一个文件里。时间一长，这个文件就会变得异常庞大。这时候就需要引入日志切割的概念，简单说就是把大日志文件按照一定规则切成小份，方便管理和分析。
二、OpenResty日志切割的常见方案
目前主流的日志切割方案主要有三种：第一种是使用Linux自带的logrotate工具，第二种是通过OpenResty的Lua脚本实现，第三种是借助crontab定时任务配合shell脚本完成。这三种方式各有优劣，我们今天重点讲第二种方案，因为它最灵活也最能体现OpenResty的特性。
logrotate虽然方便，但是配置不够灵活；crontab方案虽然简单，但是切割时可能需要重启服务；而Lua脚本方案可以在不中断服务的情况下完成切割，还能加入各种自定义逻辑。
三、基于Lua的日志切割实现
下面我们来看一个完整的Lua日志切割脚本示例，这个脚本可以放在OpenResty的access_by_lua阶段执行：
-- 引入必要的Lua库
local io = require "io"
local os = os
local string = string
-- 定义日志文件路径
local log_path = "/var/log/openresty/access.log"
local old_log_path = "/var/log/openresty/access_%Y%m%d%H%M.log"
-- 检查是否需要切割日志
local function need_rotate()
-- 获取当前日志文件大小(MB)
local file = io.open(log_path, "r")
if not file then return false end
local size = file:seek("end") / (1024 * 1024)
file:close()
-- 如果日志文件超过100MB就切割
return size > 100
end
-- 执行日志切割
local function rotate_log()
-- 生成带时间戳的新日志文件名
local new_log_path = os.date(old_log_path)
-- 重命名当前日志文件
os.rename(log_path, new_log_path)
-- 通知OpenResty重新打开日志文件
os.execute("kill -USR1 `cat /usr/local/openresty/nginx/logs/nginx.pid`")
end
-- 主逻辑
if need_rotate() then
rotate_log()
end
这个脚本的工作原理是：每次请求进来时都会检查当前日志文件大小，如果超过100MB就执行切割操作。切割过程包括重命名日志文件和通知OpenResty重新打开日志文件两个步骤。
四、进阶配置与优化
上面的基础方案虽然能用，但在生产环境中还需要考虑更多细节。下面我们来看一个增强版的实现：
-- 增强版日志切割配置
local function setup_log_rotation()
-- 配置参数
local config = {
max_size_mb = 100, -- 单个日志文件最大100MB
keep_days = 7, -- 保留最近7天的日志
compress = true, -- 是否压缩旧日志
check_interval = 10, -- 每10次请求检查一次
request_count = 0 -- 请求计数器
}
-- 定期清理旧日志
local function clean_old_logs()
local now = os.time()
local pattern = "/var/log/openresty/access_*.log"
if config.compress then
pattern = "/var/log/openresty/access_*.log.gz"
end
-- 遍历日志目录
for filename in io.popen('ls '..pattern):lines() do
local mtime = io.popen('stat -c %Y '..filename):read("*a")
local file_time = tonumber(mtime)
-- 删除超过保留天数的日志
if now - file_time > config.keep_days * 86400 then
os.remove(filename)
end
end
end
-- 增强版日志切割
return function()
config.request_count = config.request_count + 1
-- 达到检查间隔才执行检查
if config.request_count % config.check_interval ~= 0 then
return
end
-- 检查日志大小
local file = io.open(log_path, "r")
if not file then return end
local size = file:seek("end") / (1024 * 1024)
file:close()
-- 需要切割
if size > config.max_size_mb then
local new_log_path = os.date(old_log_path)
os.rename(log_path, new_log_path)
-- 如果需要压缩
if config.compress then
os.execute("gzip "..new_log_path)
end
-- 通知Nginx重新打开日志
os.execute("kill -USR1 `cat /usr/local/openresty/nginx/logs/nginx.pid`")
-- 清理旧日志
clean_old_logs()
end
end
end
-- 初始化日志切割
local log_rotator = setup_log_rotation()
log_rotator()
这个增强版增加了几个实用功能：
- 不是每次请求都检查日志大小，而是每10次请求检查一次，减少性能开销
- 增加了日志压缩功能，可以节省磁盘空间
- 自动清理超过7天的旧日志，避免磁盘被占满
- 所有配置参数集中管理，方便调整
五、性能考量与注意事项
在实际使用中，有几点需要特别注意：
性能影响：虽然Lua脚本很高效，但频繁的文件操作还是会带来额外开销。建议将检查间隔设置为50-100次请求检查一次，具体数值需要根据实际流量调整。
文件权限：确保OpenResty工作进程有权限读写日志目录。最好专门为日志创建一个用户组，把OpenResty用户加入这个组。
信号处理：USR1信号是Nginx的标准信号，用于重新打开日志文件。不同版本的Nginx/OpenResty可能略有差异，建议先测试确认。
异常处理：增加错误处理逻辑，比如文件操作失败时的回退方案，避免因为日志切割失败影响正常服务。
监控报警：建议监控日志切割是否正常执行，可以记录切割事件到单独的文件，或者发送通知到监控系统。
六、与其他工具的集成方案
虽然我们主要讲Lua方案，但在实际环境中往往会结合其他工具使用。比如可以用logrotate做兜底方案，防止Lua脚本意外失效。下面是一个简单的logrotate配置示例：
/var/log/openresty/access.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
sharedscripts
postrotate
[ -f /usr/local/openresty/nginx/logs/nginx.pid ] && kill -USR1 `cat /usr/local/openresty/nginx/logs/nginx.pid`
endscript
}
这个配置会每天切割一次日志，保留30天的日志备份，并且同样使用USR1信号通知Nginx重新打开日志文件。与Lua方案配合使用时，可以把logrotate的maxsize参数设置得比Lua脚本的阈值大一些，让它主要起到兜底作用。
七、总结与最佳实践建议
经过上面的讨论，我们可以得出几个最佳实践建议：
对于高流量网站，推荐使用Lua方案进行基于大小的实时切割，辅以logrotate做定期兜底切割。
切割阈值建议设置在100-500MB之间，具体取决于你的磁盘性能和日志重要性。
一定要实现旧日志的自动清理，避免磁盘空间被占满。保留天数建议7-30天，根据业务需求调整。
考虑添加日志压缩功能，特别是对于访问量大的网站，可以节省大量磁盘空间。
做好监控，确保日志切割机制正常运行，及时发现并解决问题。
在测试环境充分验证后再上线生产环境，避免配置错误影响服务。
评论