java日志总结系列3-大型日志收集处理系统

java日志总结系列1-日志规范
java日志总结系列2-日志框架
java日志总结系列3-大型日志收集处理系统
java日志总结系列4-log4j2配置及常见问题

之前说到日志可以存储到磁盘，但是有如下问题：

1. 微服务架构下，一个服务部署在不同的机器上，排查问题时需要登录不同的机器grep日志，显然不是一个好的做法。
2. 根据日志的内容制作报表，配置告警不易实现
3. …

因此通常大型服务日志都是存储在一个日志系统中，该日志系统包含日志收集功能、日志存储功能、日志查询功能、其他根据日志数据开发的功能，例如告警等。

日志系统架构

日志系统需要解决如下几件事

1. 日志采集
2. 日志存储
3. 日志查询功能
4. 日志数据计算/分析

常见的架构如下

日志采集模块：我们的服务时刻产生着日志，有一个log_agent部署在与服务相同的机器上，采集服务的日志，然后写入到kafka中。log_agent的实现方式不同，可以在业务服务中内嵌，也可以单独部署与服务分开。

日志传输模块：kafka是一个数据流处理平台，也是一个消息系统，将日志写入消息系统几个好处：

1. kafka性能出众、稳定可靠
2. 高峰期用于削峰
3. 不同的数据处理job都可以订阅日志消息

日志处理模块：将原生的日志进行数据处理，比如过滤不必要的数据，数据格式处理，将不同种类的数据切分，数据异构等。将处理好的数据按要求写入存储系统。

日志存储模块：用于日志存储，通常使用ES集群即可。同一份日志数据可以根据要求写到不同的库里。

用户根据需求查询日志数据。比如将erro级别的日志单独存储，查error日志效率就高了许多。还可以根据日志数据做特定的job服务，实现告警功能。

一些问题

log_agent的设计要求

1. 如果失败需要保证不影响业务
2. 对业务无侵入性，做到可插拔。一般把它封装为一个包，直接引入就好。
3. 针对大量的日志可以采取丢弃策略
4. 日志采集端性能问题：需要限制对服务器的性能使用

kafka消息积压

1. 如果日志生产速度过快，但是消费端来不及处理会造成日志查询延迟。需要根据具体情况处理。例如增加kafka partition，增加消息消费端并发度等。

日志存储时间

1. 日志不必存储过长时间，避免磁盘空间浪费。

总结

上述说的是业务日志的收集。
其实还有其它类型数据收集，比如指标的收集大多都是这个套路，具体的实现不同，但是思路大多一致。
如果是小型服务的日志，直接push给日志收集端也可。某些小指标也可以由收集端直接pull。