这篇文章，我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括 3 部分：
监控系统俗称「第三只眼」，几乎是我们每天都会打交道的系统，下面 4 项基础知识我认为是必须要了解的。
正所谓「无监控，不运维」，监控系统的地位不言而喻。不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么？它能发挥什么作用？
“
出任何线上事故，先不说其他地方有问题，监控部分一定是有问题的。
听着很甩锅的一句话，仔细思考好像有一定道理。我们在事故复盘时，通常会思考这3个和监控有关的问题：有没有做监控？监控是否及时？监控信息是否有助于快速定位问题？
可见光有一套好的监控系统还不够，还必须知道「如何用好它」。一个成熟的研发团队通常会定一个监控规范，用来统一监控系统的使用方法。
监控已然成为了整个产品生命周期非常重要的一环，运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。可见，监控的对象已经越来越立体化。这里，我对常用的监控对象以及监控指标做了分类整理，供大家参考。
3.1 硬件监控
包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
包括：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
无论是开源的监控系统还是自研的监控系统，监控的整个流程大同小异，一般都包括以下模块：
下面再来认识下主流的开源监控系统，由于篇幅有限，我挑选了3款使用最广泛的监控系统：Zabbix、Open-Falcon、Prometheus，会对它们的架构进行介绍，同时总结下各自的优劣势。
1. Zabbix（老牌监控的优秀代表）
Zabbix 1998年诞生，核心组件采用C语言开发，Web端采用PHP开发。它属于老牌监控系统中的优秀代表，监控功能很全面，使用也很广泛，差不多有70%左右的互联网公司都曾使用过 Zabbix 作为监控解决方案。
项目地址：https://github.com/zabbix/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 的优势：
下面是 Zabbix 的劣势：
2. Open-Falcon（小米出品，国内流行）
Open-falcon 是小米2015年开源的企业级监控工具，采用Go和Python语言开发，这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过200家公司在使用它。
项目地址：https://github.com/open-falcon/falcon-plus
小米初期也使用的Zabbix进行监控，但是机器量和业务量上来后，Zabbix就有些力不从心了。因此，后来自主研发了Open-Falcon，在架构设计上吸取了Zabbix的经验，同时很好地解决了Zabbix的诸多痛点。
先来了解下Open-Falcon的架构设计：
Open-Falcon架构图，来自网络
下面是Open-Falcon的优势：
自动采集能力：Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等），无需在server上做任何配置，这一点可以秒杀Zabbix.
- 强大的存储能力：底层采用RRDTool，并且通过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。
灵活的数据模型：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。
插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本。
个性化监控支持：基于Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。
下面是Open-Falcon的劣势：
3. Prometheus（号称下一代监控系统）
Prometheus（普罗米修斯）是由前google员工2015年正式发布的开源监控系统，采用Go语言开发。它不仅有一个很酷的名字，同时它有Google与k8s的强力支持，开源社区异常火爆。
项目地址：https://github.com/prometheus/prometheus
Prometheus 2016年加入云原生基金会，是继k8s后托管的第二个项目，未来前景被相当看好。它和Open-Falcon最大不同在于：数据采集是基于Pull模式的，而不是Push模式，并且架构非常简单。
先来了解下Prometheus的架构设计：
下面是Prometheus的优势：
轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的Server，便于迁移和维护。
-
较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库中，单个实例可以处理数百万的metrics。
灵活的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更方便。
强大的查询语句：PromQL允许在同一个查询语句中，对多个metrics进行加法、连接和取分位值等操作。
很好地支持云环境：能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。
下面是Prometheus的劣势：
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前端和客户端的监控，可见监控真的是一个庞大且复杂的体系，如果想理解透彻，必须理论结合实践再做深入。对于运维监控体系，如果你们也有自己的经验和体会，欢迎留言讨论。
关注公众号加入交流群
