答案：通过logrotate实现日志自动切割，结合copytruncate或信号通知确保服务持续写入，并用tail -F或filebeat正确监控。
Linux系统中日志文件会随着时间不断增长，过大的日志不仅占用磁盘空间，还会影响排查问题的效率。通过logrotate工具可以实现日志的自动切割、压缩和清理。但切割后如何保证服务能正确写入新日志，并且监控程序能实时感知变化，是运维中常见的痛点。
logrotate的基本配置与日志切割原理
logrotate 是Linux下管理日志文件的默认工具，它通过配置文件定义日志的轮转策略，比如按天、按大小、保留份数等。
常见配置位于：/etc/logrotate.conf 和 /etc/logrotate.d/ 目录下的服务专属配置文件。
例如，为应用日志 /var/log/myapp.log 设置每日切割并保留7份：
/var/log/myapp.log { daily missingok rotate 7 compress delaycompress copytruncate notifempty }说明：
- daily：每天轮转一次
- rotate 7：保留最近7个历史日志
- compress：使用gzip压缩旧日志
- copytruncate：复制日志后清空原文件，适用于无法重载的服务
- delaycompress：延迟压缩最新一份旧日志
使用copytruncate确保服务持续写日志
某些服务（如自研脚本或未使用日志库的程序）不会监听日志文件句柄变化。当logrotate直接移动文件时，进程仍在向原inode写入，导致新日志丢失。
copytruncate 模式可解决这个问题：
- 先复制当前日志内容到新文件
- 然后清空原日志文件（不改变文件名和inode）
- 服务无需重启或重载，继续写入原路径
缺点是复制和清空之间可能丢失少量日志，但在无法发送信号重载的场景下是稳妥选择。
配合信号通知实现精确切换（推荐方式）
更优雅的方式是让服务在日志轮转后重新打开日志文件。这通常通过发送信号实现。
例如Nginx、Apache等支持 USR1 或 reopen 信号：
/var/log/nginx/*.log { daily rotate 10 compress missingok postrotate systemctl kill --signal=USR1 nginx endscript }关键点：
- postrotate ... endscript 块中执行命令
- USR1信号触发Nginx关闭并重新打开日志文件
- 避免使用copytruncate，减少日志丢失风险
实时监控切割后的日志技巧
使用 tail -f 或日志采集工具（如filebeat、fluentd）监控日志时，若文件被移动或重建，可能会中断跟踪。
解决方案：
- 用 tail -F 替代 tail -f。
-F 会持续追踪文件名，即使被删除重建也能恢复跟踪。 - 在 filebeat 配置中启用
close_eof: true和clean_removed: true，并合理设置扫描周期，避免遗漏新切出的日志。 - 对于copytruncate场景，由于文件未被替换，监控工具不受影响，可安全使用常规模式。
基本上就这些。合理配置logrotate，结合服务特性选择copytruncate或信号通知，再搭配正确的监控方式，就能实现稳定可靠的日志切割与实时跟踪。关键是理解文件句柄与文件名的关系，以及不同服务对日志重载的支持情况。不复杂但容易忽略细节。
