前言
这篇博文以课程课件为蓝本来探讨logrotate和自动化日志处理的一系列课题,细节和深层次原理部分略有删减,<强>是一篇被课程耽误了的技术博文。既然谈的很直白,是一篇被课程耽误了的技术博文,如若有打着博客做引导或者拿着开源工具不开源之类的讨伐和道德绑架,恕不回复。
<人力资源/>这里是分割线,不废话了,直接切入正文,对课程有兴趣,想深入理解logrotate的朋友可以关注文末课程介绍:)
1。日志切割的概念,必要性和基本思路
1.1什么是日志切割
日志切割是指当应用或系统的日志文件达到设定的触发条件(如按照一定的时间周期:每天,按照大小:500 mb),对其进行切割/分割处理,类似截断处理,把原本容量比较大的日志文件“劫”走转存为另外一个日志文件留存归档,这一刻之后产生的日志,继续输出到文件头被重置为0的日志文件中。
<强>变化的部分:日志文件的容量(瘦身变小),日志文件的个数(多出一份被切割下的历史日志)
<强>不变的部分:日志文件名不变
此外,一段时间后,我们还需要删除时间久远的日志文件,整个过程也被俗称为日志滚动(日志轮换)。
1.2为什么要进行日志切割
在线应用(包括操作系统)在长期运行过程中,会产生很多过程日志记录,通常是应用程序记录的一些对系统管理员或者程序开发者有用的信息的文件,诸如正在执行什么,发生了什么错误等一系列信息。
随着日志记录的不断积累,日志文件越来越大,随着时间推移,会带来以下弊病:
-
<李>日志文件占用的硬盘空间越来越大李
<李>日志文件太大,达到GB级别后查看内容太耗时,要追踪错误等非常不方便李
一个栗子:
1.3日志切割的基本思路
<强>日志切割的基本需求:
-
<李>
<强>应用层面
切割过程中不影响应用的正常运行(不能停用应用来分割日志)
李 <李><强>数据层面
不丢失日志,或者在可接受的范围内丢失极少日志
切割过程中不影响应用继续输出记录日志(日志文件名不变)
李 <李><强>日志容量层面
切割后新的日志文件从空文件开始重新记录(容量和文件头被重置),便于后续查询使用
李 <李><强>日志归档层面
切割后老旧日志方便归档压缩处理(文件名加上日期后缀等)
分割后的老旧日志可按照保存周期轮询删除
李 <李><强>管理维护层面
自动化周期性进行,周而复始
李从以上需求出发,在满足<强>不停用应用的首要前提强下,可以设计出两种<强>日志切割的基本思路:
-
<李>
<>强思路1 强,重命名移走旧的日志文件,同时生成一个新的日志文件(文件名与切割之前保持一致)
把现有日志mv成另外一个文件,同时自动生成一个同文件名(mv之前的日志文件名)的新日志文件
<强>日志的文件名不变,<强>但是需要确保应用可以指向新的文件句柄
新的日志文件当然从0开始写,日志文件成功瘦身!
<>强思路2 -拷贝并重命名一份现有日志文件,同时把现有容量大的日志文件内容清空
把现有日志文件cp一份为另外的文件名,同时非常快速地把现有日志文件清空
<>强但不改变现有日志文件的文件句柄(在3.1.1章节会有更多详述)。
这样日志文件的文件名和句柄都没有变化,只是内容已经被清空,也是从0开始继续写入,减肥成功!
