ULTRON 分布式监控系统

概述

在今天这个时代，数据已经成为重要的资源，小到管理系统大到智能AI都脱离不了数据的支持。在面对海量数据的压力下，传统项目不能不走上了变迁的道路。生存还是毁灭，看你自己咯。从传统一个war包走天下，到模块化的SOA，在演变到现今火的不行的微服务。系随着系统变得越来越轻量化，扩展性更强，拆分力度更细致，就必然导致了性能测试，异常排除复杂度的升高。

典型问题有：
* 大量报错，特别是重要的服务，排查时间可能会很久
* 异常查看需要到机器上一个个的搜（虽然我们有elk），处理问题实际时间太长了
* 简单错误的问题定位扯皮，组与组之间协调起来也是麻烦的
很多问题不了了之，因为根本不知道发生了什么鬼，哪里发生的，只能怀疑网络问题

虽然也有Zabbix等系统，但那毕竟是监控服务的维度和力度还是不够的，所以开发一个分布式服务监控系统也就势在必行了，方向就是Google Dapper这篇论文了，所以在10月我们完成了ULTRON一期。

整体设计

监控系统要求就是快速定位问题，及时发现故障，在不影响应用处理能力的情况下尽可能的收集数据。
一期目前实现以下功能：
* 全量采集：设计为服务调用数据全量采集
* 实时推送：服务信息接近实时被推送到处理应用
* 异常报警：实时推送报警信息到微信、邮件、短信等渠道
* 服务排行榜：可根据排行榜发现有潜在危险的应用
* 故障容忍：ULTRON本身出现问题不影响现有业务正常运转，只是监控能力变弱
* 高吞吐：因为需要全方位监控服务，获取完整信息，必须有超强的吞吐量
* 可扩展：支持分布式部署，可任意横向扩展
* 不保证可靠性：为了保证超强的吞吐量，允许消息丢失
* 低侵入性：为了保证不影响现有业务，增加其复杂度，ULTRON采用了低侵入抓取数据

架构图

##实时分析
ULTRON借助于DUBOO SPI机制对应用进行低侵入式扩展，内置集成轻量级KAFKA客户端，实现海量数据推送，并且增强自身的故障容忍机制，在应用负载压力高峰时期会主动降低推送数据的频率。
ULTRON服务端对数据进行了流式处理，比如排行榜等信息皆来源于此，未来的报表等处理将接入流处理模块进行。

存储设计

在存储上，一期为了快速迭代采用Mysql HDFS Redis进行辅助数据处理，因为实时查询数据是经过处理的，WatchDog展现的数据对现有Mysql压力非常小。估量依照现有数据量，每日流入数据大概1000W左右，当然对于存储我们已经有了更好的方案，等待二期进行快速迭代。

消息ID设计

在分布式追踪系统中，唯一ID的设计是非常重要的，系统基本功能全是依靠于ID进行展现的。借助于Google Dapper 阿里鹰眼系统的借鉴完成了自身ID的穿织。举例：真正ID为e8aaafe039ee42919b6e493fb364e356-0.1.1

页面展示-首页

页面展示-服务监控

页面展示-服务追踪

未来

目前ULTRON系统基本完成对于服务监控的功能，但对于整个监控体系来说只是其核心的一块，还欠缺着周边配套的数据检索动态报表展示等。
下面就罗列下二期准备增加的辅助功能：
* 应用拓扑图完善
* 性能瓶颈的预测
* 根据当前调用比例、QPS等评估容量
* 对于redis 、mysql、mq线程监控数据收集（目前MQ mysql数据已经采样完毕）
* 数据存储方案的优化
* 实现针对于用户权限的实现（方便各个业务线只关注自身应用）
* 流式处理数据方案的升级改造