运维监控体系选型参考
2020-08-29 21:33:04 
阿炯
目前我所经历的几家公司，监控系统都是自研的。其实业界有很多优秀的开源产品可供选择，能满足绝大部分的监控需求，如果能从中选择一款满足企业当下的诉求，显然最省时省力。本文将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括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模式。
数据存储：有使用PostgreSQL、MySQL等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：用于存储配置信息以及采集到的数据，支持关系型数据库。同时，最新版本的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、如果非要自研，可以多研究下主流监控系统的架构方案，借鉴它们的优势，扬长补短。
04、CMDB建设从调研到落地
CMDB的建设整体过程，大致根据自已参与的经验总结为几个阶段：前期技术架构调研-->各CMDB使用方需求调研-->形成目标功能-->投入建设-->形成能力-->持续关注。本文转自运维之路，感谢原作者。
一、前期技术架构调研
在开始这部分之前，对于企业中的平台架构、资产数量、设备类型、需要纳入的关系和模型要先有一个大概的认知。接下来可以了解下业界的开源或商业CMDB常见的都有哪些，选取一到两个描述相对适配企业情况的，相对深入的了解下这些CMDB使用的技术和架构，和其他的产品相比较，这些产品的优缺点分别是什么。当前知名度相对较高的CMDB管理系统有蓝鲸、优维、乐维、itop、OneCMDB等。
这里面关注的点有：
CMDB使用的传统关系型数据库(mysql、oracle)，还是图数据库(neo4j、orientdb、rocksdb)，不同的数据库是对资产管理更方便，还是对关联关系的构建更高效。另外架构是不是还涉及存放其他数据的mongodb、es，里面各存什么数据(开源的可以搭建后简单录些测试数据看下)；
对数据的录入是支持自动采集还是手动导入，在同时有想要自动更新的数据(如硬件配置)和手工录入的数据(如人员、机柜信息)，是否处理比较方便；
对于企业有安全要求，不能安装agent的，是否有较好的API支持，支持的API方式是否是业界标准方式；
手动录入的方式是直接web界面修改、还是excel导入，还是同时支持；
录入的数据如何消费，是否支持API、web在线修改、excel导出，是否可以通过属性(IP、序列号)在线查询；
关联关系数据是怎么对应的，1对1、1对N、N对1、N对N；
查询的关联关系是以关系图的方式显示，还是同时支持原始数据的输出，是不是方便应用直接调用后，同其他应用平台结合。
有了前期这个调研总结，算是对CMDB有一定的了解了，先做个总结。接下来就可以找各使用方调研需要求了，这里以国内某CMDB的架构为例，如下：
二、CMDB消费方需求调研
在现代的运维建设中，提出了CMDB的建设是面向应用消费的，而不是仅仅只做资产管理作用。所认针对这个目标，我们的消费使用场景包含：工程上下线(资产和业务)、监控系统、根因智鉴、自动化平台、安全等。和这些消费场景的对应管理人员沟通前，我们需要先站在对方角度思路一些能和CMDB关联上的部分，先总结一些问题，带着问题去和应用方沟通。因为你直接去问，你对CMDB有什么需求，他多半是只笼统的给你说，我只要资产能录入能查，能形成关系这些模糊的概念。这不是我们要的，我们需要了解到：
应用方流程是什么样的(比如业务上下线走什么内部流程平台，是不是有相关附件输出，这些输出里是不是存一些资产信息，能不能和CMDB直接对接，在流程流转完后，直接通过流程平台解析过来的数据，完成更新)；
需要录入的资产数据是什么样子的(一般使用方都有把他自己关心的数据录成excel管理的习惯，这部分内容如果能CMDB动态管理、方便使用，估计没几个乐意一直excel吧)，有可能的话，可以把这些表给他们要过来或者以demo数据的方式要过来，这个就是后面的CI项；
需要的关系数据是哪些，详细列出(虚拟机-物理机，物理机-EOR-TOR，某某系统-nginx-tomcat-mysql)，这些就是后面应用关心的关联关系数据；
应用方希望调用的方式，是否有新增关注的功能点等。
这个对接过程不是一次就能完成后，要做好多次对应的准备。
三、形成目标功能需求
在前期的调研完成后，需要根据调研情况，形成需求功能总结、字典-配置项-属性-关系 CI模型表。功能需求表里需要涵盖这些内容：
功能需求：比如有视图管理(整体概况、机房视图)、工程管理、资产管理(录入、查询、修改)、API能力、分权分域、关联关系、自动采集、配置审计等；
功能点和规格描述：根据上面的功能需求，细化相应的功能点和功能点的描述信息。
CI模型表包含的内容：
字典(可以理解为库)：类型于目录的作用，罗列出了采集方式(自动、手动)，配置项分类(比如硬件相关的、网络相关的、业务相关的)，配置项(如，物理机、虚拟机、交换机、FW等)；
配置项(可以理解为表)：配置项里要列出属性(可以理解为列属性)，列属性就要列出来需要涵盖的属性字段(开发介入，还会增加对应的数据类型-string、布尔之类的)、关联关系(和其他属性项之间如何关联)、备注信息(采集源、采集方式)。
这些CI属性项表后面还要再找使用方确认，是不是已经覆盖了需求。同时还要输出一个能力要求模板，能力要求里会明确调用频率、调用接口时延要求、需求方、关系数据的起始终结点、数据输出的类型等。这个是产品成型后进行功能稽核要用到的。
四、投入建设
投入建设阶段，从投入方式上有使用开源、全新开发、基于开源二次开发或者直接购买企业版四种情况，如果涉及开发的，还需要加入开发模型设计的过程。从建设过程方式上，也分有从上往下构建和从下往上构建两种情况，见下图：
大多数需向业务应的企业会选择从上到下的建设方式，偏iaas层的CMDB则会选择自下而上的建设方式。这两个建设方式的不同体现在配置上，我上面有配置项的描述很多就是自下而上的建设方式。自上而下的是先某某APP、下面对应的业务模块、业务模块所在的主机、主机所在物理机-存储-网络等。自上而向下的建设如关注点见下图：
在完成在服务器的搭建以后，CMDB最重要的数据录入的环节，建议先是以某个应用需求开始，先进行录入和满足，再逐步满足其他应用。
五、形成能力和持续关注
形成能力这个很多就是使用方的事，比如根因分析和监控常见的一个场景，就是把CMDB生成的关系图调处，结合监控数据在输出的图上进行颜色区分，一眼就可以看出整体的问题出在哪一块儿，再在对应的块上进行上下钻。比如共性分析功能，可以通过将一批问题设备的上下联关系调出，通过程序求交集，得出这些设备是不是共同连接了一个存储，或者共同连接了一个交换机，可以辅助问题判断。这种能办输出后，要让应用需求方尝到甜头，这样才会有越来越多的应用感兴趣。
持续关注，CMDB的数据随着企业发展和架构演进，里面的数据也需要是活的、准确的、可快速更新的。只有长期形成，需求-采集-调用-能力这样的循环中才会形成面向应用的CMDB能力。不能建设完成后，长期不更新或停止关注，这样最后CMDB的命运就是一个摆设，各团队各用自己的表格自己玩。
以上总结结合业内一些理念和自己在实施过程中的理念进行杂糅汇总，视角偏产品经理方向。
六、小结
本文对监控体系的基础知识、原理和主流架构做了详细梳理，希望有助于大家对监控系统的认识，以及在技术选型时做出更合适的选择。
由于篇幅问题，本文的内容并未涉及到全链路监控、日志监控、以及Web前端和客户端的监控，可见监控真的是一个庞大且复杂的体系，如果想理解透彻，必须理论结合实践再做深入。
05、一例监控实施总结
要对监控有个全面的了解，大体要了解三方面的知识，如下图所示：
常见监控类型
一般在企业级技术监控领域，大体分为五种类型的监控：
基础监控：包括带宽、CDN、服务器CPU、Memory、DiskIO、Network、Load5等指标；
指标监控：服务+接口维度，常见指标有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指标；
业务监控：拿电商来说，常见的有同比下单量、支付量、履约率、DAU、GMV、支付取消率等多重指标，一般需要根据具体的业务需要来定制化；
链路监控：链路监控主要用来快速定位排查问题，在目前大多数互联网公司的微服务架构下，服务调用关系复杂，链路追踪监控可以帮助技术快速的找到调用链路上某个环节的问题。
处理过程及注意点
监控从采集到告警通知，大体分为五个步骤，每个步骤的注意事项各有不同又有部分通用的考虑。
1)数据采集
通过各种方式采集原始的相关数据，常见的有agent、埋点等方式。注意事项：主要为数据采集对业务服务的性能损耗以及对业务的侵入性两点：
一般采样都是百分比采样，比如10%，如果100%采样，对业务服务的性能损耗会比较大；良好的监控系统，对业务来说应该是无感知的，能快速接入又不影响正常的业务迭代。
2)数据存储
采集到的原始数据需要进行存储，以便于进行后续的聚合计算。注意事项：这里需要注意的点为存储时间和成本控制两方面：
存储时间：大多场景只关注最近一周或最近一个月，但有时候为了审计安全等需要，部分数据需要存储的时间会比较长，甚至有1-2年，因此需要根据具体情况来设定数据过期和清理时间；
成本控制：有些场景对数据的实时性要求比较高，因此需要存储到高速SSD，有些场景数据实时性没那么高，就可以考虑更低成本的存储方式，甚至做数据归档，然后离线计算的方式来进行后续的计算。
3)数据计算
通过对采集到的原始数据进行各种维度的计算，才能得到我们想要的监控指标。注意事项：数据计算这一环节，主要考虑的点为计算速度和结果的准确性：
计算速度：上面提到了，某些场景对于数据的实时性要求较高，因此在计算环节就需要考虑到这点。在具体的技术方案实现过程中，需要根据不同的业务需要来采用不同的技术选型和实现；
数据准确：比如上面提到的每分钟订单量，以及履约率、错误率等指标，对准确度要求是比较高的。再比如QPS这种指标，如果实时计算，对服务压力比较大，但如果取单位时间的均值，又会造成结果的准确性降低，因此在实际实践过程中，需要综合考量。
4)数据展示
即通过界面动态可视化的方式，将我们关注的监控指标进行展示。注意事项：
时延：时延这部分，上面已经阐述过了，主要还是要考虑到具体的业务场景，灵活采用技术方案；
便捷：监控是个很复杂庞大的体系，但对使用者来说，往往只关注和自己有关的模块，因此便捷可定制化的展示，良好的界面，是很需要下功夫去设计的。
5)告警通知
将已发生的或者即将发生的错误异常及时通知给相关同学，快速处理，降低影响。注意事项：
时延：告警是需要及时的做到通知的，因此对实时性要求很高。
降噪：这涉及到告警的一个敏感度问题，某些阈值怎么设置，通知到谁，怎么通知，不同等级的告警采用什么方式通知，都有很多需要考量的方面。
监控体系
监控体系是个很庞大复杂的体系，从技术角度来说，可以看下面这张图：
工具漫谈
zabbix是个综合性质的监控工具，够全面，但只适合中小型企业。当需要处理的数据和定制化需求较强时会有越来越明显的短板。
prometheus体系算是监控领域很全面灵活的，支持多种数据源，灵活配置可定制化，很多企业都在使用这套体系，但到了一定的层级维度，灵活往往会变成桎梏。还有pinpoint、cat、Prometheus、skywalking、jaeger，arthas，再演变到现在的二次开发封装的一站式监控平台。
pinpoint的采样和链路追踪做的是比较友好的，但太灵活，反而在某些阶段，不是最优解。
cat是美团开源的监控产品，但也有部分缺点，比如：监控环比只有分钟级，缺少更细的维度，界面不太友好。
skywalking是需要深度开发和改造，才能很好的应用于企业级监控需求的，它的UI操作部分，有些会显得很迷。
jaeger是个很好用的轻量级链路追踪工具，使用手感不错，建议尝试。
arthas是阿里开源的java问题定位和分析工具。
下面谷歌趋势图所示(因有些单词有二义性，具体数值可忽略，只看趋势)，与其他开源监控产品相比，2004 年的Nagios仍处在较高位置，但由于Nagios没有紧跟容器脚步、且配置复杂等缺点导致热度直线式下降。反观Zabbix，从2004年至今，由于其监控的全面性，使得其热度一直处于平稳上升阶段。此外基于RRD存储开发的Ganglia与Cacti由于产品自身的一些缺点，热度也在逐渐下降。下文我们将详细介绍各个产品的具体情况。
本节作者：Ethan Chen(云智慧解决方案架构师)，拥有丰富的运维理论及实战经验。致力于将客户需求有效地转化为公司产品场景，让客户更有效率地理解公司产品并为其提供优质的技术支撑。
Zabbix(2004)
Zabbix于1998年开发，2004年正式Release。较于其他开源监控产品，Zabbix拥有强大的指标数据存储功能、画图功能，并且真正地做到了All in One全面监控，解决了运维人力和时间成本上的问题。
基于以上功能优点，以及大量完善的教程文档，Zabbix在国内迅速传播发展。现如今，Zabbix已经进入了5.X时代，前端界面的优化、ES及TimescaleDB等时序数据库的支持，使得Zabbix又步入了一个新的时代。
优势
丰富的插件。Zabbix拥有丰富的MiB库资源以及模版等850多个插件；
易用性、依赖少。基于PHP与MySQL搭建，可用性比较强；
可进行一定颗粒度的权限控制；
文档完善。Zabbix本身定位为企业级分布式监控系统，故拥有完善的文档，活跃的官方社区，且本身也更新得比较频繁，开发比较积极；
国内市场有相关的商业支持。
劣势
MySQL数据量问题。当MySQL数据量比较大时，存储性能容易出现问题；
可视化问题。自身可视化灵活性较差，需用Grafana等进行弥补；
功能使用率低，80%的用户使用的仍为监控、看图、告警等基础功能，大部分高级功能未能被使用。
使用场景分析
监控基础设施。主机、网络设备监控等；
中小规模监控；
对于大型场景的监控来说仍需注意数据问题。
Nagios(2002)
Nagios是一个主要用于监控系统运行状态和网络信息的监控系统。Nagios能监控所指定的本地或远程主机以及服务，同时提供异常通知等功能。它拥有4000多个插件，且在很早之前就开始拥有自己的官方插件社区。这里面包括很多应用级别的监控插件。此外Nagios的通知虽然简单但能覆盖所有场景，以及本身拥有强大的监控任务调度的能力。
优势
功能简单易用，主要的功能是主动检测。
劣势
功能过于单一，只能通过主动检测告知结果是否匹配，被动检测功能原生功能较弱；
配置复杂，配置修改主机、报警、阈值等时，在原生Nagios中只能通过修改配置文件来实现，操作较为复杂。
使用场景
小场景简单监控。对于一些网站、端口等可进行简单监控；
大型场景需要各种花式Hack，需要借助很多第三方的插件进行效率的提升和分布式的扩展。
Centreon(2005)
Centreon是一款开源的软件，主要用于对Nagios的一些功能增强。可通过页面管理Nagios，通过第三方插件实现对网络，操作系统，应用程序的监控。
优势
界面友好
维护方便
统一管理
性能数据可追溯
劣势
修改配置需要重启或者重载Nagios主进程
MySQL依然存在数据问题
文档资料较少
使用场景分析
适用于百台规模的中等监控
仍需要解决原生Nagios的一些弊端
Check_MK
Check_MK是一款通用的Nagios/Icinga增强工具集。其插件有着相当成熟的检测机制和对硬件服务器的检测手段，非常适合对硬件服务器进行“体检”。
优势
界面友好
维护方便
统一管理
性能数据可追溯
劣势
增加变更需要重启Nagios主进程。
因后端存储使用RRD，导致分布式扩展较为困难。
文档资料较少。
使用场景分析
适用于百台到千台以内中等规模监控
需要解决Nagios的一些弊端
Cacti(2001)
Cacti是用PHP语言实现的一个监控软件，它的主要功能是用SNMP服务获取数据，然后用RRD储存和更新数据，当用户需要查看数据的时候用RRD生成图表呈现给用户。
优势
网络设备支持好
有权限控制
有汉化版
早期在IDC覆盖广
劣势
SNMP依赖只适合特性场景
资料老旧
使用场景分析
简单的IDC托管
网络运维
Ganglia(2001)
Ganglia是UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。主要是用来监控系统性能，如：CPU 、内存、硬盘利用率， I/O负载、网络流量情况等。
优势
数据集中，部署分布式
适合大规模部署
对集群热点观测性支持较好
劣势
无告警
集群内UDP广播问题多
使用场景分析
大数据应用
集群较多，关注整体资源使用率
监控宝(2010)
监控宝是云智慧推出的新一代用户体验监控工具，从全球节点主动模拟真实用户访问，提供网站性能监控、API监控等服务，持续监测应用程序、网站、网络和数字化服务的可用性和性能，提前诊断，实时告警，帮助客户提升网络应用效能。
优势
全球分布式监测网络。200+分布式监测节点覆盖全球112个城市以及主要运营商网络，网络规模持续扩大中。
主动监测。监测节点按照预设规则模拟真实用户发起主动监测，实时掌控网络性能，聚焦用户体验。
立体化覆盖。HTTP/HTTPS/TCP/UDP/TR/DNS/PING等多种协议类型，全面问诊网络、业务健康。
面向业务。通过包含多步请求的实务监控实现业务流程的监测，保障业务的稳定性和可用性。
持续监控。24/7小时全天候监测网站和网络性能，多渠道服务支持，减少可能发生的中断。
快照+MTR。先进的问题诊断与分析机制，问题发生之前和问题恢复之后的数据尽在掌握，快速定位故障。
灵活告警。短信、邮件、微信、语音、API等多种告警方式，确保告警能够被即时送达。
专业的分析报告。提供综合排名、竞品分析、同比/环比、日/周报等多维度的数据报告，满足专业化定制需求。
使用场景分析
网络链路质量监控与评估。通过采集不同地区、不同运营商链路的时延、丢包、网络抖动情况，从时间、地域、运营商等维度综合分析网络链路质量及可用率，快速发现和准确定位网络问题，便于及时进行链路调整，保障全网用户的体验。
CDN监控。通过海量的分布式节点模仿真实用户访问，监控CDN性能，评估CDN的加速情况，确保最佳的用户体验，可用于CDN选型评估、CDN加速效果评估、CDN故障排查与定位等使用场景。
API接口监测。通过监控API接口的响应时间、可用性和正确性并及时告警来保证API服务的可靠性，可用于API接口性能优化、第三方API接口监控等使用场景。
Graphite(2008)
Graphite是一个开源实时的、显示时间序列度量数据的图形系统，通过其后端接收度量数据，然后以实时方式查询、转换、组合这些度量数据。
优势
指标点分概念引入
Grafana支持较早的协议之一
统计函数支持(140+)
劣势
指标无Label支持
使用场景分析
在做好数据归并时可用于大规模场景
Prometheus(2016)
Prometheus 是由 SoundCloud 开源的监控告警解决方案。存储的是时序数据，即按相同时序(相同名称和标签)，以时间维度存储连续的数据的集合。
优势
时序型存储、查询效率高。
支持集群模式，扩展性强。
CNCF项目，社区活跃。
劣势
一些Exporter采集的指标众多，需进行适当裁剪。
自定义采集脚本需要脚本开发能力(Golang、Python)，相比Shell脚本来说学习成本更高一些。
使用场景分析
对于云计算、容器化场景更适合
夜莺(2018)
夜莺是一套分布式高可用的运维监控系统，前身是国内大名鼎鼎的open-falcon。基于一些国内特殊的运维场景和习惯，在运维圈中有着不俗的场景理解和用户体验。
优势
社区活跃，有open-falcon群众基础。
产品设计灵活，人性化。
v4版本自带小型CMDB和自动化。
v5版本全面拥抱开源体系(Prometheus Telegraf)。
劣势
v5刚发布，仍然需要一定的时间积累
后端存储的选型多样，需要根据场景进行选择
缺少日志类和Tracing类的监控场景
使用场景分析
所有指标类的监控
未来(2022-)
云原生的出现导致在k8s环境下的可观测性难度急剧增加，因此出现了eBPF等新技术，但无奈市场上大部分的客户Linux内核还不足以支持相关的技术。但可以看到的是DataDog skywalking 云杉等目前都在向eBPF进行布局。除了增强程序自身的可观测性之外，可以预见在不久的将来，随着Linux内核的不断的完善以及客户环境逐渐的成熟。在运维角度可以发力的可观测性的选择一定会越来越多。
本文源自互联网，原文地址已经不可考，感谢原作者。
必知必会的监控基础知识
主流监控系统介绍
监控系统的选型建议
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模式。
数据存储：有使用PostgreSQL、MySQL等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：用于存储配置信息以及采集到的数据，支持关系型数据库。同时，最新版本的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、如果非要自研，可以多研究下主流监控系统的架构方案，借鉴它们的优势，扬长补短。
04、CMDB建设从调研到落地
CMDB的建设整体过程，大致根据自已参与的经验总结为几个阶段：前期技术架构调研-->各CMDB使用方需求调研-->形成目标功能-->投入建设-->形成能力-->持续关注。本文转自运维之路，感谢原作者。
一、前期技术架构调研
在开始这部分之前，对于企业中的平台架构、资产数量、设备类型、需要纳入的关系和模型要先有一个大概的认知。接下来可以了解下业界的开源或商业CMDB常见的都有哪些，选取一到两个描述相对适配企业情况的，相对深入的了解下这些CMDB使用的技术和架构，和其他的产品相比较，这些产品的优缺点分别是什么。当前知名度相对较高的CMDB管理系统有蓝鲸、优维、乐维、itop、OneCMDB等。
这里面关注的点有：
CMDB使用的传统关系型数据库(mysql、oracle)，还是图数据库(neo4j、orientdb、rocksdb)，不同的数据库是对资产管理更方便，还是对关联关系的构建更高效。另外架构是不是还涉及存放其他数据的mongodb、es，里面各存什么数据(开源的可以搭建后简单录些测试数据看下)；
对数据的录入是支持自动采集还是手动导入，在同时有想要自动更新的数据(如硬件配置)和手工录入的数据(如人员、机柜信息)，是否处理比较方便；
对于企业有安全要求，不能安装agent的，是否有较好的API支持，支持的API方式是否是业界标准方式；
手动录入的方式是直接web界面修改、还是excel导入，还是同时支持；
录入的数据如何消费，是否支持API、web在线修改、excel导出，是否可以通过属性(IP、序列号)在线查询；
关联关系数据是怎么对应的，1对1、1对N、N对1、N对N；
查询的关联关系是以关系图的方式显示，还是同时支持原始数据的输出，是不是方便应用直接调用后，同其他应用平台结合。
有了前期这个调研总结，算是对CMDB有一定的了解了，先做个总结。接下来就可以找各使用方调研需要求了，这里以国内某CMDB的架构为例，如下：
二、CMDB消费方需求调研
在现代的运维建设中，提出了CMDB的建设是面向应用消费的，而不是仅仅只做资产管理作用。所认针对这个目标，我们的消费使用场景包含：工程上下线(资产和业务)、监控系统、根因智鉴、自动化平台、安全等。和这些消费场景的对应管理人员沟通前，我们需要先站在对方角度思路一些能和CMDB关联上的部分，先总结一些问题，带着问题去和应用方沟通。因为你直接去问，你对CMDB有什么需求，他多半是只笼统的给你说，我只要资产能录入能查，能形成关系这些模糊的概念。这不是我们要的，我们需要了解到：
应用方流程是什么样的(比如业务上下线走什么内部流程平台，是不是有相关附件输出，这些输出里是不是存一些资产信息，能不能和CMDB直接对接，在流程流转完后，直接通过流程平台解析过来的数据，完成更新)；
需要录入的资产数据是什么样子的(一般使用方都有把他自己关心的数据录成excel管理的习惯，这部分内容如果能CMDB动态管理、方便使用，估计没几个乐意一直excel吧)，有可能的话，可以把这些表给他们要过来或者以demo数据的方式要过来，这个就是后面的CI项；
需要的关系数据是哪些，详细列出(虚拟机-物理机，物理机-EOR-TOR，某某系统-nginx-tomcat-mysql)，这些就是后面应用关心的关联关系数据；
应用方希望调用的方式，是否有新增关注的功能点等。
这个对接过程不是一次就能完成后，要做好多次对应的准备。
三、形成目标功能需求
在前期的调研完成后，需要根据调研情况，形成需求功能总结、字典-配置项-属性-关系 CI模型表。功能需求表里需要涵盖这些内容：
功能需求：比如有视图管理(整体概况、机房视图)、工程管理、资产管理(录入、查询、修改)、API能力、分权分域、关联关系、自动采集、配置审计等；
功能点和规格描述：根据上面的功能需求，细化相应的功能点和功能点的描述信息。
CI模型表包含的内容：
字典(可以理解为库)：类型于目录的作用，罗列出了采集方式(自动、手动)，配置项分类(比如硬件相关的、网络相关的、业务相关的)，配置项(如，物理机、虚拟机、交换机、FW等)；
配置项(可以理解为表)：配置项里要列出属性(可以理解为列属性)，列属性就要列出来需要涵盖的属性字段(开发介入，还会增加对应的数据类型-string、布尔之类的)、关联关系(和其他属性项之间如何关联)、备注信息(采集源、采集方式)。
这些CI属性项表后面还要再找使用方确认，是不是已经覆盖了需求。同时还要输出一个能力要求模板，能力要求里会明确调用频率、调用接口时延要求、需求方、关系数据的起始终结点、数据输出的类型等。这个是产品成型后进行功能稽核要用到的。
四、投入建设
投入建设阶段，从投入方式上有使用开源、全新开发、基于开源二次开发或者直接购买企业版四种情况，如果涉及开发的，还需要加入开发模型设计的过程。从建设过程方式上，也分有从上往下构建和从下往上构建两种情况，见下图：
大多数需向业务应的企业会选择从上到下的建设方式，偏iaas层的CMDB则会选择自下而上的建设方式。这两个建设方式的不同体现在配置上，我上面有配置项的描述很多就是自下而上的建设方式。自上而下的是先某某APP、下面对应的业务模块、业务模块所在的主机、主机所在物理机-存储-网络等。自上而向下的建设如关注点见下图：
在完成在服务器的搭建以后，CMDB最重要的数据录入的环节，建议先是以某个应用需求开始，先进行录入和满足，再逐步满足其他应用。
五、形成能力和持续关注
形成能力这个很多就是使用方的事，比如根因分析和监控常见的一个场景，就是把CMDB生成的关系图调处，结合监控数据在输出的图上进行颜色区分，一眼就可以看出整体的问题出在哪一块儿，再在对应的块上进行上下钻。比如共性分析功能，可以通过将一批问题设备的上下联关系调出，通过程序求交集，得出这些设备是不是共同连接了一个存储，或者共同连接了一个交换机，可以辅助问题判断。这种能办输出后，要让应用需求方尝到甜头，这样才会有越来越多的应用感兴趣。
持续关注，CMDB的数据随着企业发展和架构演进，里面的数据也需要是活的、准确的、可快速更新的。只有长期形成，需求-采集-调用-能力这样的循环中才会形成面向应用的CMDB能力。不能建设完成后，长期不更新或停止关注，这样最后CMDB的命运就是一个摆设，各团队各用自己的表格自己玩。
以上总结结合业内一些理念和自己在实施过程中的理念进行杂糅汇总，视角偏产品经理方向。
六、小结
本文对监控体系的基础知识、原理和主流架构做了详细梳理，希望有助于大家对监控系统的认识，以及在技术选型时做出更合适的选择。
由于篇幅问题，本文的内容并未涉及到全链路监控、日志监控、以及Web前端和客户端的监控，可见监控真的是一个庞大且复杂的体系，如果想理解透彻，必须理论结合实践再做深入。
05、一例监控实施总结
要对监控有个全面的了解，大体要了解三方面的知识，如下图所示：
常见监控类型
一般在企业级技术监控领域，大体分为五种类型的监控：
基础监控：包括带宽、CDN、服务器CPU、Memory、DiskIO、Network、Load5等指标；
指标监控：服务+接口维度，常见指标有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指标；
业务监控：拿电商来说，常见的有同比下单量、支付量、履约率、DAU、GMV、支付取消率等多重指标，一般需要根据具体的业务需要来定制化；
链路监控：链路监控主要用来快速定位排查问题，在目前大多数互联网公司的微服务架构下，服务调用关系复杂，链路追踪监控可以帮助技术快速的找到调用链路上某个环节的问题。
处理过程及注意点
监控从采集到告警通知，大体分为五个步骤，每个步骤的注意事项各有不同又有部分通用的考虑。
1)数据采集
通过各种方式采集原始的相关数据，常见的有agent、埋点等方式。注意事项：主要为数据采集对业务服务的性能损耗以及对业务的侵入性两点：
一般采样都是百分比采样，比如10%，如果100%采样，对业务服务的性能损耗会比较大；良好的监控系统，对业务来说应该是无感知的，能快速接入又不影响正常的业务迭代。
2)数据存储
采集到的原始数据需要进行存储，以便于进行后续的聚合计算。注意事项：这里需要注意的点为存储时间和成本控制两方面：
存储时间：大多场景只关注最近一周或最近一个月，但有时候为了审计安全等需要，部分数据需要存储的时间会比较长，甚至有1-2年，因此需要根据具体情况来设定数据过期和清理时间；
成本控制：有些场景对数据的实时性要求比较高，因此需要存储到高速SSD，有些场景数据实时性没那么高，就可以考虑更低成本的存储方式，甚至做数据归档，然后离线计算的方式来进行后续的计算。
3)数据计算
通过对采集到的原始数据进行各种维度的计算，才能得到我们想要的监控指标。注意事项：数据计算这一环节，主要考虑的点为计算速度和结果的准确性：
计算速度：上面提到了，某些场景对于数据的实时性要求较高，因此在计算环节就需要考虑到这点。在具体的技术方案实现过程中，需要根据不同的业务需要来采用不同的技术选型和实现；
数据准确：比如上面提到的每分钟订单量，以及履约率、错误率等指标，对准确度要求是比较高的。再比如QPS这种指标，如果实时计算，对服务压力比较大，但如果取单位时间的均值，又会造成结果的准确性降低，因此在实际实践过程中，需要综合考量。
4)数据展示
即通过界面动态可视化的方式，将我们关注的监控指标进行展示。注意事项：
时延：时延这部分，上面已经阐述过了，主要还是要考虑到具体的业务场景，灵活采用技术方案；
便捷：监控是个很复杂庞大的体系，但对使用者来说，往往只关注和自己有关的模块，因此便捷可定制化的展示，良好的界面，是很需要下功夫去设计的。
5)告警通知
将已发生的或者即将发生的错误异常及时通知给相关同学，快速处理，降低影响。注意事项：
时延：告警是需要及时的做到通知的，因此对实时性要求很高。
降噪：这涉及到告警的一个敏感度问题，某些阈值怎么设置，通知到谁，怎么通知，不同等级的告警采用什么方式通知，都有很多需要考量的方面。
监控体系
监控体系是个很庞大复杂的体系，从技术角度来说，可以看下面这张图：
工具漫谈
zabbix是个综合性质的监控工具，够全面，但只适合中小型企业。当需要处理的数据和定制化需求较强时会有越来越明显的短板。
prometheus体系算是监控领域很全面灵活的，支持多种数据源，灵活配置可定制化，很多企业都在使用这套体系，但到了一定的层级维度，灵活往往会变成桎梏。还有pinpoint、cat、Prometheus、skywalking、jaeger，arthas，再演变到现在的二次开发封装的一站式监控平台。
pinpoint的采样和链路追踪做的是比较友好的，但太灵活，反而在某些阶段，不是最优解。
cat是美团开源的监控产品，但也有部分缺点，比如：监控环比只有分钟级，缺少更细的维度，界面不太友好。
skywalking是需要深度开发和改造，才能很好的应用于企业级监控需求的，它的UI操作部分，有些会显得很迷。
jaeger是个很好用的轻量级链路追踪工具，使用手感不错，建议尝试。
arthas是阿里开源的java问题定位和分析工具。
下面谷歌趋势图所示(因有些单词有二义性，具体数值可忽略，只看趋势)，与其他开源监控产品相比，2004 年的Nagios仍处在较高位置，但由于Nagios没有紧跟容器脚步、且配置复杂等缺点导致热度直线式下降。反观Zabbix，从2004年至今，由于其监控的全面性，使得其热度一直处于平稳上升阶段。此外基于RRD存储开发的Ganglia与Cacti由于产品自身的一些缺点，热度也在逐渐下降。下文我们将详细介绍各个产品的具体情况。
本节作者：Ethan Chen(云智慧解决方案架构师)，拥有丰富的运维理论及实战经验。致力于将客户需求有效地转化为公司产品场景，让客户更有效率地理解公司产品并为其提供优质的技术支撑。
Zabbix(2004)
Zabbix于1998年开发，2004年正式Release。较于其他开源监控产品，Zabbix拥有强大的指标数据存储功能、画图功能，并且真正地做到了All in One全面监控，解决了运维人力和时间成本上的问题。
基于以上功能优点，以及大量完善的教程文档，Zabbix在国内迅速传播发展。现如今，Zabbix已经进入了5.X时代，前端界面的优化、ES及TimescaleDB等时序数据库的支持，使得Zabbix又步入了一个新的时代。
优势
丰富的插件。Zabbix拥有丰富的MiB库资源以及模版等850多个插件；
易用性、依赖少。基于PHP与MySQL搭建，可用性比较强；
可进行一定颗粒度的权限控制；
文档完善。Zabbix本身定位为企业级分布式监控系统，故拥有完善的文档，活跃的官方社区，且本身也更新得比较频繁，开发比较积极；
国内市场有相关的商业支持。
劣势
MySQL数据量问题。当MySQL数据量比较大时，存储性能容易出现问题；
可视化问题。自身可视化灵活性较差，需用Grafana等进行弥补；
功能使用率低，80%的用户使用的仍为监控、看图、告警等基础功能，大部分高级功能未能被使用。
使用场景分析
监控基础设施。主机、网络设备监控等；
中小规模监控；
对于大型场景的监控来说仍需注意数据问题。
Nagios(2002)
Nagios是一个主要用于监控系统运行状态和网络信息的监控系统。Nagios能监控所指定的本地或远程主机以及服务，同时提供异常通知等功能。它拥有4000多个插件，且在很早之前就开始拥有自己的官方插件社区。这里面包括很多应用级别的监控插件。此外Nagios的通知虽然简单但能覆盖所有场景，以及本身拥有强大的监控任务调度的能力。
优势
功能简单易用，主要的功能是主动检测。
劣势
功能过于单一，只能通过主动检测告知结果是否匹配，被动检测功能原生功能较弱；
配置复杂，配置修改主机、报警、阈值等时，在原生Nagios中只能通过修改配置文件来实现，操作较为复杂。
使用场景
小场景简单监控。对于一些网站、端口等可进行简单监控；
大型场景需要各种花式Hack，需要借助很多第三方的插件进行效率的提升和分布式的扩展。
Centreon(2005)
Centreon是一款开源的软件，主要用于对Nagios的一些功能增强。可通过页面管理Nagios，通过第三方插件实现对网络，操作系统，应用程序的监控。
优势
界面友好
维护方便
统一管理
性能数据可追溯
劣势
修改配置需要重启或者重载Nagios主进程
MySQL依然存在数据问题
文档资料较少
使用场景分析
适用于百台规模的中等监控
仍需要解决原生Nagios的一些弊端
Check_MK
Check_MK是一款通用的Nagios/Icinga增强工具集。其插件有着相当成熟的检测机制和对硬件服务器的检测手段，非常适合对硬件服务器进行“体检”。
优势
界面友好
维护方便
统一管理
性能数据可追溯
劣势
增加变更需要重启Nagios主进程。
因后端存储使用RRD，导致分布式扩展较为困难。
文档资料较少。
使用场景分析
适用于百台到千台以内中等规模监控
需要解决Nagios的一些弊端
Cacti(2001)
Cacti是用PHP语言实现的一个监控软件，它的主要功能是用SNMP服务获取数据，然后用RRD储存和更新数据，当用户需要查看数据的时候用RRD生成图表呈现给用户。
优势
网络设备支持好
有权限控制
有汉化版
早期在IDC覆盖广
劣势
SNMP依赖只适合特性场景
资料老旧
使用场景分析
简单的IDC托管
网络运维
Ganglia(2001)
Ganglia是UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。主要是用来监控系统性能，如：CPU 、内存、硬盘利用率， I/O负载、网络流量情况等。
优势
数据集中，部署分布式
适合大规模部署
对集群热点观测性支持较好
劣势
无告警
集群内UDP广播问题多
使用场景分析
大数据应用
集群较多，关注整体资源使用率
监控宝(2010)
监控宝是云智慧推出的新一代用户体验监控工具，从全球节点主动模拟真实用户访问，提供网站性能监控、API监控等服务，持续监测应用程序、网站、网络和数字化服务的可用性和性能，提前诊断，实时告警，帮助客户提升网络应用效能。
优势
全球分布式监测网络。200+分布式监测节点覆盖全球112个城市以及主要运营商网络，网络规模持续扩大中。
主动监测。监测节点按照预设规则模拟真实用户发起主动监测，实时掌控网络性能，聚焦用户体验。
立体化覆盖。HTTP/HTTPS/TCP/UDP/TR/DNS/PING等多种协议类型，全面问诊网络、业务健康。
面向业务。通过包含多步请求的实务监控实现业务流程的监测，保障业务的稳定性和可用性。
持续监控。24/7小时全天候监测网站和网络性能，多渠道服务支持，减少可能发生的中断。
快照+MTR。先进的问题诊断与分析机制，问题发生之前和问题恢复之后的数据尽在掌握，快速定位故障。
灵活告警。短信、邮件、微信、语音、API等多种告警方式，确保告警能够被即时送达。
专业的分析报告。提供综合排名、竞品分析、同比/环比、日/周报等多维度的数据报告，满足专业化定制需求。
使用场景分析
网络链路质量监控与评估。通过采集不同地区、不同运营商链路的时延、丢包、网络抖动情况，从时间、地域、运营商等维度综合分析网络链路质量及可用率，快速发现和准确定位网络问题，便于及时进行链路调整，保障全网用户的体验。
CDN监控。通过海量的分布式节点模仿真实用户访问，监控CDN性能，评估CDN的加速情况，确保最佳的用户体验，可用于CDN选型评估、CDN加速效果评估、CDN故障排查与定位等使用场景。
API接口监测。通过监控API接口的响应时间、可用性和正确性并及时告警来保证API服务的可靠性，可用于API接口性能优化、第三方API接口监控等使用场景。
Graphite(2008)
Graphite是一个开源实时的、显示时间序列度量数据的图形系统，通过其后端接收度量数据，然后以实时方式查询、转换、组合这些度量数据。
优势
指标点分概念引入
Grafana支持较早的协议之一
统计函数支持(140+)
劣势
指标无Label支持
使用场景分析
在做好数据归并时可用于大规模场景
Prometheus(2016)
Prometheus 是由 SoundCloud 开源的监控告警解决方案。存储的是时序数据，即按相同时序(相同名称和标签)，以时间维度存储连续的数据的集合。
优势
时序型存储、查询效率高。
支持集群模式，扩展性强。
CNCF项目，社区活跃。
劣势
一些Exporter采集的指标众多，需进行适当裁剪。
自定义采集脚本需要脚本开发能力(Golang、Python)，相比Shell脚本来说学习成本更高一些。
使用场景分析
对于云计算、容器化场景更适合
夜莺(2018)
夜莺是一套分布式高可用的运维监控系统，前身是国内大名鼎鼎的open-falcon。基于一些国内特殊的运维场景和习惯，在运维圈中有着不俗的场景理解和用户体验。
优势
社区活跃，有open-falcon群众基础。
产品设计灵活，人性化。
v4版本自带小型CMDB和自动化。
v5版本全面拥抱开源体系(Prometheus Telegraf)。
劣势
v5刚发布，仍然需要一定的时间积累
后端存储的选型多样，需要根据场景进行选择
缺少日志类和Tracing类的监控场景
使用场景分析
所有指标类的监控
未来(2022-)
云原生的出现导致在k8s环境下的可观测性难度急剧增加，因此出现了eBPF等新技术，但无奈市场上大部分的客户Linux内核还不足以支持相关的技术。但可以看到的是DataDog skywalking 云杉等目前都在向eBPF进行布局。除了增强程序自身的可观测性之外，可以预见在不久的将来，随着Linux内核的不断的完善以及客户环境逐渐的成熟。在运维角度可以发力的可观测性的选择一定会越来越多。
本文源自互联网，原文地址已经不可考，感谢原作者。