从零到日志采集索引可视化、监控报警、rpc trace跟踪-架构介绍

github开源  欢迎一起维护~~

接下去的几篇博客将介绍如何从零开发出一套集零侵入的日志采集、日志索引及可视化、基于日志监控报警、基于日志rpc trace跟踪进行系统性能分析的系统，之后都会称为监控中心系统。经测试，该系统的采集以及处理延迟在2秒以内，基本上做到了实时，其中日志采集模块在3台pc机器上测试下来大概每秒能够索引2.5w左右的日志，并且能够随着机器的增加性能水平扩展，每秒能够有效得处理50w+条的日志。

本篇作为第一篇将介绍下基础的架构和使用组件。

1. 组件
   1. log4j和logback
      我们项目中基本是采用的log4j或者logback作为日志框架，log4j版本为1.2.17，logback版本为1.1.6（该版本未采用最新版本是由于logback最新版本和spring boot结合使用有bug，具体参见我以前的博客：http://blog.csdn.net/JThink_/article/details/52513963），我们在log框架中自定义appender将日志传输到下游的kafka，这样可以确保对接方在对接的时候不需要多写任何一行java或者scala代码，仅仅在log的配置文件xml中加入一个appender
   2. kafka
      kafka作为高性能、高吞吐的消息队列来接受log框架send过来的日志，从而不会block对接系统的运行，也不会影响对接系统的性能消耗，kafka的多消费group机制能够很好的满足我们采集、监控、rpc tracer等不同的消费方向
   3. es
      es作为分布式搜索引擎来提供日志的实时索引和可视化工具，kafka中的日志数据将会通过代码消费实时入es进行索引
   4. zk
      zookeeper作为分布式协调系统，我们在这里来追踪对接系统的状态（包括上下线以及日志采集器的存活），以及在rpc trace跟踪的时候作为rpc系统的注册中心
   5. mysql
      存储业务数据
   6. rabbitmq
      监控报警使用邮件和微信的方式，所以不能实时告警，大概每隔几秒进行报警（该问题并不是监控中心不能实时采集到告警数据，而是由于采用的是邮件和微信方式报警，可以换其他稳定的报警方式实时报警）
2. 架构图
   
   架构图是之前画的，可能和之后的介绍中有稍许出入。
   1. App: 我们将java或者scala或者其他的基于jvm运行的程序抽象为App，所有app对接了监控中心将会通过kafka的appender进行send数据到kafka
   2. es-indexer-consume-group: kafka消费入es的消费组，负责读取kafka的数据并批量bulk索引到es
   3. info-collect-consume-group: 埋点采集App特定信息的kafka消费组（如：对接系统需要作为监控系统的过滤条件需要持久化的数据、监控数据、埋点异常数据等）
   4. log-backup-consume-group: 日志备份的kafka消费组，防止日志量过大需要删除es中的数据，我们会将全量的数据同时备份到hdfs中
   5. business-group: 业务层面的消费组
   6. trace-group: rpc trace跟踪的消费组
   7. es: 日志存储db，并建立相关索引
   8. zookeeper: app注册中心
   9. monitor: 监控中心，监听zookeeper注册中心中相应的节点变化进行监控报警
   10. rabbitmq: 监控报警缓冲队列
   11. alert: 具体报警手段，包括邮件和微信
   12. zues: 监控展示系统，包括实时日志滚屏显示、历史日志查询检索、应用系统注册监控查询、应用系统监控状况查询等服务
3. 日志es字段