概述
在今天这个时代，数据已经成为重要的资源，小到管理系统大到智能AI都脱离不了数据的支持。在面对海量数据的压力下，传统项目不能不走上了变迁的道路。生存还是毁灭，看你自己咯。从传统一个war包走天下，到模块化的SOA，在演变到现今火的不行的微服务。系随着系统变得越来越轻量化，扩展性更强，拆分力度更细致，就必然导致了性能测试，异常排除复杂度的升高。
典型问题有：
- 大量报错，特别是重要的服务，排查时间可能会很久
- 异常查看需要到机器上一个个的搜（虽然我们有elk），处理问题实际时间太长了
- 简单错误的问题定位扯皮，组与组之间协调起来也是麻烦的
很多问题不了了之，因为根本不知道发生了什么鬼，哪里发生的，只能怀疑网络问题
虽然也有Zabbix等系统，但那毕竟是监控服务的维度和力度还是不够的，所以开发一个分布式服务监控系统也就势在必行了，方向就是Google Dapper这篇论文了，所以在10月我们完成了ULTRON一期。
整体设计
监控系统要求就是快速定位问题，及时发现故障，在不影响应用处理能力的情况下尽可能的收集数据。
一期目前实现以下功能：
- 全量采集：设计为服务调用数据全量采集
- 实时推送：服务信息接近实时被推送到处理应用
- 异常报警：实时推送报警信息到微信、邮件、短信等渠道
- 服务排行榜：可根据排行榜发现有潜在危险的应用
- 故障容忍：ULTRON本身出现问题不影响现有业务正常运转，只是监控能力变弱
- 高吞吐：因为需要全方位监控服务，获取完整信息，必须有超强的吞吐量
- 可扩展：支持分布式部署，可任意横向扩展
- 不保证可靠性：为了保证超强的吞吐量，允许消息丢失
- 低侵入性：为了保证不影响现有业务，增加其复杂度，ULTRON采用了低侵入抓取数据
架构图
ULTRON架构图
实时分析
ULTRON借助于DUBOO SPI机制对应用进行低侵入式扩展，内置集成轻量级KAFKA客户端，实现海量数据推送，并且增强自身的故障容忍机制，在应用负载压力高峰时期会主动降低推送数据的频率。
ULTRON服务端对数据进行了流式处理，比如排行榜等信息皆来源于此，未来的报表等处理将接入流处理模块进行。
存储设计
在存储上，一期为了快速迭代采用Mysql HDFS Redis进行辅助数据处理，因为实时查询数据是经过处理的，WatchDog展现的数据对现有Mysql压力非常小。估量依照现有数据量，每日流入数据大概1000W左右，当然对于存储我们已经有了更好的方案，等待二期进行快速迭代。
消息ID设计
系统ID设计理念-Trace树
在分布式追踪系统中，唯一ID的设计是非常重要的，系统基本功能全是依靠于ID进行展现的。借助于Google Dapper 阿里鹰眼系统的借鉴完成了自身ID的穿织。举例：真正ID为e8aaafe039ee42919b6e493fb364e356-0.1.1
页面展示-首页
页面展示-首页.jpg
页面展示-服务监控
页面展示-服务监控 .png
页面展示-服务追踪
页面展示-服务追踪 .png
未来
目前ULTRON系统基本完成对于服务监控的功能，但对于整个监控体系来说只是其核心的一块，还欠缺着周边配套的数据检索动态报表展示等。
下面就罗列下二期准备增加的辅助功能：
- 应用拓扑图完善
- 性能瓶颈的预测
- 根据当前调用比例、QPS等评估容量
- 对于redis 、mysql、mq线程监控数据收集（目前MQ mysql数据已经采样完毕）
- 数据存储方案的优化
- 实现针对于用户权限的实现（方便各个业务线只关注自身应用）
- 流式处理数据方案的升级改造
日常生活
网友评论