从头开始写一个日志采集Agent

作为一个日志采集Agent在大多数人眼中可能就是一个数据“搬运工”，还会经常抱怨这个“搬运工”用了太多的机器资源，简单来看就是一个tail -f命令，再贴切不过了，对应到Fluentd里面就是in_tail插件。笔者作为一个亲身实践过日志采集Agent的开发者，希望通过本篇文章来给大家普及下日志采集Agent开发过程中的一些技术挑战。为了让整篇文章脉络是连续的，笔者试图通过“从头开始写一个日志采集Agent”的主题来讲述在整个开发过程中遇到的问题。

如何发现一个文件?

当我们开始写日志采集Agent的时候遇到的第一个问题就是怎么发现文件，最简单的方式就是用户直接把要采集的文件罗列出来放在配置文件中，然后日志采集Agent会读取配置文件找到要采集的文件列表，最后打开这些文件进行采集，这恐怕是最为简单的了。但是大多数情况日志是动态产生的，会在日志采集的过程中动态的创建出来, 提前罗列到配置文件中就太麻烦了。正常情况下用户只需要配置一个日志采集的目录和文件名字匹配的规则就可以了，比如Nginx的日志是放在 /var/www/log 目录下，日志文件的名字是 access.log 、 access.log-2018-01-10 …..类似于这样的形式，为了描述这类文件可以通过通配符或者正则的表示来匹配这类文件例如: access.log(-[0-9]{4}-[0-9]{2}-[0-9]{2})? 有了这样的描述规则后日志采集Agent就可以知道哪些文件是需要采集的，哪些文件是不用采集的。接下来会遇到另外一个问题就是如何发现新创建的日志文件?，定时去轮询下目录或许是个不错的方法，但是轮询的周期太长会导致不够实时，太短又会耗CPU，你也不希望你的采集Agent被人吐槽占用太多CPU吧。Linux内核给我们提供了高效的Inotify的机制，由内核来监测一个目录下文件的变化，然后通过事件的方式通知用户。但是别高兴的太早，Inotify并没有我们想的那么好，它存在一些问题，首先并不是所有的文件系统都支持Inotify，此外它不支持递归的目录监测，比如我们对A目录进行监测，但是如果在A目录下面创建了B目录，然后立刻创建C文件，那么我们只能得到B目录创建的事件，C文件创建的事件就会丢失，最终会导致这个文件没有被发现和采集。对于已经存在的文件Inotify也无能为力，Inotify只能实时的发现新创建的文件。Inotify manpage中描述了更多关于Inotify的一些使用上的限制以及bug。如果你要保证不漏采那么最佳的方案还是Inotify+轮询的组合方式。通过较大的轮询周期来检测漏掉的文件和历史文件，通过Inotify来保证新创建的文件在绝大数情况下可以实时发现，即使在不支持Inotify的场景下，单独靠轮询也能正常工作。到此为止我们的日志采集Agent可以发现文件了，那么接下来就需要打开这个文件，然后进行采集了。但是天有不测风云，在我们采集的过程中机器Crash掉了，我们该如何保证已经采集的数据不要再采集了，能够继续上次没有采集到的地方继续呢?

基于轮询的方式其优点就是保证不会漏掉文件，除非文件系统发生了bug，通过增大轮询的周期可以避免浪费CPU、但是实时性不够。Inotify虽然很高效，实时性很好但是不能保证100%不丢事件。因此通过结合轮询和Inotify后可以相互取长补短。

基于轮询的方式其优点就是保证不会漏掉文件，除非文件系统发生了bug，通过增大轮询的周期可以避免浪费CPU、但是实时性不够。Inotify虽然很高效，实时性很好但是不能保证100%不丢事件。因此通过结合轮询和Inotify后可以相互取长补短。

点位文件? 对就是通过点位文件来记录文件名和对应的采集位置。那如何保证这个点位文件可以可靠的写入呢? 因为可能在文件写入的那一刻机器Crash了导致点位数据丢掉或者数据错乱了。要解决这个问题就需要保证文件写入要么成功，要么失败，绝对不能出现写了一半的情况。Linux内核给我们提供了原子的rename。一个文件可以原子的rename成另外一个文件，利用这个特性可以保证点位文件的高可用。假设我们已经存在一份点位文件叫做offset，每一秒我们去更新这个点位文件，将采集的位置实时的记录在里面，整个更新的过程如下：

• 将点位数据写入到磁盘的 offset.bak 文件中
• fdatasync确保数据写入到磁盘
• 通过 rename 系统调用将 offset.bak 更名为 offset

通过这个手段可以保证在任何时刻点位文件都是正常的，因为每次写入都会先确保写入到临时文件是成功的，然后原子的进行替换。这样就保证了offset文件总是可用的。在极端场景下会导致1秒内的点位没有及时更新，日志采集Agent启动后会再次采集这1秒内的数据进行重发，这基本上满足需求了。

