我会系统地梳理监控系统的基础知识、原理和架构，同时也会回顾几个最常用的开源监控系统。现将产品介绍如下，供您选型时参考。内容包括3个部分：必知的监控基础知识、主流监控系统介绍、监控系统选型建议。非常重要的是，当敌人来临时，哨兵会发出预警（吹笛、击鼓、放烟），让守城的士兵尽快应对。对于我们的应用系统来说，监控系统就像是我们的第三只眼。如果应用系统出现问题，我们可以通过监控系统查看问题出在哪里，是redis宕机了，还是服务器内存满了。系统我们可以方便快捷的定位问题。我们甚至可以设置预警，提前预防和处理一些即将出现的问题，及时避免问题的发生。1、监控系统的作用1）帮助定位故障当故障发生时，我们可以通过查看监控系统的各种指标数据，辅助进行故障分析和定位。2）预警降低故障率对即将发生的可能发生的故障及时发布预警信息，提前做好预防性处理。3）辅助容量规划，为服务器、中间件、应用集群的容量规划提供数据支持。4）辅助性能调优JVM垃圾回收次数、接口响应时间、慢SQL等可监控优化。2、常见的监测对象和指标有哪些？1）服务器监控CPU使用率、内存使用率、磁盘使用率、磁盘读写吞吐量、网络进出流量等2）MySQL监控TPS、QPS、数据库连接数、慢SQL、InnoDB缓冲池命中率、等3）Redis监控内存使用率、缓存命中率、总key值、Redis响应请求时间、客户端连接数、持久化指标等4）MQ监控连接数、队列、生产率、消费率、消息积累等。5）应用监控HTTP接口：URL存活、请求量、耗时量、异常量。JVM：GC次数，GC时间，每个内存区域的大小，当前线程数，死锁线程数。线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数。三、监控系统的基本流程1）数据采集采集的方式有很多种，包括日志埋点采集，JMX标准接口输出监控指标，监控对象提供RESTAPI进行数据采集（如Hadoop、ES）,系统指令是的，统一SDK进行侵入点埋点和上报。2）数据传输将采集到的数据以TCP、UDP或HTTP协议的形式上报给监控系统，有主动Push方式和被动Pull方式。3）数据存储使用MySQL、Oracle等关系型数据库，时序数据库RRDTool、OpentTSDB、InfluxDB、HBase等。4)数据显示数据指标的图形化显示。5)监控告警灵活的告警设置，支持邮件、短信、IM等多种通知渠道。2.市面上常见的一些监控系统对比下面我们来认识一下主流的开源监控系统。限于篇幅，我挑选了3个使用最广泛的监控系统：Zabbix、Open-Falcon、Prometheus，并分析它们的架构。介绍并总结各自的优缺点。一、Zabbix简介Zabbix诞生于1998年，核心组件采用C语言开发，Web端采用PHP开发。是旧监控系统的优秀代表。监控功能全面，应用广泛。几乎70%的互联网公司都使用Zabbix作为监控解决方案。我们先了解下Zabbix的架构设计：ZabbixServer的核心组件，用C语言编写，负责接收Agent和Proxy发送过来的监控数据。同时还负责数据的汇总存储和告警触发。ZabbixProxy是一个可选组件。当被监控的机器较多时，可以使用Proxy进行分布式监控。可以代Server采集部分监控数据，减轻Server的压力。ZabbixAgentd部署在被监控主机上，用于收集本地数据并发送给Proxy或Server。数据采集??方式支持主动Push和被动Pull两种方式。数据库用于存储配置信息和收集的数据，支持MySQL、Oracle等关系型数据库。同时最新版本的Zabbix已经开始支持时序数据库，但成熟度还不高。WebServerZabbix的GUI组件，用PHP编写，提供监控数据展示和告警配置。1）Zabbix的优势成熟。由于历史悠久、用途广泛，其文档丰富，开源的各种数据采集插件，可以覆盖绝大部分监控场景。丰富的采集方式支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式。2）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都使用一致性哈希进行数据分片，以提高水平扩展能力。同时Transfer还支持将数据分发到OpenTSDB进行历史归档。图数据存储组件，底层使用RRDTool（时间序列数据库）存储单个指标，并通过缓存和批量写入磁盘进行优化。据说一个图实例可以处理每秒8W+的写入速率。Judge和Alarm告警组件，Judge实时计算Transfer组件上报的数据，判断是否产生告警事件，Alarm组件对告警事件进行收敛处理，将告警消息推送到各个消息通道。API面向最终用户。收到查询请求后，查询Graph中的指标数据，汇总后返回给用户，屏蔽了存储集群的分片细节。1）Open-Falcon优势自动采集能力Falcon-agent可以自动采集服务器200多项基础指标（如CPU、内存等），服务器无需任何配置，秒杀Zabbix。RRDTool，通过一致性哈希对数据进行分片，构建了一个分布式时序数据存储系统，具有很强的扩展性。灵活的数据模型借鉴了OpenTSDB，在数据模型中引入了标签，可以支持多维度的聚合统计和告警规则设置，大大提高了使用效率。插件统一管理Open-Falcon的插件机制实现了用户自定义脚本的统一管理，可以通过HeartBeatServer分发给代理，降低用户独立维护脚本的成本。个性化监控支持基于Proxy-gateway，通过自埋点轻松实现应用层监控（如监控接口访问、耗时等）等个性化监控需求，集成方便。2）Open-Falcon监控类型较少，不支持tomcat、apache、jetty等常用应用服务器的监控，整体发展一般，社区活跃度低，没有专门的运维支持，代码更新较少，也没有大型社区维护。以后想要有什么新的能力，基本上可以靠自己的拓展。3、Prometheus（被誉为下一代监控系统）我们知道zabbix在监控界占有不可动摇的地位，功能强大。但容器监控似乎无能为力。为了解决容器的监控问题，引入了Prometheus技术。Prometheus是一个开源的系统监控和报警框架。是前谷歌员工于2015年正式发布的一款开源监控系统，采用Go语言开发。它不仅名字很酷，而且有Google和k8s的大力支持，开源社区异常火爆。我们先来了解下Prometheus的架构设计：Exporter主要用于采集数据，通过HTTP服务暴露给PrometheusServer。PrometheusServer可以通过访问Exporter提供的接口获取需要采集的监控数据。常见的exporter有很多，比如node_exporter、mysqld_exporter、redis_exporter等PrometheusServer的核心组件，负责监控数据的获取、存储和查询。PrometheusServer也是一个时序数据库，将监控数据保存在本地磁盘，并提供自定义的PromQL语言来查询和分析数据。由于Push网关设置为pull模式进行Prometheus数据采集，内置必须保证prometheusserver和对应的exporter必须通信。当网络情况不能直接满足时，可以使用pushgateway进行中转，将内网数据主动推送到gateway，prometheus使用pull的方式拉取pushgateway中的数据。AlertManager支持创建基于PromQL的警报规则。如果满足定义的规则，将生成警报消息并输入AlertManager进行处理。您可以集成邮箱、微信或通过webhook自定义告警。WebUIPrometheus内置了一个简单的web控制台，可以查询配置信息和指标。在实际应用中，我们通常使用Prometheus作为Grafana的数据源，创建仪表盘和查看指标。1）Prometheus的优势社区活跃度高，githubstart超过40k，一直在维护。基于时序数据库，存储效率高。Prometheus的核心部分只有一个单一的二进制文件，没有第三方依赖（数据库、缓存等）。唯一需要的是本地磁盘，因此不存在潜在的级联故障风险。支持容器监控，可以自动发现容器。同时，k8s、etcd等项目原生支持Prometheus，是目前最流行的容器监控方案。基于Pull模型的架构Prometheus是基于Pull模型的架构，我们可以在任何地方（本地电脑、开发环境、测试环境）构建我们的监控系统。2）普罗米修斯的缺点普罗米修斯是基于Metric的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。由于Prometheus采用拉取模型来拉取数据，这意味着所有被监控的端点必须是可达的，并且需要妥善规划网络的安全配置。指标很多，需要适当调整。三、选型建议通过上面的介绍，大家应该对主流的监控系统有了一定的了解。面对选型问题，我的建议是：1）首先明确自己的监控需求：监控的对象是什么？有多少台机器和监控指标？需要什么样的报警功能？2）监控是一项长期的建设工程。我从一开始就想构建一个AllInOne监控解决方案，但我认为没有必要。从成本上来说，前期直接使用开源的监控方案就可以了，先解决问题。3）从系统成熟度来看，Zabbix是老牌的监控系统，数据量大，功能全面稳定。如果机器数量在几百台以内，就不用太担心性能问题。此外，它还使用了数据库分区、SSD硬盘和Proxy架构，推送采集方式可以提高监控性能。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）如果非要自己研究，可以研究一下主流监控系统的架构方案，学习它们的优点。
