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

Warning：触发后需要尽快处理，短期不处理不会直接影响生产系统。

Info：提示性的告警。

不同级别的报警会对应不同的策略，比如 Disaster 告警会发送给 IT 负责人和系统管理员;Warning 告警只会发送给系统管理员;Info 不会发送告警，但会在监控大屏上展现。
具体的告警分级和策略可以根据企业内部的实际情况和监控需求进行定制。
对于告警的呈现方式，主要有邮件、短信和监控大屏等几种，多渠道的告警确保了我们的告警不会被遗漏。
同时我们也会对报警内容进行精细化的定制，包含报警状态(Problem 或者OK)、具体的问题、出现问题的服务器和 IP、问题具体的值等信息。
此外，我们还会在内容中补充该告警对应系统负责人姓名和联系方式，方便我们 7x24 小时的 NOC 第一时间联系到相应运维人员处理故障，降低故障时间。
在我们的监控大屏上，也会展现出当前每个系统状态，并显示出具体的问题有哪些，用红色标示出 Disaster 级别报警， Warning 级别的则是黄色。
持续集成/持续交付

文章插图
在前面的分享中提到了 Zabbix 提供了 API 。基于 Zabbix 的 API ，我们将其融入到了 DevOps 的持续交付流水线。
当持续集成平台 Jenkins 从版本控制系统 Git 上拉去代码进行构建后，通过 Ansible 等配置管理工具进行应用发布的同时，会调用 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 的原生 UI 不满意，仍然可以和 Prometheus 一样，接入 Grafana ，大大降低了二次开发的成本。