主流监控零碎技术选型，yyds

密码不对

以前，我写过几篇无关「线上问题排查」的文章，文中附带了一些监控图，有些读者对此很感兴致，问我监控零碎选型上有无好的倡议？
目前我所阅历的几家公司，监控零碎都是自研的。其实业界有得多优秀的开源产品可供选择，能知足绝大部份的监控需要，假如能从中选择一款知足企业当下的诉求，显然最省时省力。
这篇文章，我将对监控体系的根底常识、原理和架构做一次零碎性整顿，同时还会对几款最罕用的开源监控产品做下引见，以便大家选型时参考。内容包罗3部份：
必知必会的监控根底常识主流监控零碎引见监控零碎的选型倡议01 必知必会的监控根底常识监控零碎俗称「第三只眼」，简直是咱们天天都会打交道的零碎，上面 4 项根底常识我以为是必需要理解的。
1. 监控零碎的7大作用
正所谓「无监控，不运维」，监控零碎的位置显而易见。不论你是监控零碎的开发者仍是使用者，首先确定要分明：监控零碎的指标是甚么？它能发扬甚么作用？



实时收集监控数据：包罗硬件、操作零碎、两头件、运用顺序等各个维度的数据。实时反馈监控形态：经过对收集的数据进行多维度统计和可视化展现，能实时体现监控对象的形态是正常仍是异样。预知毛病和告警：可以提前预知毛病危险，并及时收回告警信息。辅佐定位毛病：提供毛病产生时的各项目标数据，辅佐毛病剖析和定位。辅佐机能调优：为机能调优提供数据反对，好比慢SQL，接口响应时间等。辅佐容量布局：为办事器、两头件以及运用集群的容量布局提供数据撑持。辅佐自动化运维：为自动扩容或者按照配置的SLA进行办事升级等智能运维提供数据撑持。2. 使用监控零碎的正确姿态出任何线上变乱，先不说其余中央有问题，监控部份一定是有问题的。听着很甩锅的一句话，子细思考好像有一定情理。咱们在变乱复盘时，通常会思考这3个和监控无关的问题：有无做监控？监控是不是及时？监控信息是不是有助于疾速定位问题？
可见光有一套好的监控零碎还不敷，还必需知道**「如何用好它」**。一个成熟的研发团队通常会定一个监控标准，用来一致监控零碎的使用办法。



理解监控对象的任务原理：要做到对监控对象有根本的理解，分明它的任务原理。好比想对JVM进行监控，你必需分明JVM的堆内存构造和渣滓回收机制。肯定监控对象的目标：分明使用哪些目标来描写监控对象的形态？好比想对某个接口进行监控，能够采取申请量、耗时、超时量、异样量等目标来权衡。定义公道的报警阈值和等级：达到甚么阈值需求告警？对应的毛病等级是多少？不需求处置的告警不是好告警，可见定义公道的阈值有多首要，不然只会升高运维效力或者让监控零碎失去它的作用。建设完美的毛病处置流程：收到毛病告警后，一定要有相应的处置流程和oncall机制，让毛病及时被跟进处置。3. 监控的对象和目标都有哪些？监控未然成了全部产品生命周期十分首要的一环，运维关注硬件和根底监控，研发关注各类两头件和运用层的监控，产品关注中心业务目标的监控。可见，监控的对象曾经愈来愈平面化。
这里，我对罕用的监控对象以及监控目标做了分类整顿，供大家参考。



3.1 硬件监控
包罗：电源形态、CPU形态、机器温度、风扇形态、物理磁盘、raid形态、内存形态、网卡形态
3.2 办事器根底监控
CPU：单个CPU以及总体的使用状况内存：已用内存、可用内存磁盘：磁盘使用率、磁盘读写的吞吐量网络：出口流量、入口流量、TCP衔接形态3.3 数据库监控包罗：数据库衔接数、QPS、TPS、并行处置的会话数、缓存命中率、主从延时、锁形态、慢查问
3.4 两头件监控
Nginx：活泼衔接数、等候衔接数、抛弃衔接数、申请量、耗时、5XX过错率Tomcat：最大线程数、以后线程数、申请量、耗时、过错量、堆内存使用状况、GC次数和耗时缓存 ：胜利衔接数、梗阻衔接数、已使用内存、内存碎片率、申请量、耗时、缓存命中率动静队列：衔接数、队列数、出产速率、消费速率、动静沉积量3.5 运用监控HTTP接口：URL存活、申请量、耗时、异样量RPC接口：申请量、耗时、超时量、回绝量JVM ：GC次数、GC耗时、各个内存区域的大小、以后线程数、死锁线程数线程池：活泼线程数、工作队列大小、工作履行耗时、回绝工作数衔接池：总衔接数、活泼衔接很多天志监控：拜候日志、过错日志业务目标：视业务来定，好比PV、定单量等4. 监控零碎的根本流程无论是开源的监控零碎仍是自研的监控零碎，监控的全部流程迥然不同，个别都包罗下列模块：



