数据采集之日志：怎么实时采集1万+的日志文件？

 

场景：       

     有一台重要的服务器，每天记录一万+的实时写入日志，日志文件分多级目录存储在一个文件夹下，用户需要能够实时采集一万+的日志，要求日志采集延时小于30秒，采集程序的资源消耗cpu小于5%，内存小于500M。

挑战有两个：

1.如何能够实时采集一万+的增量日志，采集延时小于30秒

2.如果能够控制采集程序的资源消耗符合用户需求

 

实现方案：

1.目前的方案：

         每个日志文件独立起一个线程，实时监控目录下的日志文件的变化，一旦有新的日志写入，马上采集并且发送。   

优点：采集文件数量小于1000的时候实时性好，数据采集的吞吐量大   

缺点：如果监控一万个文件，需要开一万个线程监控和读取数据，具柄资源消耗和系统资源消耗比较大，很容易占满系统资源 ，监控的文件数据大于1000的时候实时性明显变差，大于1分钟  用户需求实时采集1万+的日志，实时性和资源消耗不能满足用户的需求

2.方案改进：   

        通过仔细分析用户的场景和日志，发现用户的单个日志文件写入量比较小，每秒钟50条左右，而且同时写入的日志每秒钟2000个日志   ，那么这种场景下，使用目前的方案比较浪费，对方案做了改进。采用多进程+单线程的模式进行采集。

3.多进程+单线程的模式：   

        什么是多进程+单线程的模式，每个进程只启用一个线程，每个线程顺序检测和采集400个日志文件，然后同时启动5个线程，保证同时实时采集   2000个文件。 

优点：单线程，顺序处理，资源消耗和采集一个日志文件大小相等，内存资源消耗少，单线程，cpu资源消耗少，实时性较好  

缺点：如果日志的数据量比较大的情况下，采集实时性会大幅下降

4.两种方案 

       各有优点和缺点，实用的场景不同，第二种改进方案通过用户场景验证，能够满足用户的需求

结束：   

      用户的日志场景比较多，什么样的场景都有可能会遇到，这就要求我们的日志采集产品能够适应用户场景，这就需要认真收集场景，分类  提炼出通用场景，做成产品通用功能。不断提高产品的易用性！ 同时保证采集程序的资源消耗最小化！