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

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


文章目录

  • java日志总结系列3-大型日志收集处理系统
  • 日志系统架构
  • 一些问题
  • 总结


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

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

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

日志系统架构

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

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

常见的架构如下

agent java 采集日志过程 java怎么收集日志_日志采集


日志采集模块:我们的服务时刻产生着日志,有一个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。