数据收集：收集的形式有得多种，包罗日志埋点进行收集（经过Logstash、Filebeat等进行上报和解析），JMX规范接口输入监控目标，被监控对象提供REST API进行数据收集（如Hadoop、ES），零碎命令行，一致的SDK进行侵入式的埋点和上报等。数据传输：将收集的数据以TCP、UDP或者HTTP协定的方式上报给监控零碎，有被动Push模式，也有主动Pull模式。数据存储：有使用MySQL、Oracle等RDBMS存储的，也有使历时序数据库RRDTool、OpentTSDB、InfluxDB存储的，还有使用HBase存储的。数据展现：数据目标的图形化展现。监控诉警：灵敏的告警设置，以及反对邮件、短信、IM等多种通知通道。02 主流监控零碎引见上面再来意识下主流的开源监控零碎，因为篇幅无限，我挑拣了3款使用最普遍的监控零碎：Zabbix、Open-Falcon、Prometheus，会对它们的架构进行引见，同时总结下各自的优优势。



1. Zabbix（老牌监控的优秀代表）



Zabbix 1998年降生，中心组件采取C言语开发，Web端采取PHP开发。它属于老牌监控零碎中的优秀代表，监控功用很片面，使用也很普遍，差未几有70%摆布的互联网公司都曾使用过 Zabbix 作为监控解决计划。
先来理解下Zabbix的架构设计：



Zabbix架构图
Zabbix Server：中心组件，C言语编写，担任接纳Agent、Proxy发送的监控数据，也反对JMX、SNMP等多种协定间接收集数据。同时，它还担任数据的汇总存储以及告警触发等。Zabbix Proxy：**可选组件，关于被监控机器较多的状况下，可以使用Proxy进行散布式监控，它能代理Server采集部份监控数据，以加重Server的压力。Zabbix Agentd：**部署在被监控主机上，用于收集本机的数据并发送给Proxy或者Server，它的插件机制反对用户自定义数据收集脚本。Agent可在Server端手动配置，也能够经过自动发现机制被辨认。数据采集形式同时反对被动Push和主动Pull 两种模式。Database：用于存储配相信息以及收集到的数据，反对MySQL、Oracle等瓜葛型数据库。同时，最新版本的Zabbix曾经开始反对时序数据库，不外成熟度还不高。Web Server：Zabbix的GUI组件，PHP编写，提供监控数据的展示和告警配置。上面是 Zabbix 的劣势：
产品成熟：因为降生时间长且使用普遍，具有丰硕的文档材料以及各种开源的数据收集插件，能掩盖绝大部份监控场景。收集形式丰硕：反对Agent、SNMP、JMX、SSH等多种收集形式，以及被动和主动的数据传输形式。较强的扩展性：反对Proxy散布式监控，有agent自动发现功用，插件式架构反对用户自定义数据收集脚本。配置办理便利：能经过Web界面进行监控和告警配置，操作便利，上手简略。上面是 Zabbix 的优势：
机能瓶颈：机器量或者业务量大了后，瓜葛型数据库的写入一定是瓶颈，民间给出的单机下限是5000台，集体觉得达不到，尤为当初运用层的目标愈来愈多。虽然最新版曾经开始反对时序数据库，不外成熟度还不高。运用层监控反对无限：假如想对运用顺序做侵入式的埋点和收集（好比监控线程池或者接口机能），zabbix没有提供对应的sdk，经过插件式的脚本也能曲线完成此功用，集体觉得zabbix就不是做这个事的。数据模型不弱小：不反对tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵敏。便利二次开发难度大：Zabbix采取的是C言语，二次开发往往需求相熟它的数据表构造，基于它提供的API更多只能做展现层的定制。2. Open-Falcon（小米出品，国际盛行）