但是点位文件中记录了文件名和对应的采集位置这会带来另外一个问题，如果在进程Crash的过程中，文件被重命名了该怎么办? 那启动后岂不是找不到对应的采集位置了。在日志的这个场景下文件名其实非常不可靠，文件的重命名、删除、软链等都会导致相同的文件名在不同时刻其实指向的是不同的文件，而且将整个文件路径在内存中保存其实是非常耗费内存的。Linux内核提供了inode可以作为文件的标识信息，而且保证同一时刻Inode是不会重复的，这样就可以解决上面的问题，在点位文件中记录文件的inode和采集的位置即可。日志采集Agent启动后通过文件发现找到要采集的文件，通过获取Inode然后从点位文件中查找对应的采集位置，最后接着后面继续采集即可。那么即使文件重命名了但是它的Inode不会变化，所以还是可以从点位文件中找到对应的采集位置。但是Inode有没有限制呢? 当然有，天下没有免费的午餐，不同的文件系统Inode会重复，一个机器可以安装多个文件系统，所以我们还需要通过dev(设备号)来进一步区分，所以点位文件中需要记录的就是dev、inode、offset三元组。到此为止我们的采集Agent可以正常的采集日志了，即使Crash了再次启动后仍然可以继续进行采集。但是突然有一天我们发现有两个文件居然是同一个Inode，Linux内核不是保证同一时刻不会重复的吗?难道是内核的bug?注意我用的是“同一时刻”，内核只能保证在同一时刻不会重复，这到底是什么意思呢? 这便是日志采集Agent中会遇到的一个比较大的技术挑战，如何准确的标识一个文件。

如何识别一个文件?

如何知道文件内容更新了?

Inotify可以解决这个问题、通过Inotify监控一个文件，那么只要这个文件有新增数据就会触发事件，得到事件后就可以继续采集了。但是这个方案存在一个问题就是在大量文件写入的场景会导致事件队列溢出，比如用户连续写入日志N次就会产生N个事件，其实对于日志采集Agent只要知道内容就更新就可以了，至于更新几次这个反而不重要， 因为每次采集其实都是持续读文件，直到EOF，只要用户是连续写日志，那么就会一直采集下去。另外Intofy能监控的文件数量也是有上限的。所以这里最简单通用的方案就是轮询去查询要采集文件的stat信息，发现文件内容有更新就采集，采集完成后再触发下一次的轮询，既简单又通用。通过这些手段日志采集Agent终于可以不中断的持续采集日志了，既然是日志总会有被删除的一刻，如果在我们采集的过程中被删除了会如何? 大可放心，Linux中的文件是有引用计数的，已经打开的文件即使被删除也只是引用计数减1，只要有进程引用就可以继续读内容的，所以日志采集Agent可以安心的继续把日志读完，然后释放文件的fd，让系统真正的删除文件。但是如何知道采集完了呢? 废话，上面不是说了采集到文件末尾就是采集完了啊，可是如果此刻还有另外一个进程也打开了这个文件，在你采集完所有内容后又追加了一段内容进去，而你此时已经释放了fd了，在文件系统上这个文件已经不在了，再也没办法通过文件发现找到这个文件，打开并读取数据了，这该怎么办?

如何安全的释放文件句柄?

Fluentd的处理方式就是将这部分的责任推给用户，让用户配置一个时间，文件删除后如果在指定的时间范围内没有数据新增就释放fd，其实这就是间接的甩锅行为了。这个时间配置的太小会造成丢数据的概率增大，这个时间配置的太大会导致fd和磁盘空间一直被占用造成短时间自由浪费的假象。这个问题的本质上其实就是我们不知道还有谁在引用这个文件，如果还有人在引用这个文件就可能会写入数据，此时即使你释放了fd资源仍然是占用的，还不如不释放，如果没有任何人在引用这个文件了，那其实就可以立刻释放fd了。如何知道谁在引用这个文件呢? 想必大家都用过lsof -f列出系统中进程打开的文件列表，这个工具通过扫描每一个进程的/proc/PID/fd/目录下的所有文件描述符，通过readlink就可以查看这个描述符对应的文件路径，例如下面这个例子:

tianqian-zyf@ubuntu:~$ sudo ls -al /proc/22686/fd

total 0

dr-x —— 2 tianqian-zyf tianqian-zyf 0 May 27 12:25 .

dr-xr-xr-x 9 tianqian-zyf tianqian-zyf 0 May 27 12:25 ..

lrwx —— 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 0 -> /dev/pts/19

lrwx —— 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 1 -> /dev/pts/19

lrwx —— 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 2 -> /dev/pts/19

lrwx —— 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 4 -> /home/tianqian-zyf/.post.lua.swp

22686这个进程就打开了一个文件，fd是4，对应的文件路径是 /home/tianqian-zyf/.post.lua.swp 。通过这个方法可以查询到文件的引用计数，如果引用计数是1，也就是只有当前进程引用，那么基本上可以做到安全的释放fd，不会造成数据丢失，但是带来的问题就是开销有点大，需要遍历所有的进程查看它们的打开文件表逐一的比较，复杂度是O(n)，如果能做到O(1)这个问题才算完美解决。通过搜索相关的资料我发现这个在用户态来做几乎是没有办法做到的，Linux内核没有暴露相关的API。只能通过Kernel的方式来解决，比如添加一个API通过fd来获取文件的引用计数。这在内核中还是比较容易做到的，每一个进程都保存了打开的文件，在内核中就是struct file结构，通过这个结构就可以找到这个文件对应的struct inode对象，这个对象内部就维护了引用计数值。期待后续Linux内核能够提供相关的API来完美解决这个问题吧。

总结

到此为此，一个基于文件的采集Agen涉及到的核心技术点都已经介绍完毕了，这其中涉及到很多文件系统、Linux相关的知识，只有掌握好这些知识才能更好的驾驭日志采集。想要编写一个可靠的日志采集Agent确保数据不丢失，这其中的复杂度和挑战不容忽视。希望通过本文能让读者对日志采集有一个较为全面的认知。