1。业务背景当今时代是信息爆炸的时代。信息借助互联网的潮流在世界范围内自由流动，产生了各种平台系统和软件系统。越来越多的业务也会导致系统的复杂性。当核心业务出现影响用户体验的问题，而开发者未能及时发现，发现问题时为时已晚，或者当服务器的CPU不断增加，磁盘空间不足时full等，需要运维人员及时发现并处理。这就需要一个有效的监控系统对其进行监控和预警。如何对这些业务和服务器进行监控和维护，是我们开发人员和运维人员不能忽视的重要一环。这篇文章的长度约为5,000字。一个系统的整理，让大家在选择监控技术时可以参考。vivo服务器监控旨在为服务器应用提供包括系统监控、JVM监控、自定义业务指标监控在内的一站式数据监控，并配备实时、多维度、多渠道的告警服务，帮助用户掌握应用及时多方位状态，及时预警，事前发现故障，事后提供详细数据，追溯定位问题，提高服务可用性。目前，vivo服务器监控累计接入业务方已达200+。本文介绍服务器监控。我司还有其他类型的优秀监控，包括通用监控、调用链监控、客户端监控。一、监控系统的基本流程无论是开源的监控系统还是自研的监控系统，整体流程都是差不多的。1）数据收集：可以包括JVM监控数据，如GC次数、线程数、老年代和新生代区域大小；磁盘使用率、磁盘读写吞吐量、网络出口流量和入口流量、TCP连接数等系统监控数据；业务监控数据，如错误日志、访问日志、视频播放量、PV、UV等。2）数据传输：将采集到的数据以消息或HTTP协议的形式上报给监控系统。3）数据存储：有的使用MySQL、Oracle等RDBMS进行存储，有的使用时序数据库OpenTSDB、InfluxDB进行存储，有的使用HBase直接存储。4)数据可视化：数据指标的图形化展示，可以是折线图、直方图、饼图等。5)监控告警：告警设置灵活，支持邮件、短信、IM等多种通知渠道。2.如何规范的使用监控系统在使用监控系统之前，我们需要了解监控对象的基本工作原理，比如JVM监控，我们需要知道JVM的内存结构和常见的垃圾收集机制；其次，我们需要确定如何描述和定义监控对象的状态，比如监控某个业务功能的接口性能，可以监控接口的请求量、耗时情况、错误量等;确定了如何监控对象的状态后，需要定义合理的告警阈值和告警类型，在收到告警提醒时，帮助开发者及时发现故障；最终建立完善的故障处理体系，接到告警快速响应，及时处理线上故障。2、vivo服务器监控系统架构及演进之路在介绍vivo服务器监控系统架构之前，先带大家了解一下OpenTSDB时序数据库。在理解之前先解释一下为什么我们选择OpenTSDB。原因如下：1）监测数据采集指标在某一时点具有独特的价值，不存在复杂的结构和关系。2）监测数据指标具有随时间变化的特点。3）基于HBase分布式可扩展的时序数据库，存储层不需要过多的努力，具有HBase的高吞吐量和良好扩展性的特点。4)开源，Java实现，提供基于HTTP的应用程序编程接口，方便修改，方便故障排除。一、OpenTSDB简介1）基于HBase的分布式可扩展时序数据库，主要用作监控系统。例如，采集大型集群（包括网络设备、操作系统、应用程序）的监控数据并进行存储和查询，支持秒级数据采集，支持永久存储，允许进行容量规划，轻松连接现有的In监控系统，OpenTSDB的系统架构图如下：（来自官方文档）存储结构单元为DataPoint，即某个时间点某个Metric的值。DataPoint包括以下几个部分：Metric，监控指标的名称；Tags，Metric的标签，用于标注机器名称等信息，包括TagKey和TagValue；Value，Metric对应的实际值，整数或小数；时间戳，时间戳。核心存储两张表：tsdb和tsdb-uid。tsdb表用于存储监控数据，如下图所示：（图片来源：https://www.jianshu.com）RowKey为Metric+Timestamphourhour+TagKey+TagValue，取对应字节映射并结合；columnfamilyt下的Qualifier是Timestamp所在小时剩余的秒数，对应的值为Value。tsdb-uid表用于存储刚才提到的字节映射，如下图所示：（图片来源：https://www.jianshu.com）图中“001”表示tagk=hots或tagv=static，提供正反Inquire。2）OpenTSDB使用策略说明：不使用OpenTSDB提供的rest接口，直接通过客户端连接HBase；在工程方面禁用紧凑操作的Thrd线程；每隔10秒获取Redis缓冲数据，批量写入OpenTSDB。2、OpenTSDB在实践中需要注意的点1）精度问题Stringvalue="0.51";floatf=Float.parseFloat(value);intraw=Float.floatToRawIntBits(f);byte[]float_bytes=Bytes。fromInt(raw);intraw_back=Bytes.getInt(float_bytes,0);doubledecode=Float.intBitsToFloat(raw_back);/***打印结果：*ParsedFloat:0.51*EncodeRaw:1057132380*EncodeBytes:3F028F5C*原始解码：1057132380*解码浮点数：0.5099999904632568*/System.out.println("解析浮点数："+f);System.out.println("原始编码："+raw);System.out.println("编码字节:"+UniqueId.uidToString(float_bytes));System.out.println("原始解码："+raw_back);System.out.println("解码浮点数："+decode);如上代码，OpenTSDB存储的是浮点型数据，存储意图不可知，转换时会遇到精度问题，即存储“0.51”，取为“0.5099999904632568”。2）聚合函数问题OpenTSDB的聚合函数，包括sum、avg、max、min，大部分都是LERP（linearinterpolation）插值方法，即把得到的值填进去，很难做到如果有空值，则使用它们。不友好。详细原理参见OpenTSDB关于插值的文档。目前vmonitor服务器用于监控的OpenTSDB是我们修改后的源码。添加了nimavg函数以满足内置zimsum函数的空值插入要求。3、vivo服务器监控采集器原理1）定时器包含3种采集器：OS采集器、JVM采集器和业务指标采集器，其中OS和JVM每分钟进行一次采集聚合，业务指标采集器会实时收集并在1分钟内完成聚合重置。三个采集器的数据打包上报给RabbitMQ，上报动作异步超时。2）业务指标收集器业务指标的收集有两种方式：日志输出过滤和工具代码上报（侵入式）。日志输出过滤是通过继承log4j的filter获取指标配置中指定的Appender输出的renderedMessage，并根据指标配置的关键字和聚合方式进行同步监控和收集；代码上报根据代码中指定的指标代码上报消息信息，属于侵入式采集方式，通过调用监控提供的Util实现。业务指标配置每5分钟从CDN刷新一次，使用内置多种聚合器进行聚合，包括count计数、sum求和、average、max最大值和min最小值统计。四、老版本vivo服务器监控架构设计1）数据采集与上报。需求方应用连接的监控采集器vmonitor-agent根据监控指标配置采集相应数据，每分钟上报一次RabbitMQ。索引配置采用每5分钟从CDN下载更新，CDN内容由监控后台上传。2）计算和存储监控后台接收RabbitMQ数据，拆解后存储到OpenTSDB中，可视化图表调用，监控项、应用、指标、告警等配置存储到MySQL中；分布式任务分发模块通过Zookeeper和Redis实现，多个监控服务协调配合用于分布式计算。3）告警检测从OpenTSDB获取监控指标数据，根据告警配置检测异常，并通过第三方自研消息和短信发送异常，告警检测通过分布式任务分发模块完成分布式计算。五、vivo服务器监控老版本部署架构1）自建机房A部署架构以中国为例，监控项目部署在自建机房A，监控机房RabbitMQ消息，并依托Redis、OpenTSDB、MySQL、Zookeeper等。在同一机房，将需要上传的监控指标配置通过文件服务上传到CDN，由应用设备调用，满足监控需求。2）云机房的监控需求。应用设备将监控数据上报给云机房本地的RabbitMQ。云机房的RabbitMQ通过路由将指定队列转发给自建机房A的RabbitMQ。云机房的监控配置通过CDN拉取。挑选。六、新版vivo服务器监控架构设计1）采集（接入方）业务方接入vmonitor-collector，在相应环境的监控后台配置相关监控项完成接入，vmonitor-collector会定时拉取监控项配置，每分钟采集服务数据并上报。2）老版本的数据聚合支持RabbitMQ采集的数据路由到监控机房的RabbitMQ（同机房不会出现这种行为），由监控后台服务消费；CDN负责承载每个应用的配置，供应用定时拉取。新版vmonitor-gateway作为监控数据网关，使用http上报监控数据和拉取指标配置，摒弃了之前使用的RabbitMQ上报和CDN同步配置方式，避免了两者都失效时对监控上报的影响。3）告警和配置的可视化和支持（监控后台vmonitor）负责前端数据的多样化展示（包括业务指标数据、分机房汇总数据、单台服务器数据、业务指标复合计算），数据聚合、告警（目前包括短信和自研消息）等。4）数据存储采用HBASE集群和开源OpenTSDB作为聚合中介。原始数据上报后，通过OpenTSDB持久化到HBase集群。Redis作为分布式数据存储，用于调度任务分配、告警状态等信息，后台Configuration涉及的指标告警存储在MySQL中。3、监控采集、上报和存储监控数据策略为了降低监控访问成本，避免RabbitMQ上报失败和CDN同步配置失败对监控系统的影响，采集层会通过HTTP直接上报给代理层，以及通过采集层和数据代理层的队列实现灾难时数据的最大抢救。详细过程描述如下：1）收集器（vmonitor-collector）根据监控配置，每分钟收集并压缩数据，并存储在本地队列中（最大长度为100，即最长存储时间）为100分钟的数据），通知可以通过HTTP方式将数据上报给网关。2）网关（vmonitor-gateway）收到上报数据后进行鉴权，发现不合法则丢弃；同时判断下层是否异常炸毁，如果发生则通知采集层重置数据返回队列。3)网关验证上报时带入的监控配置的版本号。如果过期，返回结果时会返回最新的监控配置，并要求采集层更新配置。4）网关将上报数据存储在应用对应的Redis队列中（单个应用缓存队列key最大长度为1w）；存储队列完成后，立即返回HTTP报告，表示网关已经收到数据，采集层可以移除入口数据。5）网关对Redis队列数据进行解压聚合；如果熔断器异常，则暂停之前的行为；完成后通过HTTP存储到OpenTSDB；如果大量存储行为异常，则触发熔断。四、核心指标1、系统监控告警和业务监控告警采集到的数据通过OpenTSDB存储到HBase中后，通过分布式任务分发模块完成分布式计算。如果满足业务方配置的告警规则，则触发相应的告警，告警信息将被分组路由到正确的通知方。可通过短信自研短信发送告警，需要接收告警的人员可通过姓名、工号、拼音查询录入。当收到大量重复告警时，可以剔除重复告警信息，通过MySQL表记录所有告警信息，方便后续查询和统计，告警的目的不仅仅是帮助开发人员及时发现故障建立故障应急机制，还要将监控项目和告警排序服务结合业务特点，借鉴行业最佳监控实践。告警流程图如下：2.支持的告警类型及计算公式1)最大值：当指定字段超过该值时，触发告警（告警阈值单位：个数）。2）最小值：当指定字段低于该值时，触发告警（告警阈值单位：个数）。3)波动量：取当前时间到前15分钟的最大值或最小值以及15分钟内的平均值进行浮动百分比报警。波动量需要配置波动基线，只有当标记超过基线值时才会判断“告警阈值”，低于基线值则不会触发告警（告警阈值单位：百分比).计算公式：波动量-向上波动计算公式：浮动率=（float）（max-avg）/（float）avg；波动量-向下波动计算公式：浮动率=(float)(avg-min)/(float)avg；波动量-区间波动计算公式：浮动率=（浮动）（最大-最小）/（浮动）最大；4）日比：取当前时间和昨天同一时刻的值作为浮动百分比报警（报警阈值单位：百分比）。计算公式：浮动率=（当前值-上期值）/上期值5）周周比：取当前时间与上周同一天同一时间的值作为浮动百分比报警（告警阈值单位：百分比）。计算公式：浮动率=（当前值-上一期值）/上一期值6）小时日比：取当前时间到上一小时的数据值之和昨天同一时刻前一小时的数据值之和作为浮动百分比告警（告警阈值单位：百分比）。计算公式：浮点率=(float)(anHourTodaySum-anHourYesterdaySum)/(float)anHourYesterdaySum。五、演示效果1、业务指标数据查询1）在查询条件栏“指标”中，可以选择指定一个指标。2)双击图表上的指标名称显示大图，下方是指标字段按照开始时间的总值。3)滚轮可以缩放图表。2、系统监控&JVM监控指标数据查询1）页面每分钟自动刷新一次。2）如果某行，即某台机器整行显示为红色，表示该机器超过半小时没有上报数据。如果机器异常掉线，一定要仔细检查。3)点击Details按钮可以详细查询系统&JVM监控数据。3.业务指标配置单个监控指标（普通）可以从单个指定Appender的日志文件中采集数据。【必填】【指标类型】为“普通”、“复合”。组合是多个公共指标的二次聚合，所以一般情况下需要先添加公共指标。【必填】【图表顺序】正序排列，控制指标图表在数据页的显示顺序。[必填][指标代码]默认自动生成UUID短代码。[可选][Appender]为log4j日志文件的appender名称，appender必须被logger的ref引用；如果使用侵入式数据收集，则不需要指定。[可选][关键字]是过滤日志文件行的关键字。[可选][分隔符]是指分隔单行日志列的符号，通常是“,”英文逗号或其他符号。六、主流监控对比1、ZabbixZabbix诞生于1998年，核心组件采用C语言开发，Web端采用PHP开发。非常广泛。Zabbix使用MySQL进行数据存储，OpenTSDB不支持Tag特性，无法基于多维度进行聚合统计和告警配置，使用不灵活。Zabbix没有提供相应的SDK，应用层监控支持有限，我们自研的监控提供了侵入式的埋点和采集功能。总的来说，Zabbix成熟度较高，集成度高导致灵活性较差。监控复杂度增加后，定制化难度会增加，所使用的MySQL关系型数据库是大规模监控数据插入查询的重要工具。问题。2.Open-FalconOpenFalcon是一个企业级、高可用、可扩展的开源监控解决方案，提供实时告警、数据监控等功能。它使用Go和Python开发，由小米开源。使用Falcon可以非常方便地监控整个服务器的状态，比如磁盘空间、端口存活、网络流量等等。基于Proxy-gateway，通过自埋点轻松实现应用层监控（如监控接口访问、耗时）等个性化监控需求，集成方便。官方架构图如下：3.PrometheusPrometheus是SoundCloud开发的开源监控报警系统和时序数据库（TSDB）。Prometheus使用Go语言开发，是GoogleBorgMon监控系统的开源版本。像小米的Open-Falcon，它借鉴了OpenTSDB，在数据模型中引入了Tags，可以支持多维聚合统计和告警规则设置，大大提高了使用效率。监控数据直接存储在PrometheusServer的本地时序数据库中。单个实例可以处理数百万个指标。架构简单，不依赖外部存储。单个服务器节点可以直接工作。官方架构图如下：4、vivo服务器监控vmonitor作为监控后台管理系统，vmonitor可以进行可视化查看、告警配置、业务指标配置等，具有JVM监控、系统监控、业务监控等功能.通过采集层（vmonitor-collectorcollector）和数据代理层的队列（vmonitor-gatewaygateway），实现灾难时数据的最大抢救。提供SDK方便业务方集成，支持日志输出过滤、侵入式代码上报数据等应用层监控统计。基于OpenTSDB时序开源数据库，修改源码，增加nimavg函数，满足内置zimsum函数的要求。空值插入需求，具备强大的数据聚合能力，可提供实时、多维度、多渠道的告警服务。7.小结本文主要介绍vivo服务器监控架构的设计与演进。是一个基于java技术栈的实时监控系统。同时，也简要列举了目前业界主流的几类监控系统。希望能有更多的帮助大家了解监控系统，在选择技术的时候做出更合适的选择。监控系统涉及面广，是一个庞大而复杂的系统。本文只介绍服务端监控中的JVM监控、系统监控、业务监控（包括日志监控和工具代码的侵入式上报）。不涉及Client监控和全链路监控等，要想理解透彻，必须理论结合实际再深入。
