日志rotate和日志采集

两种切割模式

1.1、create模式

1、首先重命名当前进程正在输出的日志文件名称，因为进程是根据 inode 号来确定往哪个日志文件输出，更改日志文件名称并不会影响inode号，所以这步行为中，进程依旧会往修改了名称的日志文件内输出日志。

2、进行新的日志创建，创建新的日志名称和老旧的日志名称一样，但是因为是新建的。所以inode号不一样。此时进程日志还是依旧输出到老的被重命名了的日志文件里面。

3、对进程发起信号通知，让其重新写日志。

常用的logback就是基于该模式。

1.2、copytruncate模式

1、copy当前日志文件，重命名为新文件，这样进程还是往老的文件写入。

2、然后logrotate对老文件进行truncate，对老文件进行清空。这样就完成了一次日志切割。

这种日志切割不需要对进程发起重载信号。

风险：

• 因为会对日志文件进行copy，如果系统文件巨大，那么系统可用空间会突然暴增。
• copy到truncate的中间短暂间隔，日志还在写，一旦truncate了，中间的日志可能存在日志丢失

Caution

一般不建议使用copytruncate模式，如果使用Loggie采集copytruncate模式切割的日志，file source的path请配置具体写入的文件名称。

比如一直写入app.log，切割后的文件为app-1.log，app-2.log等，请配置path为app.log，而不是*.log，因为copy之后是一个新的文件，由于Loggie根据inode+deviceId等来识别文件的唯一性而不是文件名，如果匹配到切割后的文件，会重复采集这部分的日志。