最近几年一直在使用监控系统，主要使用Zabbix和Prometheus 两个监控工具，对于这两个监控系统有一些使用实践方面的经验，通过对比的方式来和大家分享一下。
一、Zabbix 和 Prometheus 的出现和发展
Zabbix 和 Prometheus 都是监控系统中很流行的工具，Zabbix 的出现要更早一些，在 2001 年的时候发布了 0.1，彼时时序数据库还没有应用在监控领域，Zabbix 基于当时的环境采用了关系型数据库来存储数据。
最早的时序数据库 RRDTool 出现于 1999 年 7 月 16 日，Influxdb 在 2013 年 10 月 24 日发布了 0.0.1 版本，Prometheus 于 2014 年 3 月 13 日发布了 0.1.0 版本 ，直到 2016 年，时序数据库彻底火了起来。
现在 Zabbix 按照每 6 个月一个稳定版本，每 2 年一个大版本的节奏在逐步发展，当前是 5.x 版本，6.x 版本也在规划中了。
Prometheus 按照每 6 周一个小版本的迭代在逐步前进，目前已经在 2.X 时代，最新版本是 2.30.0。
站在当前这个时间节点，Prometheus 即将发布 2.31.0 ，Zabbix 也已经发布了 5.4.0 。Zabbix 看到了时序数据库在监控领域的前景，在 5.x 开始支持使用时序数据库来存储数据，并且在 4.4 的时候就支持收集 Prometheus 的 数据存储在自己的关系型数据库中。Zabbix 站在企业级监控系统的角度，开始支持包含各种监控工具，进一步向一个臃肿的大而全的系统演进，并且开始小范围的尝试新的技术。Prometheus 按照自己最初的设计，只做监控，其他部分交给更专业的人来做，基于时序数据库，基于 Golang，不断优化，提高性能。目前来看，Prometheus 基本已经是云原生监控系统的事实标准，最佳选择。Zabbix 扎根企业市场以功能大而全的优点毅力不倒。
二、 Zabbix 和 Prometheus 的优缺点
最近在使用Zabbix 时被同事写的一个接口调用的bug导致Zabbix 的主机信息、模版信息、以及他们的关联关系全丢了，因为配置了自动注册，在这些数据丢失以后，Zabbix Agent 又把自己注册了一次，然后通过备份数据恢复的时候这两部分就发生了冲突，一个表一个表的解决问题。恢复好以后，这个事情又发生了一次。不同的是，第一次恢复紧急恢复花费了一晚上十几个小时的时间，全部恢复大概花了一周时间，第二次全部恢复花了两个小时。
另外的一个事情就是Zabbix Server版本升级，由于一些安全原因和实际碰到的 BUG，我们决定对 Zabbix Server 进行版本升级。仅仅是从 4.4.0升级到4.4.10花费了大约一周时间，各种测试，各种升级回滚解决问题。当然这也和当前的部署结构有关系，结构不合理，负载不均衡等等。
这个月主要就耗费在这里了。
针对 Zabbix 总结一下，有以下的优点：
1、监控模版可以包含多个指标，在不涉及自定义采集脚本等其他方式的情况下，使用SNMP、Zabbix Agent 的情况下可以做到开箱即用；
2、指标和触发器（Zabbix的告警规则叫触发器）的关联交互挺好用；
3、宏和宏变量的使用可以大大的提高告警的便捷性，基本可以做到每个label 不同的阈值；
4、Zabbix 的指标采集挺丰富的，包括采集间隔，是否要一直采集还是每天固定时间段来采集；
5、Zabbix 的管理页面，这个不愧是企业级软件，Zabbix 很大一部分的优势是靠它来体现的。
说完了优点来看看缺点：
1、Zabbix 架构原生是单点，没有集群方案，官方推荐的是使用keepalived 来进行3个点的负载均衡，这个方案在现在来说还是有很大的优化空间的。
2、Zabbix 的数据存储使用关系型数据库，在 Zabbix 刚发布的时候，这个没的选择，但放在现在这是个很大的问题，当指标数量增加以后，数据的存储空间、查询时间都变成了一个恐怖的事情。当前使用了6TiB的空间来存储了每帧80万条数据，采集间隔一分钟，详细数据1个月，历史数据大概1年半的数据，Prometheus 存储比这个节省多了。当然zabbix 也可以支持更大的数据收集规模，只是不知道资源会按什么比例增长。
3、升级复杂，体验了4.4.0升级到4.4.10以后，升级太麻烦，使用Zabbix 你的团队最好配置一个DBA 来处理各种问题。
4、Zabbix 和 Grafana 的结合不太好，语句写起来挺生硬的，也能用，但是不如Prometheus 灵活。
对于prometheus 这个月我也做了例行升级，大概花了一个小时左右，我升级完了十多个实例，配套的Thanos 和存储数据的Minio。和Zabbix 相比，这太让人舒服了。
Prometheus 具备以下优点：
1、结构简单，但是可以水平扩展，通过和thanos 结合可以做到无缝的水平扩展。不喜欢thanos 也可以使用自带的联邦功能进行扩展，Prometheus 的思想就是：我尽量简单但是好用，剩下的功能尽管放给其他人做
2、采用时序数据库，大大的节省了存储空间，并且提升了查询效率。我使用3TiB 的空间存储了每帧300万条数据，30秒采集一次，大约有120万条数据是15秒采集一次，详细数据存2个月，5分钟降准数据存半年，一小时降准数据存一年，而且我还不需要DBA 参与。
3、采集配置简单，简单配置以后就可以收取丰富的指标，不用自己一个指标一个指标的添加。
4、原生支持收集很多服务暴露的监控数据，Zabbix 很难收集应用自身提供的监控数据。
对于Prometheus 的缺点，
1、当前告警规则无法快捷的支持每个label 一个阈值，要么统一阈值，要么一个label 一条规则，量大了以后真的不好管理。大家如果这方面有什么好的办法还请指导我一下。
其他感觉和zabbix 比起来没啥缺点了。
另外有一个不同点就是，当采集内容较多的时候会出现一个机器上有多个 Agent 的问题。对于这个方面来说，Zabbix 只有一个 Agent ，但是很多内容需要自己编写采集脚本，Agent 还是比自己编写脚本的可靠性更高一些。另外对于单节点多 Agent 来说，Prometheus 也有对应的解决方案。
三、Zabbix 和 Prometheus 的适用场景
在使用Zabbix 和 Prometheus 的过程中，曾经将 Zabbix 和 Prometheus 放在各种场景下进行过使用，比如单个集群、多个集群、超级集群、企业业务环境等等场景。
我们先来看看集群环境。
对于单个中小规模的集群（500或者 1000 节点以下）来说，使用Zabbix 和 Prometheus 没有什么差别，无论使用哪种工具，做好规划和设计，使用起来基本没有问题，单机的资源使用、数据库的压力、场景的复杂度，都不是太大的问题。随便使用就好。
对于多集群来说，我们需要考虑 Master 节点的资源使用情况、数据库的压力承载情况、集群扩展的方便性。对于 Zabbix 来说，当节点数量直线上升的时候，Master 的压力会一直增大，对于单点 Master 的配置要求越来越大，当数量达到一定规模以后，单点就无法支撑这个规模的系统，然而官方也没有提出很好的集群方案。另外当节点规模增大以后，数据库的压力会变大，监控数据的查询会变的很慢，数据库会变成一个集群来解决遇到的问题，硬件资源的成本会直线上升。对于集群扩展来说，Zabbix 可以基于自动注册和 Proxy 来实现，但是数据是采取 Agent 到 Server Push 回来的，当你想要摘除一个被监控集群的时候操作很繁琐。
对于Prometheus 来说，在多集群的时候，可以每个集群使用一个 Prometheus ，通过 Thanos 来进行汇总，水平扩展特别方便，也不会有单点压力很大的情况，而且可以通过 Label 来区分不同的集群，单点Server 承载节点的能力比Zabbix 强很多。而且 Prometheus 使用时序数据库来存储监控数据，可以用很少的硬件资源提供更强的查询能力。Prometheus 使用 从 Server 到 Agent 拉取的方式获取数据，可以在 Server 端很轻易的操作采集那些节点，放弃某些节点的采集。
对于单集群超过 5000 节点的超级集群，建议直接使用 Prometheus ，可以不用 Zabbix 了，性能差太多。在不考虑冗余的情况下，Prometheus 单点就可以支持 5000 节点存储 1 个月的监控数据，Zabbix 使用同配置的机器至少要 3~4 台机器才能实现相同的效果。而且 Prometheus 相较 Zabbix 维护简单，使用方便。
对于企业的业务环境来说，超过 2000 台节点、业务服务数量大于 1000 个的时候建议直接上 Prometheus 。这个时候是需要一个完整的监控观测系统，需要和 Grafana、Kafka、Redis、MySQL等等中间件和各种系统进行结合、直接获取服务自身暴露的监控指标，在这种场景下，Prometheus 是最适合的。Zabbix 和其他中间件的结合较差，完全依赖自定义脚本来实现，没有依托社区的力量。
四、小结
对于 Zabbix 和 Prometheus 的选取主要看自己的使用场景，Zabbix 和 Prometheus 都有大规模使用的场景，在使用过程中选取适合自己的才是最好的。
对于 Zabbix 和 Prometheus 我也在持续的使用，很多新的特性和功能也在持续探索验证当中，如果有新的发现也会和大家分享
