设备监控平台设备监控软件( 二 ) _设备

①UI 方面
Zabbix 5.0 界面如下图：
Zabbix 一直被吐槽的最多的一点就是它的 UI 。
的确，在 Zabbix 早些的版本比如 1.8，2.2 中，它的 UI 并没有那么友善和好看。
但是官方团队始终在不断迭代和完善 UI，5.0 的 UI 已经非常现代化，而且图形图表的展现也更丰富多彩。
同时 Zabbix 90% 以上的配置管理操作都可以通过 Zabbix 的 Web 端实现，仅有一部分基础配置需要通过配置文件处理。
这样有一个很大的好处：所有的维护都会有统一的入口，而且只要通过简单的点击、拖拽操作就可以完成，大大提升了运维团队的效率。
Prometheus界面如下图：
Prometheus 的界面相对比较基础，提供类似 SQL 的查询界面，可以简单查询某些指标。大家更常用的是 Grafana 作为 Prometheus 的前端。
Zabbix 本身也可以把 Grafana 作为前端，但就原生的 UI 进行对比，Prometheus 稍微简单了点。
同时，Prometheus 绝大多数的操作和维护都通过配置文件进行。对上大批量监控对象的维护，必须要依赖于第三方的配置管理工具，因此运维复杂度会比Zabbix更高。
②架构方面
Zabbix 架构图如下：
Zabbix 是一个分布式的监控系统。在很多公司内部，尤其是金融机构，会存在多个网络区域，每个区域之间进行了隔离。
Zabbix 支持在每个网络区域内部署一个 Zabbix Proxy，即 Zabbix 的代理服务器，这个服务器的职责是收集当前区域的监控对象的监控数据。
同时 Zabbix Proxy 会和 Zabbix Server 打通，把收集到的数据提供给 Zabbix Server 进行后续处理，比如触发告警。
我们也会把 Web 端部署在一个用户可以访问的区域，这样做的好处是用户可以在正常的办公环境而不是机房中访问 Zabbix 。
对于 Zabbix 使用的数据库，使用 one proxy 或者 mycat 方式，能够提高它的高可用性，同时也确保数据库的主从分离。
这种架构的好处在于从库作为读库提供给其他系统访问，比如 CMDB 或者报表系统，同时不会影响主库的性能。
由于 Zabbix 各个组件进行了分离，防火墙上只需要打通一些必要的网络通路，不需要把所有监控主机的端口都像 Zabbix Server 暴露，从而提升了安全性。
Prometheus 架构图如下：
总体而言，Prometheus 的架构和 Zabbix 有很多相似之处：

Prometheus 使用各种 Exporter 进行监控，Exporter 的功能类似于 Zabbix 的 Agent，负责收集监控对象端的数据。
Prometheus 的 AlertManager 类似于 Zabbix 的 Action，可以进行报警触发，比如发送短信和邮件。

存在不同的一点是：Prometheus 使用的数据库是 TSDB 时序数据库，Zabbix 使用的是 MySQL 或者 PgSQL 的关系型数据库。
TSDB 在存储监控的性能会优于传统关系型数据库，因此 Zabbix 也开始尝试性的支持 TSDB 作为后端的数据存储。
在监控平台的选型时，也需要评估数据库是否是监控的瓶颈，当性能和压力尚不能成为监控平台的瓶颈时，TSDB 时序数据库的优势并不会十分明显。
以上是 Zabbix 和 Prometheus 在不同几个方面的对比，那也希望这些对比能为大家在监控平台选型时，提供一定的参考依据。
在我所处的环境中，由于我们需要监控很多不同类型的设备和平台，因此选择了 Zabbix 作为统一监控平台。依托 Zabbix 的一些特性，也大大提升了自动化监控的水平。
③Zabbix 的高级特性
开源免费，社区支持：很多的软件虽然开源，但会有商业版和社区版区分，比如 MySQL、Puppet 等。商业版本会要求用户付费，但同时会提供更完善和更高级的功能。