Open-falcon 是小米2015年开源的企业级监控工具，采取Go和Python言语开发，这是一款灵敏、高机能且易扩展的新一代监控计划，目前小米、美团、滴滴等超过200家公司在使用它。
小米早期也使用的Zabbix进行监控，然而机器量和业务量下去后，Zabbix就有些力所能及了。因此，起初自主研发了Open-Falcon，在架构设计上汲取了Zabbix的教训，同时很好地解决了Zabbix的诸多痛点。
先来理解下Open-Falcon的架构设计：



Open-Falcon架构图，来自网络
Falcon-agent：数据收集器和采集器，Go开发，部署在被监控的机器上，反对3种数据收集形式。首先它能自动收集单机200多个根底监控目标，无需做任何配置；同时反对用户自定义的plugin获得监控数据；另外，用户可经过http接口，自主push数据到本机的proxy-gateway，由gateway转发到server.Transfer：数据散发组件，接纳客户端发送的数据，分别发送给数据存储组件Graph和告警断定组件Judge，Graph和Judge均采取统一性hash做数据分片，以进步横向扩展才能。同时Transfer还反对将数据散发到OpenTSDB，用于历史归档。Graph：数据存储组件，底层使用RRDTool（时序数据库）做单个目标的存储，并经过缓存、分批写入磁盘等形式进行了优化。听说一个graph实例可以处置8W+每秒的写入速率。Judge和Alarm：告警组件，Judge对Transfer组件上报的数据进行实时计算，判别是不是要发生告警事情，Alarm组件对告警事情进行收敛处置后，将告警动静推送给各个动静通道。API：面向终端用户，收到查问申请后会去Graph中查问目标数据，汇总后果后一致前往给用户，屏蔽了存储集群的分片细节。上面是Open-Falcon的劣势：
自动收集才能：Falcon-agent 能自动收集办事器的200多个根底目标（好比CPU、内存等），无需在server上做任何配置，这一点能够秒杀Zabbix.弱小的存储才能：底层采取RRDTool，而且经过统一性hash进行数据分片，构建了一个散布式的时序数据存储零碎，可扩展性强。灵敏的数据模型：鉴戒OpenTSDB，数据模型中引入了tag，这样能反对多维度的聚合统计以及告警规定设置，大大进步了使用效力。插件一致办理：Open-Falcon的插件机制完成了对用户自定义脚本的一致化办理，可经过HeartBeat Server散发给agent，加重了使用者自主保护脚本的本钱。共性化监控反对：基于Proxy-gateway，很容易经过自主埋点完成运用层的监控（好比监控接口的拜候量和耗时）和其余共性化监控需要，集成便利。上面是Open-Falcon的优势：
总体开展个别：社区活泼度不算高，同时版本更新慢，有些大厂是基于它的不乱版本间接做二次开发的，对于当前的前景其实有点耽忧。UI不敷敌对：关于业务线的研发来讲，可能只想便捷地实现告警配置和业务监控，然而它把机器分组、战略模板、模板承继等概念整个袒露在UI上，觉得在环抱这几个概念设计UI，了解有点费力。装置对比繁杂：集体的亲自感触，因为它是从小米外部衍生出来的，虽然去掉了对小米外部零碎的依赖，然而组件仍是对比多，假如对全部架构不相熟，装置很难欲速不达。3. Prometheus（号称下一代监控零碎）


Prometheus（普罗米修斯）是由前Google员工2015年正式公布的开源监控零碎，采取Go言语开发。它不只有一个很酷的名字，同时它有Google与k8s的强力反对，开源社区异样火爆。
Prometheus 2016年参加云原生基金会，是继k8s后托管的第二个名目，将来前景被至关看好。它和Open-Falcon最大不同在于：数据收集是基于Pull模式的，而不是Push模式，而且架构十分简略。
先来理解下Prometheus的架构设计：



