一次切割日志引发的事故

一次切割日志引发的事故

很多应用程序会产生日志，有些程序已经实现了日志切割，一般是每天一个文件。但有时这个切割并不能满足我们的需求，例如我们需要颗粒度更细的切割。 

切割日志的目的是什么？ 

1. 日志尺寸过大 
2. 便于分析 
3. 切割后归档，或者导入日志平台 

切割日志基本两种方法： 

1. 手工或者 shell 
2. 工具,例如logrotate，传统的cronolog 

日志切割方案网上有很多，很多运维也是参考这些方案进行配置，网上的例子不完全都是对的，可能你用了很多年配置方案是错误的。 没有出现故障是侥幸，因为笔者15年前就在此处栽过，由于日志太大，我便清空了日志，以为程序仍然会继续写入，最后直到服务器崩溃。 最近发现很多新手再谈cronolog，我便想起当前发生的故障，有必要跟大家分享。 

首先日志是可以切割的，网上的例子理论上也是可行，但我们不能不求甚解，稀里糊涂的用下去。 

我们首先了解一下日志是怎么产生的，那种日志可以切割，那些日志不能切割，为什么不能切割，如果需要切割日志怎么处理？ 

首先日志是怎么产生的 

日志生命周期，创建/打开日志文件，追加日志记录，关闭日志文件。请看下面伪代码。 

main (){ f = open(/tmp/prog.log) ...
	...
	f.append('DEBUG .............') ...
	f.append('INFO .............') ...
	f.append('WARN .............') f.close()}

这个程序是顺序运行，每次运行都会经历，打开日志文件，追加日志记录，关闭日志文件，一个日志生命周期结束。 在完成日志生命周后，你就可以切割日志了。因为f.close()后日志文件已经被释放。 

再看下面的程序 

main (){ f = open(/tmp/prog.log) loop{ ... ... f.append('DEBUG .............') ... f.append('INFO .............') ... f.append('WARN .............') if(quit){ break } } f.close()}

这个程序就不同了，程序运行，打开日志文件，然后进入无穷循环，期间不断写入日志，知道接到重载命令才会关闭日志。 那么这个程序你就不能随便切割日志。你一旦修改了日志文件，程序将不能在写入日志到文件中。 这个程序切割日志的过程是这样的 

split loop { prog run prog quit && m