为什么我们放弃Zabbix采用Prometheus？

2017 年以前，我们运维体系的监控主要还是以 Zabbix 作为主流的解决方案。当时数据库这部分的监控服务也是使用的监控运维团队提供的服务。

图片来自 Pexels

总体来说，Zabbix 的功能还是非常强大的，而且使用也比较简单，基本上写写脚本就能实现指定应用的监控。

PS：目前已经不是 Zabbix 了，运维团队基于 Open-Falcon 定制开发了一套统一的运维监控系统，当然这是后话了。

我们在 2016 年就已经尝试 MySQL 的容器化，2017 年开始大规模应用。容器化以后 MySQL 数量大幅度上升，通过平台化进行管理。

原来使用的 Zabbix 已经无法满足需求：

• 监控指标太多，如果都接入到 Zabbix，服务器无法承受(当时的服务器资源情况下)。
• 数据库运维平台对监控告警的管理需要联动处理。
• 数据库运维平台上实例增删时需要监控系统自动发现实例。
• 有趋势预测、数据快速统计的需求。
• 对监控指标画图有自定义的需求。

所以我们 DB 团队内部想选型一款监控系统来支撑以上需求。

技术选型

关于数据库的监控，我们并不想投入太多人力去维护，毕竟监控系统不是我们的主要工作。

所以需要选一款部署简单、服务器资源占用低、同时又能结合告警功能的监控系统。

虽然目前开源的监控系统还是有不少的，但是最终评估下来，还是选择了更轻量化的 Prometheus，能够快速满足我们数据库监控的需求。

①易用性

二进制文件启动、轻量级 Server，便于迁移和维护、PromQL 计算函数丰富，统计维度广。

②高性能

监控数据以时间为维度统计情况较多，时序数据库更适用于监控数据的存储，按时间索引性能更高，数百万监控指标，每秒处理数十万的数据点。

③扩展性

Prometheus 支持联邦集群，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 Prometheus Server 处理的任务量过大时，通过使用功能分区(Sharding)+联邦集群(Federation)可以对其进行扩展。

④易集成性

Prometheus 社区还提供了大量第三方实现的监控数据采集支持：JMX，EC2，MySQL，PostgresSQL，SNMP，Consul，Haproxy，Mesos，Bind，CouchDB，Django，Memcached，RabbitMQ，Redis，Rsyslog等等。

⑤可视化

自带了 Prometheus UI，通过这个 UI 可以直接对数据进行查询。结合 Grafana 可以灵活构建精美细致的监控趋势图。

⑥强大的聚合语法

内置查询语言，可以通过 PromQL 的函数实现对数据的查询、聚合。同时基于 PromQL 可以快速定制告警规则。

实践

监控的目的

在做监控系统之前，首先我们要明确监控的目的。

在总结相关内容的时候，正好在网上看到了 CNCF 基金会 Certified Kubernetes Administrator 郑云龙先生基于《SRE：Google 运维解密》对监控目的的总结，总结很到位，所以就直接引用过来了。

引用