共计 7629 个字符，预计需要花费 20 分钟才能阅读完成。
一、业务背景
当今时代处在信息大暴发的时代，信息借助互联网的潮流在寰球自在的流动，产生了各式各样的平台零碎和软件系统，越来越多的业务也会导致系统的复杂性。
当外围业务呈现了问题影响用户体验，开发人员没有及时发现，发现问题时曾经为时已晚，又或者当服务器的 CPU 继续增高，磁盘空间被打满等，须要运维人员及时发现并解决，这就须要一套无效的监控系统对其进行监控和预警。
如何对这些业务和服务器进行监控和保护是咱们开发人员和运维人员不可漠视的重要一环，这篇文章全篇大概 5000 多字，我将对 vivo 服务端监控的原理和架构演进之路做一次系统性整顿，以便大家做监控技术选型时参考。
vivo 服务端监控旨在为服务端利用提供包含系统监控、JVM 监控以及自定义业务指标监控在内的一站式数据监控，并配套实时、多维度、多渠道的告警服务，帮忙用户及时把握利用多方面状态，事先及时预警发现故障，预先提供详实的数据用于追究定位问题，晋升服务可用性。目前 vivo 服务端监控累计接入业务方数量达到 200+，本文介绍的是服务端监控，我司还有其余类型的优良监控包含通用监控、调用链监控和客户端监控等。
1.1 监控零碎的根本流程
无论是开源的监控零碎还是自研的监控零碎，整体流程都大同小异。
1）数据采集：能够包含 JVM 监控数据如 GC 次数，线程数量，老年代和新生代区域大小；系统监控数据如磁盘应用使用率，磁盘读写的吞吐量，网络的进口流量和入口流量，TCP 连接数；业务监控数据如谬误日志，拜访日志，视频播放量，PV，UV 等。
2）数据传输：将采集的数据以音讯模式或者 HTTP 协定的模式等上报给监控零碎。
3）数据存储：有应用 MySQL、Oracle 等 RDBMS 存储的，也有应用时序数据库 OpenTSDB、InfluxDB 存储的，还有应用 HBase 间接存储的。
4）数据可视化：数据指标的图形化展现，能够是折线图，柱状图，饼图等。
5）监控告警：灵便的告警设置，以及反对邮件、短信、IM 等多种告诉通道。
1.2 如何标准的应用监控零碎
在应用监控零碎之前，咱们须要理解监控对象的根本工作原理，例如 JVM 监控，咱们须要分明 JVM 的内存构造组成和常见的垃圾回收机制；其次须要确定如何去形容和定义监控对象的状态，例如监控某个业务性能的接口性能，能够监控该接口的申请量，耗时状况，谬误量等；在确定了如何监控对象的状态之后，须要定义正当的告警阈值和告警类型，当收到告警揭示时，帮忙开发人员及时发现故障；最初建设欠缺的故障解决体系，收到告警时迅速响应，及时处理线上故障。
二、vivo 服务端监控零碎架构及演进之路
在介绍 vivo 服务端监控零碎架构之前，先带大家理解一下 OpenTSDB 时序数据库，在理解之前阐明下为什么咱们会抉择 OpenTSDB，起因有以下几点：
1）监控数据采集指标在某一时间点具备惟一值，没有简单的构造及关系。
2）监控数据的指标具备随着工夫一直变动的特点。
3）基于 HBase 分布式、可伸缩的工夫序列数据库，存储层不须要过多投入精力，具备 HBase 的高吞吐，良好的伸缩性等特点。
4）开源，Java 实现，并且提供基于 HTTP 的应用程序编程接口，问题排查快可批改。
2.1 OpenTSDB 简介
1）基于 HBase 的分布式的，可伸缩的工夫序列数据库，主要用途就是做监控零碎。譬如收集大规模集群（包含网络设备、操作系统、应用程序）的监控数据并进行存储和查问，反对秒级数据采集，反对永恒存储，能够做容量布局，并很容易地接入到现有的监控零碎里，OpenTSDB 的零碎架构图如下：
（来自官网文档）
存储结构单元为 Data Point，即某个 Metric 在某个工夫点的数值。Data Point 包含以下局部：
- Metric，监控指标名称；
- Tags，Metric 的标签，用来标注相似机器名称等信息，包含 TagKey 和 TagValue；
- Value，Metric 对应的理论数值，整数或小数；
- Timestamp，工夫戳。
外围存储两张表：tsdb 和 tsdb-uid。表 tsdb 用来存储监控数据，如下图：
（图片出处：https://www.jianshu.com）
Row Key 为 Metric+Timestamp 的小时整点 +TagKey+TagValue，取相应的字节映射组合起来；列族 t 下的 Qualifier 为 Timestamp 的小时整点余出的秒数，对应的值即为 Value。
表 tsdb-uid 用来存储方才提到的字节映射，如下图：
（图片出处：https://www.jianshu.com）
图中的“001”示意 tagk=hots 或者 tagv=static，提供正反查问。
2）OpenTSDB 应用策略阐明：
- 不应用 OpenTSDB 提供的 rest 接口，通过 client 与 HBase 直连；
- 工程端禁用 compact 动作的 Thrd 线程；
- 距离 10 秒获取 Redis 缓冲数据批量写入 OpenTSDB。
2.2 OpenTSDB 在实践中须要关注的点
1）精确性问题
String value = "0.51";
float f = Float.parseFloat(value);
int raw = Float.floatToRawIntBits(f);
byte[] float_bytes = Bytes.fromInt(raw);
int raw_back = Bytes.getInt(float_bytes, 0);
double decode = Float.intBitsToFloat(raw_back);
/**
* 打印后果：* Parsed Float: 0.51
* Encode Raw: 1057132380
* Encode Bytes: 3F028F5C
* Decode Raw: 1057132380
* Decoded Float: 0.5099999904632568
*/
System.out.println("Parsed Float:" + f);
System.out.println("Encode Raw:" + raw);
System.out.println("Encode Bytes:" + UniqueId.uidToString(float_bytes));
System.out.println("Decode Raw:" + raw_back);
System.out.println("Decoded Float:" + decode);如上代码，OpenTSDB 在存储浮点型数据时，无奈知悉存储用意，在转化时会遇到精确性问题，即存储 ”0.51″，取出为 ”0.5099999904632568″。
2）聚合函数问题
OpenTSDB 的大部分聚合函数，包含 sum、avg、max、min 都是 LERP（linear interpolation）的插值形式，即所获取的值存在被补缺的景象，对于有空值需要的应用很不敌对。具体原理参见 OpenTSDB 对于 interpolation 的文档。
目前 vmonitor 服务端监控应用的 OpenTSDB 是咱们革新后的源码，新增了 nimavg 函数，配合自带的 zimsum 函数满足空值插入需要。
2.3 vivo 服务端监控采集器原理
1）定时器
内含 3 种采集器：OS 采集器、JVM 采集器和业务指标采集器，其中 OS 及 JVM 每分钟执行采集和汇聚，业务指标采集器会实时采集并在 1 分钟的工夫点实现汇聚重置，3 份采集器的数据打包上报至 RabbitMQ，上报动作异步超时。
2）业务指标采集器
业务指标采集形式有 2 种：日志输入过滤和工具类代码上报(侵入式)，日志输入过滤是通过继承 log4j 的 Filter，从而获取指标配置中指定的 Appender 输入的 renderedMessage，并依据指标配置的关键词、聚合形式等信息进行同步监听采集；代码上报依据代码中指定的指标 code 进行 message 信息上报，属于侵入式的采集形式，通过调用监控提供的 Util 实现。业务指标配置每隔 5 分钟会从 CDN 刷新，内置多种聚合器供聚合应用，包含 count 计数、sum 求和、average 均匀、max 最大值和 min 最小值统计。
2.4 vivo 服务端监控老版本架构设计
1）数据采集及上报：需求方利用接入的监控采集器 vmonitor-agent 依据监控指标配置采集相应数据，每分钟上报 1 次数据至 RabbitMQ，所采纳的指标配置每 5 分钟从 CDN 下载更新，CDN 内容由监控后盾上传。
2）计算及存储：监控后盾接管 RabbitMQ 的数据，拆解后存储至 OpenTSDB，供可视化图表调用，监控我的项目、利用、指标和告警等配置存储于 MySQL；通过 Zookeeper 和 Redis 实现分布式工作散发模块，实现多台监控服务协调配合运作，供分布式计算应用。
3）告警检测：从 OpenTSDB 获取监控指标数据，依据告警配置检测异样，并将异样通过第三方依赖自研音讯、短信发送，告警检测通过分布式工作散发模块实现分布式计算。
2.5 vivo 服务端监控老版本部署架构
1）自建机房 A ：部署架构以国内为例，监控工程部署在自建机房 A，监听本机房的 RabbitMQ 音讯，依赖的 Redis、OpenTSDB、MySQL、Zookeeper 等均在同机房，须要上传的监控指标配置由文件服务上传至 CDN，供监控需要利用设施调用。
2）云机房：云机房的监控需要利用设施将监控数据上报至云机房本地的 RabbitMQ，云机房的 RabbitMQ 将指定队列通过路由的形式转发至自建机房 A 的 RabbitMQ，云机房的监控配置通过 CDN 拉取。
2.6 vivo 服务端监控新版本架构设计
1）采集（接入方）：业务方接入 vmonitor-collector，并在相应环境的监控后盾配置相干监控项即实现接入，vmonitor- collector 将定时拉取监控项配置，采集服务数据并每分钟上报。
2）数据聚合：老版本反对的是 RabbitMQ 将采集到的数据，路由至监控机房的 RabbitMQ（同机房则不产生该行为），由监控后盾服务生产；CDN 负责承载各利用的配置供给用定时拉取。新版本 vmonitor-gateway 作为监控数据网关，采纳 http 形式上报监控数据以及拉取指标配置，摈弃了之前应用的 RabbitMQ 上报以及 CDN 同步配置的路径，防止两者故障时对监控上报的影响。
3）可视化并且反对告警与配置（监控后盾 vmonitor）：负责前台的数据多元化展现（包含业务指标数据，分机房汇总数据，单台服务器数据，以及业务指标复合运算出现），数据聚合，告警（目前包含短信及自研音讯）等。
4）数据存储：存储应用 HBASE 集群和开源的 OpenTSDB 作为聚合的中介，原始数据上报之后通过 OpenTSDB 长久化到 HBase 集群，Redis 作为分布式数据存储调度任务分配、告警状态等信息，后盾波及的指标和告警配置存储于 MySQL。
三、监控采集上报和存储监控数据策略
为升高监控接入老本以及防止 RabbitMQ 上报故障和 CDN 同步配置故障对监控体系带来的影响，将由采集层通过 HTTP 间接上报至代理层，并通过采集层和数据代理层的队列实现灾时数据最大水平的解救。
具体流程阐明如下：
1）采集器（vmonitor-collector）依据监控配置每分钟采集数据并压缩，存储于本地队列（最大长度 100，即最大存储 100 分钟数据），告诉可进行 HTTP 上报，将数据上报至网关。
2）网关（vmonitor-gateway）接管到上报的数据后鉴权，认定非法即抛弃；同时判断以后是否上层异样熔断，如果产生则告诉采集层重置数据退回队列。
3）网关校验 上报时带来的监控配置版本号，过期则在后果返回时将最新监控配置一并返回要求采集层更新配置。
4）网关将上报的数据存储于该利用对应的 Redis 队列中（单个利用缓存队列 key 最大长度 1w）；存储队列实现后立刻返回 HTTP 上报，表明网关已承受到数据，采集层可移除该条数据。
5）网关对 Redis 队列数据进行解压以及数据聚合；如果熔断器异样则暂停前一行为；实现后通过 HTTP 存储至 OpenTSDB；如果存储行为大量异样则触发熔断器。
四、外围指标
4.1 系统监控告警和业务监控告警
将采集到的数据通过 OpenTSDB 寄存到 HBase 中后，通过分布式工作散发模块实现分布式计算。如果合乎业务方配置的告警规定，则触发相应的告警，对告警信息进行分组并且路由到正确的告诉方。能够通过短信自研音讯进行告警发送，可通过名字、工号、拼音查问录入须要接管告警的人员，当接管到大量反复告警时可能打消反复的告警信息，所有的告警信息能够通过 MySQL 表进行记录不便后续查问和统计，告警的目标不仅仅是帮忙开发人员及时发现故障建设故障应急机制，同时也能够联合业务特点的监控项和告警梳理服务，借鉴行业最佳监控实际。告警流程图如下：
4.2 反对的告警类型以及计算公式
1）最大值：当指定字段超过该值时触发报警（报警阈值单位：number）。
2）最小值：当指定字段低于该值时触发报警（报警阈值单位：number）。
3）稳定量：取以后工夫到前 15 分钟这段时间内的最大值或者最小值与这 15 分钟内的平均值做浮动百分比报警，稳定量须要配置稳定基线，标识超过该基线数值时才做“报警阀值”断定，低于该基线数值则不触发报警（报警阈值单位：percent）。
计算公式：
稳定量 - 向上稳定计算公式：float rate = (float) (max – avg) / (float) avg;
稳定量 - 向下稳定计算公式：float rate = (float) (avg – min) / (float) avg;
稳定量 - 区间稳定计算公式：float rate = (float) (max – min) / (float) max;
4）日环比：取以后工夫与昨天同一时刻的值做浮动百分比报警（报警阈值单位：percent）。
计算公式：float rate =（以后值 – 上一周期值）/ 上一周期值
5）周环比：取以后工夫与上周同一天的同一时刻的值做浮动百分比报警（报警阈值单位：percent）。
计算公式：float rate =（以后值 – 上一周期值）/ 上一周期值
6）小时日环比：取以后工夫到前一小时内的数据值总和与昨天同一时刻的前一小时内的数据值总和做浮动百分比报警（报警阈值单位：percent）。
计算公式：float rate = (float) (anHourTodaySum – anHourYesterdaySum) / (float) anHourYesterdaySum。
五、演示成果
5.1 业务指标数据查问
1）查问条件栏“指标”可抉择指定指标。
2）双击图表上指标名称可展现大图，底部是依据起始工夫的指标域共计值。
3）滚轮能够缩放图表。
5.2 系统监控 &JVM 监控指标数据查问
1）每分钟页面主动刷新。
2）如果某行，即某台机器整行显示红色，则代表该机器已逾半小时未上报数据，如机器是非正常下线就要留神排查了。
3）点击详情按钮，能够对系统 &JVM 监控数据进行明细查问。
5.3 业务指标配置
单个监控指标 (一般) 能够针对单个指定 Appender 的日志文件进行数据采集。
【必填】【指标类型】为“一般”、“复合”两种，复合是将多个一般指标二次聚合，所以失常状况下须要先新增一般指标。
【必填】【图表程序】正序排列，管制指标图表在数据页面上的展现程序。
【必填】【指标代码】默认主动生成 UUID 短码。
【可选】【Appender】为 log4j 日志文件的 appender 名称，要求该 appender 必须被 logger 的 ref 援用；如果应用侵入式采集数据则无需指定。
【可选】【关键字】为过滤日志文件行的关键词。
【可选】【分隔符】是指单行日志列宰割的符号，个别为 ”,” 英文逗号或其它符号。
六、支流监控比照
6.1 Zabbix
Zabbix 于 1998 年诞生，外围组件采纳 C 语言开发，Web 端采纳 PHP 开发，它属于老牌监控零碎中的优良代表，可能监控网络参数，服务器衰弱和软件完整性，应用也很宽泛。
Zabbix 采纳 MySQL 进行数据存储，所有没有 OpenTSDB 反对 Tag 的个性，因而没法按多维度进行聚合统计和告警配置，应用起来不灵便。Zabbix 没有提供对应的 SDK，应用层监控反对无限，也没有咱们自研的监控提供了侵入式的埋点和采集性能。
总体而言 Zabbix 的成熟度更高，高集成度导致灵活性较差，在监控复杂度减少后，定制难度会升高，而且应用的 MySQL 关系型数据库，对于大规模的监控数据插入和查问是个问题。
6.2 Open-Falcon
OpenFalcon 是一款企业级、高可用、可扩大的开源监控解决方案，提供实时报警、数据监控等性能，采纳 Go 和 Python 语言开发，由小米公司开源。应用 Falcon 能够非常容易的监控整个服务器的状态，比方磁盘空间，端口存活，网络流量等等。基于 Proxy-gateway，很容易通过自主埋点实现应用层的监控（比方监控接口的访问量和耗时）和其余个性化监控需要，集成不便。
官网的架构图如下：
6.3 Prometheus（普罗米修斯）
Prometheus 是由 SoundCloud 开发的开源监控报警零碎和时序列数据库(TSDB)，Prometheus 应用 Go 语言开发，是 Google BorgMon 监控零碎的开源版本。
和小米的 Open-Falcon 一样，借鉴 OpenTSDB，数据模型中引入了 Tag，这样能反对多维度的聚合统计以及告警规定设置，大大提高了应用效率。监控数据间接存储在 Prometheus Server 本地的时序数据库中，单个实例能够解决数百万的 Metrics，架构简略，不依赖内部存储，单个服务器节点可间接工作。
官网的架构图如下：
6.4 vivo 服务端监控 vmonitor
vmonitor 作为监控后盾管理系统，能够进行可视化查看，告警的配置，业务指标的配置等，具备 JVM 监控、系统监控和业务监控的性能。通过采集层（vmonitor-collector 采集器）和数据代理层（vmonitor-gateway 网关）的队列实现灾时数据最大水平的解救。
提供了 SDK 不便业务方集成，反对日志输入过滤和侵入式代码上报数据等应用层监控统计，基于 OpenTSDB 时序开源数据库，对其源码进行了革新，新增了 nimavg 函数，配合自带的 zimsum 函数满足空值插入需要，具备弱小的数据聚合能力，能够提供实时、多维度、多渠道的告警服务。
七、总结
本文次要介绍了 vivo 服务端监控架构的设计与演进之路，是基于 java 技术栈做的一套实时监控零碎，同时也简略列举了行业内支流的几种类型的监控零碎，心愿有助于大家对监控零碎的意识，以及在技术选型时做出更适合的抉择。
监控体系外面波及到的面很广，是一个宏大简单的体系，本文只是介绍了服务端监控里的 JVM 监控，系统监控以及业务监控（蕴含日志监控和工具类代码侵入式上报），未波及到客户端监控和全链路监控等，如果想了解透彻，必须实践联合实际再做深刻。
作者：vivo 互联网服务器团队 -Deng Haibo