概述
在今天这个时代，数据已经成为重要的资源，小到管理系统大到智能AI都脱离不了数据的支持。在面对海量数据的压力下，传统项目不能不走上了变迁的道路。生存仍是毁灭，看你本身咯。从传统一个war包走天下，到模块化的SOA，在演变到现今火的不行的微服务。系随着系统变得愈来愈轻量化，扩展性更强，拆分力度更细致，就必然致使了性能测试，异常排除复杂度的升高。mysql
典型问题有：redis
大量报错，特别是重要的服务，排查时间可能会好久sql
异常查看须要到机器上一个个的搜（虽然咱们有elk），处理问题实际时间太长了微信
简单错误的问题定位扯皮，组与组之间协调起来也是麻烦的
不少问题不了了之，由于根本不知道发生了什么鬼，哪里发生的，只能怀疑网络问题网络
虽然也有Zabbix等系统，但那毕竟是监控服务的维度和力度仍是不够的，因此开发一个分布式服务监控系统也就势在必行了，方向就是Google Dapper这篇论文了，因此在10月咱们完成了ULTRON一期。架构
总体设计
监控系统要求就是快速定位问题，及时发现故障，在不影响应用处理能力的状况下尽量的收集数据。
一期目前实现如下功能：app
全量采集：设计为服务调用数据全量采集分布式
实时推送：服务信息接近实时被推送处处理应用模块化
异常报警：实时推送报警信息到微信、邮件、短信等渠道微服务
服务排行榜：可根据排行榜发现有潜在危险的应用
可扩展：支持分布式部署，可任意横向扩展
不保证可靠性：为了保证超强的吞吐量，容许消息丢失
低侵入性：为了保证不影响现有业务，增长其复杂度，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数据已经采样完毕）
数据存储方案的优化
实现针对于用户权限的实现（方便各个业务线只关注自身应用）
流式处理数据方案的升级改造
本文分享自微信公众号 - 架构技术专栏（jiagoujishu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。