对Apache日志文件大小的思考？

你应该以另一种方式来处理它，而不是限制这些日志文件，制定一个总是有足够日志空间的系统，以便永远不会填满磁盘。

我这样做的主要方法是简单地计算需要多less空间，并给它足够的空间，但我也有一个脚本，将检查日志目录中的磁盘空间，如果它变得紧张会自动旋转日志文件，压缩旧版本，并删除那些已存档的介质上已经足够大的文件。

那么， 不限制日志大小的主要原因是：

• 提供了有用的审计日志
• 提供详细的访问日志
• 作为未来分析的数据库：
  • 其他网站推介
  • 内部导航path
  • 内部随机select的内容日志
  • 用于debugging缓慢的报告错误

限制日志大小的主要原因是不占用磁盘空间。 但这是相当蹩脚的 – 现在1.5TB硬盘的价格大约是120美元。

我会build议根据日志文件大小来定制日志文件。 如果您的网站使用率极高，则会生成大量日志条目，并根据文件大小进行旋转，这些文件的大小足以在文本编辑器中进行有效处理，或者查看日志，并保持日志足够小以压缩和发送给其他人解决问题。 如果您正在生成less量日志条目，则个人偏好是每天轮换一次，以便我可以轻松地处理错误。 再加上每天轮换，我可以看到基于文件大小的利用率和错误的峰值。

日志保留应该由个人需求，统计分析需求或企业标准/规定来驱动。 如果您想parsing日志并查找使用模式，统计信息或用于审计目的，则可能需要保留大量的日志文件。 日志文件压缩到惊人的小尺寸，所以很容易保留大量的。

我们设置自动压缩 – >存档和最终删除过程根据我们的保留政策，以保持系统pipe理降到最低。

但是为什么删除它们的时候可以简单地使用bzip2 / tar / cpio它们。
文本文件具有很高的压缩率。
或者只是将它们归档到磁带（便宜的存储空间和持久的），无论是否压缩

在旋转之前限制大小。 较小的原始文件在被压缩的时候会在你的networking服务器上消耗更less的时间。

你想要保留多less个旋转的日志是一个单独的问题。

在生产机器上，我根本不删除它们，只是将它们归档如上所述。

但是在一台开发机器上，这些日志只会在短时间内有用，所以阻止它们填充太多的磁盘空间是非常有意义的 – 特别是在根文件系统在SSD而不是HDD上的机器上更小的驱动器尺寸）。