最近在搭建日志收集平台，将linux的部分日志收集到elasticsearch上通过kibana进行搜索展现，基本上是标准的ELK架构，但是agent端复用了已有的flume。在功能测试的时候，是将本地messages日志备份出来对备份的日志进行了切割测试。经过一周测试终于完成了，当时的内心是：
日志的切割，采用了linux自带的logrotate进行日志的切割。配置就不放了，主要就是去切割指定的文件，然后将切割的文件转移到agent收集工具监控的目录，然后将文件权限改一下就行。当功能性测试通过后，就需要进行正常的测试了，然后将切割的文件改为系统的messages日志，然后进行logrotate切割测试。然后崩溃的事情来了：
这是什么鬼！！！！！不是测试好好的吗？？？这到底是啥错啊？！！
当然作为一个坚强的小伙子，当经历过一段时间的WFK后，就果断的请来了谷歌大法了。
但是，当查了半天没结果的时候，在stackoverflow上看到有讨论说是logrotate的版本的BUG的时候，我整个人又。。。。。。。
当然作为一个坚强的小伙，我怎么可能真的去睡觉。在被卡了近半天以后，我决定还是去翻翻鸟哥linux的私房菜看看。然后看到了鸟哥linux私房菜里有这么一章《认识与分析日志文件》，然后我就通读里一遍。结果可想而知：
截取了其中一段内容如下：
加入了a这个属性之后，你的 /var/log/messages 登录文件从此就仅能被添加，而不能被删除，直到 root 以『 chattr -a /var/log/messages 』取消这个 a 的参数之后，才能被删除或移动喔！
也就是说，为了保证系统日志的准确性，linux对messages系统日志设置了只能追加不能删和移动，而logrotate需要将文件移动后新建一个新messages文件给系统。所以为了能用logrotate进行切割，我们需要先将messages文件的安全属性a给去掉，当然如果系统管理员直接将这个安全属性去掉的话，在生产环境来说还是不安全的设置。有什么办法能不需要管理员手工去调整安全权限呢？很多管理员第一想法是直接写个脚本去切割的时候改一下，切割完成后改回来不就完了。当然通过shell脚本是可以很好的完成，但是杀鸡焉用牛刀？这个时候logrotate的强大就体现出来了：logrotate可以在配置文件中配置logrotate启动前执行一些shell命令，然后logrotate启动后再执行一些shell命令。你看问题不是迎刃而解了吗？具体到详细的配置文件可以参考如下：
然后完美的完成了！logrotate可以完美切割日志文件，而不需要对当前messages的安全性做任何调整。何其方便！！！！
PS：还是要好好看书！还是要好好看书！还是要好好看书！重要的事情说三遍！
以上完成后，写个定时任务去跑就好了，然后可以到kibana上去搜索日志了：
以上，完美解决！