Prometheus架构图，来自网络
Prometheus Server：中心组件，用于采集、存储监控数据。它同时反对动态配置和经过Service Discovery静态发现来办理监控指标，并从监控指标中获得数据。另外，Prometheus Server 也是一个时序数据库，它将监控数据保留在当地磁盘中，并对外提供自定义的 PromQL 言语完成对数据的查问和剖析。Exporter：用来收集数据，作用相似于agent，区分在于Prometheus是基于Pull形式拉取收集数据的，因此，Exporter经过HTTP办事的方式将监控数据根据规范格局袒露给Prometheus Server，社区中曾经有少量现成的Exporter能够间接使用，用户也能够使用各种言语的client library自定义完成。Push gateway：次要用于刹时工作的场景，避免Prometheus Server来pull数据以前此类Short-lived jobs就曾经履行终了了，因此job能够采取push的形式将监控数据被动报告请示给Push gateway缓存起来进行直达。Alert Manager：当告警发生时，Prometheus Server将告警信息推送给Alert Manager，由它发送告警信息给接纳方。Web UI：Prometheus内置了一个简略的web管制台，能够查问配相信息和目标等，而实际运用中咱们通常会将Prometheus作为Grafana的数据源，创立仪表盘以及查看目标。上面是Prometheus的劣势：
轻量办理：架构简略，不依赖内部存储，单个办事器节点可间接任务，二进制文件启动便可，属于轻量级的Server，便于迁徙和保护。较强的处置才能：监控数据间接存储在Prometheus Server当地的时序数据库中，单个实例能够处置数百万的metrics。灵敏的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更便利。弱小的查问语句：PromQL允许在同一个查问语句中，对多个metrics进行加法、衔接和取分位值等操作。很好地反对云环境：能自动发现容器，同时k8s和etcd等名目都提供了对Prometheus的原生反对，是目前容器监控最盛行的计划。上面是Prometheus的优势：
功用不敷完美：Prometheus从一开始的架构设计就是要做到简略，不提供集群化计划，长时间的耐久化存储和用户办理，而这些是企业变大后所必需的特性，目前要做到这些只能在Prometheus之上进行扩展。网络布局变繁杂：因为Prometheus采取的是Pull模型拉取数据，象征着一切被监控的endpoint必需是可达的，需求公道布局网络的平安配置。03 监控零碎的选型倡议经过下面的引见，大家对主流的监控零碎应该有了一定的意识。面对选型问题，我的倡议是：
1、先明白分明你的监控需要：要监控的对象有哪些？机器数量和监控目标有多少？需求具备甚么样的告警功用？
2、监控是一项长时间建立的事件，一开始就想做一个 All In One 的监控解决计划，我感觉没有须要。从本钱角度斟酌，在早期间接使用开源的监控计划便可，先解决有没有问题。
3、从零碎成熟度上看，Zabbix属于老牌的监控零碎，材料多，功用片面且不乱，假如机器数量在几百台之内，不必太耽心机能问题，此外，采取数据库分区、SSD硬盘、Proxy架构、Push收集模式均可以进步监控机能。
4、Zabbix在办事器监控方面占绝对劣势，能够知足90%以上的监控场景，然而运用层的监控似乎其实不长于，好比要监控线程池的形态、某个外部接口的履行时间等，这类通常都要做侵入式埋点。相同，新一代的监控零碎Open-Falcon和Prometheus在这一点做得很好。
5、从总体表示下去看，新一代监控零碎也有显著的劣势，好比：灵敏的数据模型、更成熟的时序数据库、弱小的告警功用，假如以前对zabbix这类传统监控没有技术积攒，倡议使用Open-Falcon或者Prometheus.
6、Open-Falcon的中心劣势在于数据分片功用，能撑持更多的机器和监控项；Prometheus则是容器监控方面的标配，有Google和k8s加持。
7、Zabbix、Open-Falcon和Prometheus都反对和Grafana做疾速集成，想要好看且弱小的可视化体验，能够和Grafana进行组合。
8、用适合的监控零碎解决相应的问题便可，能够多套监控同时使用，这类在企业早期很常见。
9、到中前期，跟着机器数据减少和共性化需要增多（好比但愿一致监控平台、买通公司的CMDB和组织架构瓜葛），往往需求二次开发或者经过监控零碎提供的API做集成，从这点来看，Open-Falcon或者Prometheus更适合。
10、假如非要自研，能够多钻研下主流监控零碎的架构计划，鉴戒它们的劣势。
最初的话
本文对监控体系的根底常识、原理和主流架构做了具体梳理，但愿有助于大家对监控零碎的意识，以及在技术选型时做出更适合的选择。



因为篇幅问题，本文的内容并未波及到全链路监控、日志监控、以及Web前端和客户真个监控，可见监控真的是一个宏大且繁杂的体系，假如想了解透辟，必需实践结合理论再做深化。