作为IT工程师，我经常听到许多运维同事就Prometheus和Zabbix之间的优劣进行争论。然而，我认为，在没有考虑到实际应用场景的情况下，对技术进行优劣的讨论实际上毫无意义。
Zabbix 适合的监控场景
监控的维度
在确定选择特定的监控平台之前，首先需要明确我们的监控目标是什么。我认为监控可以从两个维度进行划分：监控的范围和监控的详尽程度。
①监控的广度
大家所需要监控的系统少则几种，多则几十种，比如需要监控硬件、存储、操作系统、中间件、数据库及应用等。
在各个平台中，包括华为、戴尔、惠普、IBM等硬件服务器或交换机，也有多种操作系统如Windows、Linux、Aix、ESXi等。
系统和平台的组合导致了运维的复杂性。这意味着我们需要在多个层级进行监控，并且在每个层级内部需要更加细致的监控对象。此外，系统的异构性和平台的多样性也增加了运维工作的复杂性。
综上，一个理想的监控平台应该支持基于各类系统，覆盖各类厂商和平台的监控。
②监控的深度
在考虑监控目标时，我们需要注意监控的深度。监控的深度可分为四个主要类别：可用性监控、性能监控、日志监控和自定义监控。
可用性监控是通过一个布尔型状态来表示，即仅有两种可能的值，1或0。举例来说，一个服务可以处于停止或运行状态，一个端口可以是开启或关闭状态。通过可用性监控，我们可以判断监控对象是否处于正常状态。
性能监控：是基于可用性监控的更进一步监控。比如说我们监控某个 IP 地址，在可用性监控中我们会去 Ping 这个 IP。
如果一个IP地址能够正常通信，这意味着它是可达的。进一步说，Ping延迟是衡量该IP性能的一种监控方式。通过性能监控，我们可以获得所监控对象的健康状况和负载水平。常见的性能监控指标包括CPU和内存使用率、磁盘IOPS以及网络吞吐量。
在日志监控中，不论是针对可用性还是性能的监控，都是通过定期的轮询周期进行采样的方式来实现的。然而，在两个采样点之间的时间段内，监控数据是缺失的，这意味着可能会错过一些异常监控数据。
通过日志监控，我们可以记录下每一个操作或行为，以确保监控的完整性。常见的日志监控包括安全日志、系统日志、应用日志和操作日志等。作为IT工程师，日志监控是一项重要的职责，它能帮助我们追踪和解决问题，并确保系统的稳定性和安全性。
自定义的监控：顾名思义，根据我们自身的情况去定义一些符合我们监控需求的监控指标。比如订单数、网络设备流量的聚合运算等等。
一个理想的监控平台应该支持不同的监控深度和方式，从可用性监控、性能监控、日志监控到自定义监控。
监控选型
综合监控的广度和监控的深度这两点，为我们进行监控平台的选型提供了一个思路和依据：
当我们的环境只使用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的Web界面可以实现超过90％的配置管理操作，仅有少部分基础配置需要通过配置文件完成。作为IT工程师，您可以通过Zabbix的Web界面轻松管理配置操作，并在需要时使用配置文件进行基础配置。
这样有一个很大的好处：所有的维护都会有统一的入口，而且只要通过简单的点击、拖拽操作就可以完成，大大提升了运维团队的效率。
Prometheus界面如下图：
Prometheus的用户界面功能相对较简单，提供了类似于SQL查询的界面，使用户能够轻松地查询一些指标。然而，在实际使用中，更多的人选择使用Grafana作为Prometheus的前端界面。
Zabbix 本身也可以把 Grafana 作为前端，但就原生的 UI 进行对比，Prometheus 稍微简单了点。
Prometheus主要通过配置文件来进行操作和维护，具有高度的可扩展性。然而，对于大规模监控对象的维护，必须依赖于第三方的配置管理工具，这在运维方面增加了一定的复杂度，相较于Zabbix而言。
②架构方面
Zabbix 架构图如下：
Zabbix 是一个分布式的监控系统。在很多公司内部，尤其是金融机构，会存在多个网络区域，每个区域之间进行了隔离。
为了实现监控数据的集中收集，Zabbix提供了Zabbix Proxy作为代理服务器部署在每个网络区域中。Zabbix Proxy的主要作用是收集当前区域内的监控对象的监控数据。
Zabbix Proxy与Zabbix Server建立通信连接，以便将收集到的数据传递给Zabbix Server以便进行后续处理，例如触发警报。
我们还将Web端部署至用户可访问的区域，这样一来，用户便能在正常的办公环境中而非机房中访问Zabbix，从而获得以下优势。
使用一种代理（one proxy）或者 mycat 方式来提高 Zabbix 使用的数据库的高可用性，并确保数据库的主从分离。作为一个IT工程师，这一措施将有效地增加系统的稳定性和可用性。
这种架构的好处在于从库作为读库提供给其他系统访问，比如 CMDB 或者报表系统，同时不会影响主库的性能。
因为Zabbix的各个组件已经进行了分离，所以在防火墙上只需要打开必要的网络通路，无需暴露所有监控主机的端口，这样可以提高安全性。
Prometheus 架构图如下：
总体而言，Prometheus 的架构和 Zabbix 有很多相似之处：
- Prometheus 使用各种 Exporter 进行监控，Exporter 的功能类似于 Zabbix 的 Agent，负责收集监控对象端的数据。
- Prometheus 的 AlertManager 类似于 Zabbix 的 Action，可以进行报警触发，比如发送短信和邮件。
Prometheus和Zabbix在使用的数据库类型上有区别。具体来说，Prometheus使用的是TSDB（时序数据库），而Zabbix使用的是关系型数据库，例如MySQL或PgSQL。
TSDB 在存储监控的性能会优于传统关系型数据库，因此 Zabbix 也开始尝试性的支持 TSDB 作为后端的数据存储。
在进行监控平台选型时，需要对数据库是否成为监控瓶颈进行评估。如果性能和压力还没有成为监控平台的瓶颈，那么TSDB时序数据库的优势可能不太明显。
上述内容对比了 Zabbix 和 Prometheus 在几个不同方面的特点。希望这些对比能够为大家在选择监控平台时提供一些参考依据。
由于需要监控多种设备和平台, 在我们的环境下选择了Zabbix作为统一监控平台。依靠Zabbix的特性，我们成功地提升了自动化监控的水平。
③Zabbix 的高级特性
在软件领域中，许多开源软件都存在商业版和社区版的区分，例如MySQL和Puppet等。商业版本需要付费，但也提供了更全面和高级的功能。这些开源软件可以免费获取，并且拥有一个庞大的社区支持系统。
Zabbix是一个开源的IT监控解决方案，没有商业版和社区版之分。官方定期更新版本，每个新版本都会修复问题并改善用户体验。
Zabbix 不仅由原始开发团队提供支持，还有社区提供支持。在中国，Zabbix 社区非常活跃，每年还会举办定期的 Zabbix 大会等活动。
分布式，高可用：Zabbix 本身也是分布式高可用的，这也很好的解决了单点的问题。
低级别发现，自动发现：这是 Zabbix 全栈自动化监控中最不可或缺的两个特性。
低级别发现：低级别发现能帮助我们发现一台设备上所有的监控对象。
试想一个场景，我们有 100 台服务器，每台服务器上至少有 2 块硬盘，最多有 20 块硬盘。
如果我们要监控这些磁盘的 IOPS、剩余磁盘空间 1、磁盘队列长度等 10 个指标，需要怎么去添加监控?
按照行业标准，我会在每台服务器上为实际磁盘数量设置监控。假设每台服务器平均有10个磁盘，那么就要添加100*10*10个监控项，总计10,000个监控项。
不止于此，还要继续为这 10000 个监控项配置触发器和告警规则。
在Zabbix中，我们需要创建一个模板，并定义适用于低级别发现的规则。然后，我们将该模板与需要监控的100台服务器进行关联。
Zabbix系统会根据服务器上实际的磁盘数量自动创建相应的监控项，从而显著提高了监控添加的效率，并减少了手动添加监控时可能出现的错误。
自动发现：它能帮助我们快速发现网络内的设备，并按规则识别出它的类型，将其和指定的模版进行关联。
全栈级监控：就像刚才所介绍的，Zabbix 在监控的广度和深度之间做了一个比较好的权衡，它是一个全栈级的监控平台。
从底层的硬件、操作系统、中间件、数据库，到上层的应用、业务，都可以纳入到 Zabbix 的监控范围中。
我们成功地开发了一个统一的监控平台，能够满足不同层次监控需求并降低维护多个监控平台的成本和所需的专业知识。这个平台更易于上手使用，并覆盖了所有监控对象。
作为IT工程师，我可以提供一个更专业的表述方式： Zabbix是一个灵活的系统，可以进行定制化，并且与DevOps流水线无缝集成。它提供了丰富的API，几乎涵盖了界面上的所有功能，可以与企业内部的DevOps持续交付流水线进行集成，从而提高整体自动化水平。
Zabbix 全栈自动化监控实践案例
接下来，我们来讨论下 Zabbix 这些高级特性在实际使用场景中的最佳实践案例。
分布式自动化监控
首先来看下我们是如何通过自动发现特性实现监控的自动添加的：
作为IT工程师，我们将使用Zabbix来配置自动发现规则，通过扫描特定网段来检测。一旦我们发现某个IP在该网段上的1433端口开放，我们可以根据情况合理推断该IP上可能正在运行微软的SQL Server服务。
因此，我们通过已经配置好的规则，将发现的这个开放着 1433 端口的 IP 和 SQLServer 模版进行关联。
SQLServer 的模版是我们预先定制好的对于微软数据库的监控模版，通过自动发现，我们能达到两个目的：
- 所有的微软数据库都被监控到了。
- 所有被监控的数据库使用了同一套监控基线，实现了标准化监控。
同样的，我们也可以通过定制不同的规则，来添加不同类型的监控，比如 3306 是 MySQL 的监控等。
除了关联模版，我们会把监控对象添加到不同的组中，确保每个组关联了对应的运维人员。
这样做的好处在于，我们不需要频繁的更新告警策略，而当故障发生的时候，对应的管理员也能第一时间收到告警。
双维度管理(平台维度/业务维度)
刚才提到了组的概念，我们在实际应用中，一个监控对象属于两个组，即一个 P 组(平台组)和一个 S 组(业务组)。
在组织中，IT运维人员和业务人员之间存在一定的视角差异。为了满足不同的需要，通常组织会雇佣不同角色的专业IT人员，如Windows管理员、Linux管理员和数据库管理员等。
DBA 会负责所有数据库相关的运维工作，而且不在乎这个数据库属于那个应用系统。
因此所有的数据库服务器，比如所有的 MySQL，都会放到一个叫做 P-DB-MySQL 的组中。
这个组所有的告警会发送给指定的 DBA 而不是 Windows 管理员，同时会和对应的 MySQL 监控模版进行关联。
这样做的收益在于 DBA 只会收到他们所负责系统的告警，同时监控也实现了标准化。
IT工程师负责确保企业的技术基础设施正常运行，包括硬件、网络和软件系统。与此相反，业务人员则关注整体业务应用的正常运行情况。举例来说，我们可以考虑一个登陆系统，其前端使用Tomcat中间件进行操作，用户登录信息存储在MySQL数据库中，而底层则运行着一台HP服务器。
那么我们会把这三个监控对象放在一个叫做 S-Department1-Login 的组中。
这样做的好处在于，一旦一个监控对象出现任何问题，我们可以第一时间知道它影响什么系统。
通过将P组和S组结合，我们能够同时确保不会遗漏任何监控告警，同时最大限度地减少监控噪音的影响。此外，我们还能够清晰地了解当前问题对哪些业务造成了影响。
告警方式
Zabbix 支持非常多的告警方式，这点类似于 Prometheus 的 AlertManager。
我们将首先根据报警级别对其进行分类，Zabbix系统提供了5个级别的告警，分别是Disaster（灾难级别），High（高级别），Warning（警告级别），Average（一般级别）和Info（信息级别）。
我们使用了其中的三种，并给出了这三种级别告警的定义：
- Disaster：触发后需要立即处理，如不处理会直接影响生产系统的告警。
- Warning：触发后需要尽快处理，短期不处理不会直接影响生产系统。
- Info：提示性的告警。
不同级别的警报将配备不同的策略进行处理，例如，Disaster级别的警报将通过邮件发送给负责IT和系统管理员的人员；Warning级别的警报仅发送给系统管理员；Info级别的警报不会发送警报，而是在监控屏幕上显示。
具体的告警分级和策略可以根据企业内部的实际情况和监控需求进行定制。
对于告警的呈现方式，主要有邮件、短信和监控大屏等几种，多渠道的告警确保了我们的告警不会被遗漏。
我们将对报警内容进行定制，以包含更多详细信息，如报警状态（Problem或OK）、具体问题、问题服务器和IP、问题值等。
另外，我们将在信息中添加该警报所对应系统的负责人姓名和联系方式，在处理故障时，我们的7x24小时运维中心（NOC）可以立即联系到相应的运维人员，以减少故障处理时间。
在我们的监控大屏上，系统状态会实时显示，并清晰标明所有问题的详细信息。我们使用红色标示表示Disaster级别报警，黄色标示表示Warning级别报警。
持续集成/持续交付
在之前的演讲中提到了Zabbix提供了API。我们已经将Zabbix的API整合到了DevOps的持续交付流程中。
在软件开发中，持续集成平台 Jenkins 通过与版本控制系统 Git 的集成，拉取代码并进行构建。同时，通过使用配置管理工具如Ansible来进行应用发布。在应用发布的过程中， Jenkins 会调用 Zabbix API 将相关的主机设置为维护模式，以减少应用发布时的监控日志记录。这样做可以避免监控系统在应用发布过程中发出的噪音信号。
Zabbix还能通过收集基础信息，向CMDB配置管理数据库提供数据。当发生告警时，可以调用微信、邮件等平台的接口来触发告警。通过与其他平台的集成，可以形成一个完整的持续交付闭环。
自动化带外管理
当物理服务器数量大幅上升后，硬件巡检问题是最烧脑的难题。硬件故障存在着随机性。
在大多数组织中，硬件问题通常通过定期的人工巡检来观察和排除。然而，一些组织采用了服务器自带的带外管理平台，例如HP的iLo、华为的iBMC和戴尔的iDrac等平台来进行远程管理。
当一个机房里面有多种服务器的时候，如果只是依靠这些平台，除了昂贵的 License 授权，管理成本也非常高昂。
即使这些问题解决了，那么那些只支持 SNMP 的网络设备、存储怎么办呢?
来看看 Zabbix 是如何解决的：
- 我们将 Zabbix 部署在带外管理网络中，这个网络会有一台 DHCP 服务器自动为所有的设备分配 IP 地址。
- Zabbix 在这个带外网络中会有一台 Proxy 代理服务器，通过 Zabbix 的自动发现功能，将所有的带外地址增加到 Zabbix 中;通过 IPMI 或者 SNMP 的标准协议套用监控模版，实现统一监控。
- 收集到的带外数据可以作为 CMDB 配置管理数据库中重要的硬件信息。
通过 Zabbix 的带外管理大大节约了带外管理平台的授权费用，也降低了带外管理的成本，实现了统一带外管理的目标。
以上就是 Zabbix 在落地过程中的案例和最佳实践。
总结
如何选择监控平台
如果我们只是在 Prometheus 和 Zabbix 中选择，应该如何选择一个合适的监控平台?
我的建议是：
- 当环境是一个纯容器的环境，毫无疑问 Prometheus 是更适合的选择，Prometheus 是天生为容器化平台打造的监控系统。
- 而当我们环境很复杂，有各种操作系统、硬件、中间件、数据库等，那么 Zabbix 是更适合的监控平台，Zabbix 兼顾了监控的深度和广度，实现了统一监控平台的目的。
- 当整个环境中又有容器、又有其他的系统，而又希望之用一套监控系统，那么 Zabbix 更合适，因为 Zabbix 的最新版本中已经强化了容器化监控的功能。
- 当然，有余力的话，也可以使用两台监控系统互相补足。
使用 Zabbix 的收益
Zabbix 有简单易用的 UI，自带的 Graph 和 Screen 也可以满足企业级的展现需求。
90% 以上的配置可以通过 Web 端统一操作和实现，这一点比强依赖于配置文件的 Prometheus 要更为方便。
如果对于Zabbix的原生用户界面不满意，可以采用与Prometheus类似的方式，将Grafana接入其中，从而显著降低二次开发的成本。
基于平台组和业务组的双维度分组，也使得 Zabbix 可以在同一组织内为不同团队提供更个性化的展现。
Zabbix 的开源、免费等特性使得越来越多的企业，尤其是自研能力不是那么强的中小企业快速实现全栈级监控。
Zabbix几乎涵盖了80%乃至更多的监控需求，并且其高级特性有效地减少了人工干预，提高了自动化能力，同时还能与其他系统和平台进行持续集成。
有兴趣的朋友可以一起来探讨一下。
