大家好，我是陈谋~在这篇文章中，我将系统梳理监控系统的基础知识、原理和架构，同时介绍一些最常用的开源监控产品，供大家参考。您选型时的参考。内容包括3个部分：必知的监控基础知识、主流监控系统介绍、监控系统选型建议、关注公众号：码猿技术专栏，回复关键词：1111获取阿里巴巴内部Java性能调优手册，你必须知道的监控基础知识我们可以理解为监控系统就像是我们古代的哨兵。哨兵的作用非常重要。当敌人来临时，哨兵会第一时间发出预警（吹笛、击鼓、冒烟），让守城的士兵能够在最快的时间内应对和应对。对于我们的应用系统来说，监控系统就像是我们的第三只眼。如果应用系统出现问题，我们可以通过监控系统查看问题出在哪里，是redis宕机了，还是服务器内存满了。系统我们可以方便快捷的定位问题。我们甚至可以设置预警，提前预防和处理一些即将出现的问题，及时避免问题的发生。1、监控系统辅助故障定位的作用：当出现故障时，我们可以通过查看监控系统的各项指标数据，辅助故障分析定位。预警降低故障率：对可能发生的故障及时发出预警信息，提前进行预防性处理。辅助容量规划：为服务器、中间件、应用集群的容量规划提供数据支持。辅助性能调优：JVM垃圾回收次数、接口响应时间、慢SQL等可监控优化。2、常见的监测对象和指标有哪些？服务器监控：CPU使用率、内存使用率、磁盘使用率、磁盘读写吞吐量、网络进出流量等MySQL监控：TPS、QPS、数据库连接数、慢SQL、InnoDB缓冲池命中率等Redis监控：内存使用率、缓存命中率、总key值、Redis响应请求时间、客户端连接数、持久化指标等MQ监控：连接数、队列数、生产率、消费率、消息堆积等。应用监控：HTTP接口：URL存活、请求量、耗时、异常量JVM：GC次数、GC耗时、各内存区大小、当前线程数、死锁线程数线程池：活跃线程数、任务队列大小、任务执行耗时，拒绝任务数3.监控系统基本流程数据采集：采集数据的方式有很多种，包括日志埋点采集，JMX标准接口输出监控指标，监控对象提供RESTAPI获取数据集合（如Hadoop、ES）、系统命令行、侵入式埋点上报统一SDK等。数据传输：将采集到的数据以TCP、UDP或HTTP协议的形式上报给监控系统。有主动Push模式和被动Pull模式。数据存储：有的使用MySQL、Oracle等关系型数据库进行存储，有的使用时序数据库RRDTool、OpentTSDB、InfluxDB进行存储，有的使用HBase进行存储。数据显示：数据指标图形化显示。监控告警：告警设置灵活，支持邮件、短信、IM等多种通知渠道。对比市面上一些常见的监控系统，让我们来认识一下主流的开源监控系统。限于篇幅，我挑选了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已经开始支持时序数据库，但成熟度还不高。WebServer：Zabbix的GUI组件，用PHP编写，提供监控数据展示和告警配置。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都使用一致性哈希进行数据分片，以提高水平扩展能力。同时Transfer还支持将数据分发到OpenTSDB进行历史归档。Graph：数据存储组件，底层使用RRDTool（时间序列数据库）存储单个指标，并通过缓存和批量写入磁盘进行优化。据说一个图实例可以处理每秒8W+的写入速率。JudgeandAlarm：报警元件。Judge实时计算Transfer组件上报的数据，判断是否产生告警事件。Alarm组件收敛告警事件后，将告警消息推送到各个消息通道。API：对于终端用户来说，在收到查询请求后，会查询Graph中的指标数据，并将结果汇??总后返回给用户，屏蔽了存储集群的分片细节。Open-Falcon自动采集能力优势：Falcon-agent可以自动采集服务器200多项基础指标（如CPU、内存等），服务器无需任何配置，秒杀Zabbix。强大的存储能力：底层采用RRDTool，通过一致性哈希对数据进行分片，构建分布式时序数据存储系统，具有很强的扩展性。灵活的数据模型：参考OpenTSDB，在数据模型中引入标签，可以支持多维度的聚合统计和告警规则设置，大大提高了使用效率。插件统一管理：Open-Falcon的插件机制实现了用户自定义脚本的统一管理，可以通过HeartBeatServer分发给代理，降低用户独立维护脚本的成本。个性化监控支持：基于Proxy-gateway，通过自埋点轻松实现应用层监控（如监控接口访问、耗时等）等个性化监控需求，集成方便。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语言来查询和分析数据。Pushgateway：由于Prometheus数据采集设置为pull模式，内置必须保证prometheusserver和对应的exporter必须通信。当网络情况不能直接满足时，可以使用pushgateway进行中转，内网数据可以通过pushgateway主动推送到网关，prometheus使用pull方式拉取pushgateway中的数据。AlertManager：当支持基于PromQL创建告警规则时，如果满足定义的规则，将生成一条告警信息，并进入AlertManager进行处理。您可以集成邮箱、微信或通过webhook自定义告警。WebUI：Prometheus内置了一个简单的Web控制台，可以查询配置信息和指标。在实际应用中，我们通常使用Prometheus作为Grafana的数据源来创建仪表盘和查看指标。Prometheus的优势社区活跃度高：github启动超过40k，并且一直在维护。基于时序数据库，存储效率高：Prometheus核心部分只有一个二进制文件，没有第三方依赖（数据库、缓存等）。唯一需要的是本地磁盘，因此不存在潜在的级联故障风险。良好的容器监控支持：可以自动发现容器，k8s、etcd等项目原生支持Prometheus，是目前最流行的容器监控方案。基于Pull模型的架构：Prometheus是基于Pull模型的架构，我们的监控系统可以搭建在任何地方（本地电脑、开发环境、测试环境）。Prometheus的缺点Prometheus是基于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、如果非要自己研究，可以研究一下主流监控系统的架构方案，学习他们的优点。欢迎加入陈氏知识星球，一起学习签到，一起交流技术。如何加入，扫描下方二维码：知识星球已更新以下栏目，详情点击链接）：《我要进大厂》：大厂面试测试系列总结、系统架构设计、实战总结与优化..《亿级数据分库分表实战》：以文章和视频的形式，分享亿级数据的分库分表实战：从SpringBoot入门到源码级别的整理文章《精尽Spring系列》：迭代47+文章，源码层级介绍，完整案例源码，Java后端相关技术源码讲解，文末全栈学习路线图我就说（不嫖，求关注）陈氏的每篇文章精心输出，他写了3个专栏，整理成PDF。专栏】回复关键词SpringCloud进阶获取！《Spring Boot 进阶》PDF：关注公众号：【码猿技术专栏】回复关键词SpringBoot进阶获取！《Mybatis 进阶》PDF：关注公众号：【码猿技术专栏】回复关键词Mybatis进阶获取！如果本文对您有帮助或启发，请点赞、观看、转发、收藏，您的支持是我坚持下去的最大动力！
