据我所知，Log4Perl 或其在 CPAN 中的任何相关模块都不支持日志文件的旋转和压缩。
旋转可以通过使用来完成：
但是两个模块都不支持旋转和压缩。（Log::Dispatch::FileRotate 在它的待办事项列表中有它，但它目前没有实现）。
可以使用 Linux 中的标准Logrotate工具来执行此操作，方法是使用 Log::Log4perl::Appender::File 的 recreate_check_interval 或 recreate_check_signal。
从最初的测试来看，使用带有delaycompress选项的 Logrotate 似乎可以解决问题——即使在高负载的机器上，一旦文件被移动，log4perl 将继续记录到同一个文件句柄，直到信号被输出。
但是，如果没有使用 delaycompress，并且在日志文件的压缩和 Perl 程序捕获信号之间存在（甚至是轻微的延迟），则可能会丢失一些日志数据。
你怎么看？还有其他我们没有想到的选择吗？
多年来，我发现您几乎总是希望使用外部方法来使用 Log4perl 进行日志文件轮换。您只需避免内部日志轮换不可避免地遇到的许多微妙问题（日志延迟、权限问题）。
您已经提到了在 Linux 上使用 logrotate 的两种方法，为什么不坚持使用它们呢？Log4perl FAQ 描述了使用 newsyslog，它是 FreeBSD 的 logrotate 等价物，并提供类似的功能。
我按照这里的建议联系了 Log::Dispatch::FileRotate 的作者，他解释了 Log::Dispatch::FileRotate 中尚未实现压缩的原因。
基本上，在旋转后立即压缩可能会在压缩过程中阻塞运行过程，这非常昂贵。
建议的选项是允许 Log::Dispatch::FileRotate 的用户在旋转之后对文件执行任意应用程序，从而在另一个非阻塞进程中执行此操作。
另一个建议是让文件系统触发器（如inotify）在文件关闭以由主进程写入时触发压缩。
另一个建议是编写通过 gzip 管道或 perl gzip 模块之一压缩的日志文件。这可行，但会导致一些问题（grep/less）不起作用。zgrep 和 zless 可以工作，但是 zgrep 会在对仍然打开以供写入的 gzip 文件进行 grep 时发出难看的警告。在文件上使用“tail”也不起作用 - 所以这个选项不实用。
您是否考虑过与 Log::Dispatch::FileRotate 的维护者合作来添加它缺少的和您需要的功能？毕竟它是开源的。:)
如果您不想自己处理，有各种 CPAN 支持咨询公司可以为您做这件事。