宝塔面板日志轮转需手动配置logrotate实现自动化切割，因默认不接管系统日志机制且Nginx等服务无内置切割功能；需新建/etc/logrotate.d/bt-logs配置文件，启用daily、create、sharedscripts及postrotate调用kill -USR1等指令，并配合find命令定期清理90天前压缩包。
宝塔面板的日志文件，包括 bt、nginx、apache 以及各个站点的访问日志，若长期不进行管理，体积膨胀至10GB甚至几十GB是常见现象。这并非配置错误，其根本原因在于——系统日志轮转机制并未被正确启用。
宝塔面板为何默认不自动切割日志？
这需要从系统日志管理机制说起。宝塔面板本身并不干预系统级的日志轮转策略。无论是 /www/wwwlogs/ 目录下的网站访问日志，还是 /www/server/panel/logs/ 下的面板操作日志，均由对应的服务进程（如Nginx、Apache或Python）直接写入，这些服务本身不具备自动日志分割功能。而系统自带的 logrotate 工具，默认配置仅监控 /var/log/ 等标准系统日志目录，对于宝塔自定义的日志存储路径，它不会自动识别和处理。
- 因此，
logrotate不会自动发现并处理/www/wwwlogs/或/www/server/panel/logs/目录中的日志文件。 - 更进一步，即使手动添加了配置，若未正确设置
create和dateext等关键参数，旧日志文件可能被直接覆盖而非归档保存。 - 另一个技术要点：Nginx的
access_log指令本身不支持在运行时动态重新打开日志文件。这意味着，仅移动或重命名日志文件后，Nginx进程仍会向旧的文件句柄写入数据。必须通过kill -USR1命令向Nginx主进程发送信号，通知其重新加载日志文件，才能实现无缝切换。
手动配置logrotate管理宝塔日志（含Nginx重载信号）
解决方案清晰直接：手动为宝塔的日志目录创建专属的 logrotate 配置文件。在 /etc/logrotate.d/ 目录下新建一个文件，例如命名为 bt-logs，其内容配置如下：
"/www/wwwlogs/*.log" "/www/server/panel/logs/*.log" {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 644 www www
sharedscripts
postrotate
if [ -f /www/server/nginx/logs/nginx.pid ]; then
kill -USR1 `cat /www/server/nginx/logs/nginx.pid`
fi
if [ -f /www/server/apache/logs/httpd.pid ]; then
/www/server/apache/bin/httpd -k graceful
fi
endscript
}
- 路径必须使用引号：使用双引号包裹包含通配符的路径，可防止因站点名称包含空格或特殊字符而导致
logrotate解析错误。 - 共享脚本指令至关重要：
sharedscripts指令确保所有匹配到的日志文件，在整个轮转周期内仅共同执行一次postrotate脚本。避免每处理一个.log文件就重载一次服务，造成不必要的性能开销和潜在风险。 - 文件权限与属主设置：
create 644 www www这一行设置非常关键。它定义了新创建日志文件的权限（644）和属主/属组（www:www）。Nginx日志通常由www用户写入，若不正确设置权限，可能导致日志记录失败。 - 延迟压缩的实用价值：
delaycompress参数的作用是，在本次轮转后暂不压缩上一个日志文件（例如.log.1），为你留出检查日志内容的时间窗口。压缩操作将在下一次轮转时执行。
验证logrotate配置生效与排查常见故障
配置文件完成后，建议立即进行测试验证，无需等待次日自动执行。使用调试模式运行以下命令：
logrotate -d /etc/logrotate.d/bt-logs
仔细分析命令输出，重点关注是否出现 rotating pattern（正在轮转的模式）和 running postrotate script（正在运行后续脚本）等关键提示。若未发现相关提示，通常由以下原因导致：
- 路径或权限错误：首先使用
ls -l /www/wwwlogs/确认目录存在且可读。然后通过ps aux | grep nginx命令核实Nginx进程的PID文件路径是否与配置中/www/server/nginx/logs/nginx.pid一致。 - 脚本命令路径不匹配：
postrotate脚本中若使用绝对路径，需确保命令真实存在。例如，某些系统中kill命令位于/bin/kill，为保险起见可显式指定为/bin/kill -USR1。 - 日志文件被进程锁定：某些后台程序（如部分Python脚本）可能长期持有日志文件的打开句柄。使用
lsof +D /www/wwwlogs/命令可查看具体是哪个进程占用了文件。 - 配置文件语法错误：仔细检查配置文件，确保没有遗漏闭合的
}，且缩进格式正确。logrotate对语法错误有时会静默忽略，不报错但也不执行。
附加保障：使用crontab定期清理过期压缩日志
请注意，logrotate 仅负责日志的轮转和压缩，并不自动删除历史文件。那些压缩后的 .log.1.gz、.log.2.gz 等文件会持续累积。因此，我们需要增加一道“安全阀”，定期清理超期的压缩包：
/usr/bin/find /www/wwwlogs/ /www/server/panel/logs/ -name "*.log.*.gz" -mtime +90 -delete
将此命令添加到系统的crontab计划任务中，例如设置为每周日凌晨0点执行：
0 0 * * 0 /usr/bin/find /www/wwwlogs/ /www/server/panel/logs/ -name "*.log.*.gz" -mtime +90 -delete
- 务必使用绝对路径：crontab执行环境中的PATH变量通常非常有限，直接写
find可能无法找到命令，因此必须前置/usr/bin/find。 - 正确理解时间参数：
-mtime +90表示查找并操作修改时间在90天之前的文件。对于压缩包而言，其修改时间即压缩完成的时间，符合我们的清理逻辑。 - 避免使用粗暴删除命令：切勿为图省事使用类似
rm -f /www/wwwlogs/*.gz的命令，它可能误删正在被使用的临时压缩文件，导致不可预知的问题。
最后，提供一个最直接的验证方法：检查Nginx是否成功接收了USR1信号。在日志轮转发生后，执行 tail -f /www/server/nginx/logs/error.log 命令，若能看到 reopening logs 的提示信息，则证明信号发送成功。如果未发现该提示，则需要回头检查 postrotate 脚本的执行权限或PID文件路径是否正确。
