这篇文章 ，监控我将对监控体系的系统选型基础知识、原理和架构做一次系统性整理 ，篇全同时还会对几款最常用的搞定开源监控产品做下介绍 ，以便大家选型时参考 。监控内容包括3部分 ：
必知必会的系统选型监控基础知识主流监控系统介绍监控系统的选型建议必知必会的监控基础知识
我们可以理解监控系统就像我们古代打战的哨兵一样 ，哨兵的篇全角色非常重要，敌人来了 ，搞定哨兵会第一时间发出预警(吹笛、监控打鼓 、源码下载系统选型放烟) ，篇全让守城的搞定战士能够最快的时间处理，应对 。监控
那对于我们应用系统而言 ，系统选型监控系统就像我们第三只眼 ，篇全如果有应用系统出现问题，我们可以通过监控系统看是哪里出现问题，是redis挂了 ，还是说服务器内存满了，有监控系统我们可以很轻松 、快速的源码库定位问题。
甚至我们可以设置预警 ，对一些将要出现的问题进行提前预防处理 ，及时避免问题的发生 。
1 、监控系统的作用
HTTP接口 ：URL存活 、请求量 、耗时 、服务器租用异常量
JVM ：GC次数、GC耗时、各个内存区域的大小 、当前线程数、死锁线程数
线程池 ：活跃线程数 、任务队列大小 、任务执行耗时 、拒绝任务数
3 、监控系统的基本流程
市面上的一些常见监控系统比较
下面再来认识下主流的开源监控系统 ，由于篇幅有限 ，我挑选了3款使用最广泛的监控系统 ：Zabbix 、Open-Falcon 、Prometheus ，会对它们的架构进行介绍 ，同时总结下各自的优劣势 。
1 、Zabbix介绍
Zabbix 1998年诞生 ，核心组件采用C语言开发 ，Web端采用PHP开发 。它属于老牌监控系统中的优秀代表 ，监控功能很全面 ，使用也很广泛，差不多有70%左右的互联网公司都曾使用过 Zabbix 作为监控解决方案 。
先来了解下Zabbix的架构设计 ：
Zabbix的优势：
产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件 ，能覆盖绝大部分监控场景 。采集方式丰富 ：支持Agent、SNMP 、JMX 、SSH等多种采集方式 ，以及主动和被动的数据传输方式 。Zabbix的劣势 ：
需要在被监控主机上安装Agent ，所有的数据都存在数据库里 ，产生的数据很大 ，瓶颈主要在数据库 。
2 、Open-Falcon（小米出品，国内流行）Open-falcon 是小米2015年开源的企业级监控工具，采用Go和Python语言开发，这是一款灵活 、高性能且易扩展的新一代监控方案，目前小米 、美团 、滴滴等超过200家公司在使用它 。
小米初期也使用的Zabbix进行监控 ，但是机器量和业务量上来后，Zabbix就有些力不从心了 。因此 ，后来自主研发了Open-Falcon ，在架构设计上吸取了Zabbix的经验 ，同时很好地解决了Zabbix的诸多痛点。
架构看去比Zabbix复杂多了，其实它也是基于Server---Agent的模式 ，只不过Server又给他划分了好几个组件 ，这个耦合性和扩展性都得到了明显提高。
Falcon-agent：数据采集器和收集器 ，Go开发，部署在被监控的机器上 。就相当于Agent ，用于采集机器负载监控指标数据如：CPU、内存 、磁盘、IO 、网络 、端口等等大概有200多个这些都可以自定是否收集 。Transfer ：数据分发组件 ，接收客户端发送的数据，分别发送给数据存储组件Graph和告警判定组件Judge ，Graph和Judge均采用一致性hash做数据分片，以提高横向扩展能力 。同时Transfer还支持将数据分发到OpenTSDB ，用于历史归档。Graph ：数据存储组件 ，底层使用RRDTool（时序数据库）做单个指标的存储，并通过缓存 、分批写入磁盘等方式进行了优化 。据说一个graph实例能够处理8W+每秒的写入速率 。Judge和Alarm ：告警组件 ，Judge对Transfer组件上报的数据进行实时计算，判断是否要产生告警事件 ，Alarm组件对告警事件进行收敛处理后，将告警消息推送给各个消息通道。API ：面向终端用户，收到查询请求后会去Graph中查询指标数据，汇总结果后统一返回给用户，屏蔽了存储集群的分片细节 。
复制Open-Falcon优势1. 自动采集能力 ：Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等） ，无需在server上做任何配置，这一点可以秒杀Zabbix.强大的存储能力 ：底层采用RRDTool ，并且通过一致性hash进行数据分片 ，构建了一个分布式的时序数据存储系统 ，可扩展性强 。灵活的数据模型 ：借鉴OpenTSDB ，数据模型中引入了tag ，这样能支持多维度的聚合统计以及告警规则设置 ，大大提高了使用效率。插件统一管理 ：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理 ，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本 。个性化监控支持 ：基于Proxy-gateway ，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求 ，集成方便 。 复制Open-Falcon缺点1. 监控类型较少: 不支持常用应用服务器如tomcat 、apache 、jetty等的监控 。整体发展一般 ，社区活跃度低: 没有专门的运维支持 ，代码更新较少 ，没有一个较大的社区来维护 ，后续想要有什么新的能力基本只能指望自己扩展 。3 、Prometheus（号称下一代监控系统）我们知道 zabbix 在监控界占有不可撼动的地位 ，功能强大 。但是对容器监控显得力不从心 。为解决监控容器的问题 ，引入了 Prometheus 技术 。
Prometheus 是一套开源的系统监控报警框架 。是由前google员工2015年正式发布的开源监控系统，采用Go语言开发 。它不仅有一个很酷的名字 ，同时它有Google与k8s的强力支持，开源社区异常火爆 。
先来了解下Prometheus的架构设计 ：
社区活跃度高: github start超过40k ，且一直在维护 。
基于时序数据库 ，存储效率高:Prometheus核心部分只有一个单独的二进制文件 ，不存在任何的第三方依赖(数据库 ，缓存等等) 。唯一需要的就是 本地磁盘 ，因此不会有潜在级联故障的风险 。
很好地支持容器监控: 能自动发现容器 ，同时k8s和etcd等项目都提供了对Prometheus的原生支持 ，是目前容器监控最流行的方案。
基于Pull模型的架构: Prometheus基于Pull模型的架构方式 ，可以在任何地方（本地电脑 ，开发环境 ，测试环境）搭建我们的监控系统。
复制Prometheus缺点1.Prometheus 是基于 Metric 的监控 ，不适用于日志（Logs） 、事件(Event)、调用链(Tracing)。
由于Prometheus采用的是Pull模型拉取数据 ，意味着所有被监控的endpoint必须是可达的，需要合理规划网络的安全配置 。
指标众多 ，需进行适当裁剪。
选型建议通过上面的介绍 ，大家对主流的监控系统应该有了一定的认识。面对选型问题，我的建议是：
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 、如果非要自研 ，可以多研究下主流监控系统的架构方案 ，借鉴它们的优势。
