用什么监控我们的容器?

用什么监控我们的容器?

本文介绍常见监控工具 zabbix 和 prometheus 的主要特点以及应用于容器监控时各自的优缺点，希望能够帮助同学们选择适合项目的监控工具。

说明：本文介绍的两个工具 zabbix 和 prometheus 都是开源、免费的。

Zabbix 的主要特点

作为老牌监控工具，zabbix 历史悠久，功能全面且强大。下面罗列一些它的主要特点：

数据收集方式灵活全面

支持可用性和性能检查

支持 SNMP(包括主动轮训和被动获取)，IPMI，JMX，VMware 监控

支持自定义检查

按照自定义的间隔收集需要的数据

支持 server/proxy+agents 的模式

自动发现监控对象

自动发现网络设备

监控代理自动注册

发现文件系统，网络接口等等企业部署

高度可配置化的报警

支持收敛的报警策略

可以使用宏变量让报警通知更加高效

在报警的同时可以执行应对策略

强大的模板功能

在模板中分组检查

模板可以关联其他模板

完善的权限管理系统

安全用户认证

特定用户可以限制访问特定的视图

近乎无限的扩展能力

支持通过脚本进行扩展

看一眼 zabbix 提供的菜单感受下它的丰富功能：

Prometheus 的主要特点

Prometheus 是一个开源的系统监控和警报工具包，许多公司和组织都采用了 Prometheus，该项目拥有非常活跃的开发人员和用户社区。下面是 prometheus 的一些主要特点：

多维度数据模型

灵活的查询语言

不依赖分布式存储，单个服务器节点是自主的

通过 pull 方式采集时序数据

可以通过中间网关进行时序列数据推送

通过服务发现或者静态配置来发现目标服务对象

支持多种界面展示方案，比如 grafana 等

事实上，业界多把 prometheus 用于容器监控的解决方案，比如与 k8s 的集成。使用 cadvisor + prometheus + grafana 搭建容器监控事实上已经成为了中小企业的首选方案。下图是由 grafana 展示的单台主机上运行容器的汇总信息(当然，数据源来自 prometheus)：

其实，prometheus 的扩展性也很好，通过扩展不同的 exporter 可以收集不同应用、设备的信息。

使用 zabbix 监控容器的缺点

Zabbix 的功能非常全面，以至于仅仅用它来监控容器让我们觉着是大材小用了，同时也难免会觉着它不太专业(就监控容器来说)。

事实上 zabbix 监控容器的能力一点也不弱，特别是从版本 4.2 开始，zabbix 也支持 prometheus 做为数据源了。这样一来，zabbix 也就是在视觉展示上比 grafana 差些罢了。

当然 zabbix 还有其它一些问题，比如功能过多(优点有时候也会变成缺点)，如果仅仅需要容器监控功能，会觉着 zabbix 用起来太繁琐了。

Zabbix 使用的是 mysql 数据库，对于时序型的数据，性能上肯定没法和专门的时序型数据库相比。

最后，zabbix 的安装和配置虽然不是很难，但离开箱即用还是有段距离的。

使用 prometheus 监控容器的优缺点

Prometheus 和 zabbix 比起来就轻多了，它就是为容器监控而生的。特别是它使用的是时序型的数据库，对于监控类的场景而言性能非常好。

Prometheus + grafana 做出来的视觉效果非常的棒：

并且多数情况下你都不需要自己动手设计这些图表，下载大家做好的模板，直接就能用，效果棒棒的！

但与 zabbix 相比，grafana 的报警功能却不够灵活。
关于监控信息的收集，zabbix 支持 pull/push 两种模式，而 prometheus 只支持 pull 模式。关于 pull/push 模式，大家的关注点似乎都在性能上。而对于我管理的较小的系统来说基本上没有性能问题，我更关注的是安全性。使用 pull 模式，需要生产环境对外暴露端口号，我们需要为此提供安全性相关的配置，而使用 push 模式则没有这个问题(其实是需要提供监控服务器端的安全配置)。

结论

不管是 zabbix 还是 prometheus 都能够完成容器监控的任务。Zabbix 大而全，[Zabbix]在传统的监控领域依然是主流的解决方案。而 prometheus 作为一个轻量级的后起之秀，在性能和展示方面优势比较明显，对容器监控支持的非常好。个人认为，在中小企业中搭建 zabbix 监控平台是非常必要的，它能把大大小小、各式各样的设备管理起来。而对于那些运行在云端的容器，选择 prometheus 搭建独立的监控系统会是个不错的选择。