从Zabbix到Prometheus

跟同行谈起智能运维和企业级监控系统，不可避免的谈到了技术路线的选择。时下最流行的开源监控技术路线无非是 zabbix和prometheus，其实这两个方向孰好孰坏，还真不好用一两句话去说明白，好吧，那干脆咱们就用十句八句去聊聊这个话题，以备咨询。

一、智能运维必须从监控谈起

我们现在基本有一个共识，智能运维也好AIOps也罢，我们对运维的美好憧憬，都建立在监控的基础上。兵法有云，知己知彼百战不殆。连运维对象的情况都不能及时准确的了解，还谈什么运维，谈什么智能，还不如回到石器时代好。

我们现在谈监控，更多指的是全要素监控，也就是从机房的风火水电到物理服务器、到虚拟化和云平台再到PaaS层、再到应用和数据都要实现统一的监控和管理。过去单一模式下的粗放式监控已经不能满足业务运营的需要。当然现在笼统的要求实现统一视图的下的监控融合，也存在很多困难，也需要一步一步来。在这样的大背景下，越来越多的互联网金融和运营商等行业客户开始依托开源组件构建自己的监控系统，以达成上述目的。zabbix和prometheus就进入了我们的视野。

二、萝卜白菜各有所爱

现在的大形势下，我们去做这样一个监控系统的技术选型，势必会去深入比较这两种技术路线的优缺点，我们稍微打开一下看看：

1、革命家史：

1）prometheus：

Prometheus则是Google开源的。主要包括开源监控报警系统和时序列数据库。2016年，CNCF将Prometheus纳入开源体系，目前开源社区也十分活跃，凭借跟同门师兄Kubernetes的关系，后面在云原生领域会有好的协作。

2）zabbix：

zabbix差不多是2012年发布的，比prometheus早年。思路上也更传统一些，应用的比较广泛，算是是主流的企业级分布式开源监控方案。

2、架构上的差异

1） Prometheus更主动，以拉为主： 的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。

2） zabbix是典型的的C/S架构 ： 核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy。Server主要负责接收Agent发送的监控信息，并进行汇总存储，触发告警等。

3、几个关键差异

1）开发语言：Prometheus出现较晚，语言更倾向于更灵活的go语言，轻量化更敏捷。zabbix采用C，更厚重，不对应该是跟笨重；

2）系统成熟度：这个显而易见，Prometheus出现的更晚，虽然在容器监控层面更有优势，但还需要一定的时间去完善去实践zabbix出现的更早，在国内的应用也更广泛，尤其是在服务器的监控层面；

3）数据存储：zabbix采用了传统的关系型数据库，默认是mySQL,大家都知道，在普通客户的传统监控场景下，这也许还问题不大，一旦上量上应用，传统关系型数据库很难支撑时序数据的轰炸，效率和速度就会成为瓶颈；Prometheus就充分意识到这一点，从一开始就才用了时序数据库，很好的解决了这个问题，好像zabbix也开始对接时序数据库了，目前还不完善。

4） 容器支持:由于Zabbix出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。而Prometheus的动态发现机制，不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。

5)部署难度：Prometheus架构简单，配置也相对简单；Zabbix需要配置监控源和监控系统，还是有点复杂。

6）图形化：

三、一点思考

Zabbix发展时间长一些，相对成熟，在各个行业成功案例也比较多，更容易获取支持，从应用场景说，更适合对服务器等变化不频繁的基础设施进行监控。但随着时间的推移，Zabbix会越开越面对复杂的监控需求，对数据的再加工和再利用会变得越来越困难，也就是说大多数用户都会面对去留的抉择。

Prometheus是新生事物，需要一个熟悉的过程，一旦采用后面的运营支撑会比Zabbix容易很多，更适合对于云和容器进行监控，更适合没有原始积累，刚开始做监控的用户使用。

还有一个感觉，我个人认为Prometheus更适合做服务监控，而且Zabbix还是停留在以Ip地址为主的主机监控层面，而且面向长期的持续监控和大规模数据分析的场景，Prometheus更从容一些。

Prometheus通过牺牲自己实现了人类的救赎，听起来也更神圣一点，哈哈哈。