作为一个日志采集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掉了，我们该如何保证已经采集的数据不要再采集了，能够继续上次没有采集到的地方继续呢?

将点位数据写入到磁盘的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中会遇到的一个比较大的技术挑战，如何准确的标识一个文件。

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来完美解决这个问题吧。