前言

LogStash为开源的数据收集器

LogAgent为我司开发的专用平台日志采集器。

项目背景

所有的系统都会产生日志，日志是为了帮助开发人员排查问题的一个手段，Klink企业集成平台，OpenAPI，超融合集成平台都是大并发系统，企业内部只要有外部接口交互调用，系统接口都会经过以上三个系统，自然我们会产生大量的交易日志，监控日志，平台日志；

交易日志是为了方便排查系统间调用不可抵赖的依据，查询每一笔接口调用的详细过程如下：

1、 请求系统是否发出请求给集成平台，集成平台收到的内容及时间；

2、 集成平台发给接口提供系统的内容及时间；

3、 接口提供系统返回的内容及时间；

4、 集成平台返回给请求系统的内容及时间；

平台日志则记录了系统打印的关键日志信息：

1、 Log4j2的日志内容；

2、 监控日志，统计日志等等；

当系统架构比较简单或者服务器数量比较少， 那么可以登录到服务器上面去查询日志；这种方式如果你拥有的服务器权限或者生产环境允许你这么操作，可以简单的解决；

现在大多系统都用的微服务架构，应用数量和服务器都成倍上升了，集群模式下服务调用链路比较复杂，那么登录服务器看日志就不现实了；

在银行内，运维人员掌握了所有服务器的权限，服务商是没有办法登录后到台服务器上面查看日志的；所以日志采集成为了必要手段，也是方便我们的实施人员排查问题的重要手段。

原方案

平台运行过程中会产生碎片化的日志；

碎片日志通过LogStash采集器采集入库到ElasticSearch存储；

后续根据原始日志可以计算维度日志或者监控需要的数据；

为什么弃用LogStash

上图是一个典型的ElasticSearch+LogStash的日志采集+日志存储方案，但是为什么要启用LogStash呢？

LogStash问题如下：

1、 Filters的match耗时长，在大报文采集的时候相当慢，消息如果超过1M以上基本在1秒，消息在10M时间更长；消息越大耗时越大，主要是日志格式匹配耗时；

2、 LogStash大报文容易内存溢出；

3、 缺少监控，无法知道logstash采集的文件数量，大小，logstash健康状态等；

4、 交易日志、监控日志和平台日志分开采集，减少监控日志和交易日志的延时，延时控制在分钟级别，保证能够及时告警通知运维处理；

5、 定制扩展开发成本和维护成本都太高；

6、 日志采集后不会删除；

LogAgent设计

LogAgent的主要作用就是日志收集，日志收集主要从文件里面读取，大致步骤如下：

1、 从指定的文件目录读取文件；

2、 根据文件类型进行格式匹配；

3、 将日志入库到指定的ES索引；

要求：

1、 能够支持采集多个文件目录，文件目录之间的采集是独立互相不干扰的；

2、 能够监控采集器的状态，包括CPU，内存使用情况，采集文件的数量，采集文件大小，监控状态等；

3、 可以扩展输入源和输出源，扩展日志格式读取等；

4、 解决大报文读取内存溢出等问题；

功能对比

性能对比

在相同的条件下，我们的LogAgent超过了LogStash，上位成功！