篇首语:本文由编程笔记#小编为大家整理,主要介绍了监控系统选型看这一篇够了!选择 Prometheus 还是 Zabbix ?相关的知识,希望对你有一定的参考价值。
之前,我写过几篇有关「线上问题排查」的文章,文中附带了一些监控图,有些读者对此很感兴趣,问我监控系统选型上有没有好的建议?
目前我所经历的几家公司,监控系统都是自研的。其实业界有很多优秀的开源产品可供选择,能满足绝大部分的监控需求,如果能从中选择一款满足企业当下的诉求,显然最省时省力。
这篇文章,我将对监控体系的基础知识、原理和架构做一次系统性整理,同时还会对几款最常用的开源监控产品做下介绍,以便大家选型时参考。内容包括3部分:
监控系统俗称「第三只眼」,几乎是我们每天都会打交道的系统,下面 4 项基础知识我认为是必须要了解的。
辅助性能调优:为性能调优提供数据支持,比如慢SQL,接口响应时间等。
“
出任何线上事故,先不说其他地方有问题,监控部分一定是有问题的。
听着很甩锅的一句话,仔细思考好像有一定道理。我们在事故复盘时,通常会思考这3个和监控有关的问题:有没有做监控?监控是否及时?监控信息是否有助于快速定位问题?
可见光有一套好的监控系统还不够,还必须知道「如何用好它」。一个成熟的研发团队通常会定一个监控规范,用来统一监控系统的使用方法。
定义合理的报警阈值和等级:达到什么阈值需要告警?对应的故障等级是多少?不需要处理的告警不是好告警,可见定义合理的阈值有多重要,否则只会降低运维效率或者让监控系统失去它的作用。
3.1 硬件监控
包括:电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
磁盘:磁盘使用率、磁盘读写的吞吐量
包括:数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
缓存 :成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
JVM :GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
数据传输:将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统,有主动Push模式,也有被动Pull模式。
数据展示:数据指标的图形化展示。
监控告警:灵活的告警设置,以及支持邮件、短信、IM等多种通知通道。
1. Zabbix(老牌监控的优秀代表)
Zabbix 1998年诞生,核心组件采用C语言开发,Web端采用php开发。它属于老牌监控系统中的优秀代表,监控功能很全面,使用也很广泛,差不多有70%左右的互联网公司都曾使用过 Zabbix 作为监控解决方案。
先来了解下Zabbix的架构设计:
Zabbix架构图
Zabbix Proxy:可选组件,对于被监控机器较多的情况下,可使用Proxy进行分布式监控,它能代理Server收集部分监控数据,以减轻Server的压力。
Database:用于存储配置信息以及采集到的数据,支持MySQL、Oracle等关系型数据库。同时,最新版本的Zabbix已经开始支持时序数据库,不过成熟度还不高。
Web Server:Zabbix的GUI组件,PHP编写,提供监控数据的展现和告警配置。
下面是 Zabbix 的优势:
产品成熟:由于诞生时间长且使用广泛,拥有丰富的文档资料以及各种开源的数据采集插件,能覆盖绝大部分监控场景。
下面是 Zabbix 的劣势:
性能瓶颈:机器量或者业务量大了后,关系型数据库的写入一定是瓶颈,官方给出的单机上限是5000台,个人感觉达不到,尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库,不过成熟度还不高。
Open-falcon 是小米2015年开源的企业级监控工具,采用Go和Python语言开发,这是一款灵活、高性能且易扩展的新一代监控方案,目前小米、美团、滴滴等超过200家公司在使用它。
小米初期也使用的Zabbix进行监控,但是机器量和业务量上来后,Zabbix就有些力不从心了。因此,后来自主研发了Open-Falcon,在架构设计上吸取了Zabbix的经验,同时很好地解决了Zabbix的诸多痛点。
先来了解下Open-Falcon的架构设计:
Open-Falcon架构图,来自网络
Graph:数据存储组件,底层使用RRDTool(时序数据库)做单个指标的存储,并通过缓存、分批写入磁盘等方式进行了优化。据说一个graph实例能够处理8W+每秒的写入速率。
下面是Open-Falcon的优势:
自动采集能力:Falcon-agent 能自动采集服务器的200多个基础指标(比如CPU、内存等),无需在server上做任何配置,这一点可以秒杀Zabbix.
灵活的数据模型:借鉴OpenTSDB,数据模型中引入了tag,这样能支持多维度的聚合统计以及告警规则设置,大大提高了使用效率。
插件统一管理:Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理,可通过HeartBeat Server分发给agent,减轻了使用者自主维护脚本的成本。
个性化监控支持:基于Proxy-gateway,很容易通过自主埋点实现应用层的监控(比如监控接口的访问量和耗时)和其他个性化监控需求,集成方便。
下面是Open-Falcon的劣势:
整体发展一般:社区活跃度不算高,同时版本更新慢,有些大厂是基于它的稳定版本直接做二次开发的,关于以后的前景其实有点担忧。
安装比较复杂:个人的亲身感受,由于它是从小米内部衍生出来的,虽然去掉了对小米内部系统的依赖,但是组件还是比较多,如果对整个架构不熟悉,安装很难一蹴而就。
3. Prometheus(号称下一代监控系统)
Prometheus(普罗米修斯)是由前google员工2015年正式发布的开源监控系统,采用Go语言开发。它不仅有一个很酷的名字,同时它有Google与k8s的强力支持,开源社区异常火爆。
Prometheus 2016年加入云原生基金会,是继k8s后托管的第二个项目,未来前景被相当看好。它和Open-Falcon最大不同在于:数据采集是基于Pull模式的,而不是Push模式,并且架构非常简单。
先来了解下Prometheus的架构设计:
Exporter:用来采集数据,作用类似于agent,区别在于Prometheus是基于Pull方式拉取采集数据的,因此,Exporter通过HTTP服务的形式将监控数据按照标准格式暴露给Prometheus Server,社区中已经有大量现成的Exporter可以直接使用,用户也可以使用各种语言的client library自定义实现。
下面是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、如果非要自研,可以多研究下主流监控系统的架构方案,借鉴它们的优势。
文章有帮助可以点个「在看」或「分享」,都是支持,我都喜欢!
我是Guide哥,Java后端开发,半个全栈,自由的少年。一个三观比主角还正的技术人。我们下期再见!
欢迎关注我的分享非技术文章的小号!