监控平台选Prometheus还是Zabbix？时常会听到很多运维伙伴在争

时常会听到很多运维伙伴在争论， Prometheus 和 Zabbix 哪一个更好?在我看来，脱离实际应用场景讨论技术的优劣其实是没有任何意义的。
文章插图
图片来自 Pexels
Zabbix 适合的监控场景
监控的维度
在选择具体的监控平台之前，我们最先需要明确，我们监控的目标是什么?在我的理解中，监控分为两个维度：即监控的广度和监控的深度。
①监控的广度
文章插图
大家所需要监控的系统少则几种，多则几十种，比如需要监控硬件、存储、操作系统、中间件、数据库及应用等。
而在每一个平台中，又存在多种平台：比如我们有华为、戴尔、惠普、IBM 的硬件服务器或者交换机，同时也会有 Windows、Linux、Aix、ESXi 等多种操作系统。
系统和平台维度的组合，意味着我们不仅仅要监控多个层级的监控，也意味着每个层级内部的需要监控的对象更精细化。因此系统异构性和平台的多样性构成了运维的复杂性。
综上，一个理想的监控平台应该支持基于各类系统，覆盖各类厂商和平台的监控。
②监控的深度
文章插图
相对的，监控目标需要考虑的另一维度是监控的深度。就监控深度而言，我们可以将其简单分成可用性监控、性能监控、日志监控和自定义监控这四大类。
可用性监控：它的状态是一个布尔型，即只有 1 或者 0 。比方说，一个服务是处于停止状态还是运行状态，一个端口是 Up 还是 Down ，根据可用性监控我们可以获知监控对象是否处于正常状态。
性能监控：是基于可用性监控的更进一步监控。比如说我们监控某个 IP 地址，在可用性监控中我们会去 Ping 这个 IP 。
如果通，就说明这个 IP 可达;更进一步， Ping 延迟就是这个 IP 的性能监控。通过性能监控，我们可以获知监控对象的健康程度以及负载水平。 CPU、内存使用率，磁盘的 IOPS ，网络的吞吐量，都是常见的性能监控指标。
日志监控：不管是可用性监控还是性能监控，都基于一定的轮询周期进行采样，在两个采样点之间的监控其实是缺失的，因此在两个采样点之间可能会遗漏一些异常监控数据。
通过日志监控，可以记录下每一个操作或者行为，确保监控的完整性。常用的日志监控会分为安全日志、系统日志、应用日志和操作日志等。
自定义的监控：顾名思义，根据我们自身的情况去定义一些符合我们监控需求的监控指标。比如订单数、网络设备流量的聚合运算等等。
一个理想的监控平台应该支持不同的监控深度和方式，从可用性监控、性能监控、日志监控到自定义监控。
监控选型
文章插图
综合监控的广度和监控的深度这两点，为我们进行监控平台的选型提供了一个思路和依据：
【监控平台选Prometheus还是Zabbix？】当我们的环境中只有 Windows 的服务器时，显然微软的 System Center 更合适，它不仅能比其他平台更快的发现问题，并有完善的知识库提供具体的解决方案。
不过，通常情况下我们的环境中还充满了网络设备、Linux、存储等其他监控对象。
这个时候使用 System Center 去监控可能就比较难以实施了，即使能实施，仍然会存在较高的成本或者技术局限性。同样 Solarwind 更加适合网络设备的监控。
那么有没有一个产品可以兼具监控的广度和监控的深度呢?经过各种评估和试用，我们认为 Zabbix 可能是在目前兼顾监控广度和深度的最合适的监控平台。
刚才也提到了 Zabbix 和 Prometheus 孰优孰劣一直是大家争议的热点，接下来我们对这两者在不同维度做一些简单的比较。
①UI 方面
Zabbix 5.0 界面如下图：
文章插图
Zabbix 一直被吐槽的最多的一点就是它的 UI 。
的确，在 Zabbix 早些的版本比如 1.8 ， 2.2 中，它的 UI 并没有那么友善和好看。
但是官方团队始终在不断迭代和完善 UI ， 5.0 的 UI 已经非常现代化，而且图形图表的展现也更丰富多彩。
同时 Zabbix 90% 以上的配置管理操作都可以通过 Zabbix 的 Web 端实现，仅有一部分基础配置需要通过配置文件处理。