万字谈监控：解答Zabbix与Prometheus选型疑难

 

    Zabbix与Prometheus     读完本文，你将收获    

1. 二者适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？

2. 二者怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？

3. 二者怎么应对告警风暴和误报？

4. 在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？

5. 监控大屏是怎么设计的？

6. 自动化运维管理是二者同时使用仍是二选一更合适？

7. 二者在配合使用时，应该怎么分工？怎么落地？

8. 若是已经部署了Zabbix，怎么平稳过渡到Prometheus？

9. 分布式链路的可观测性和端到端诊断怎么作？

10. 大规模场景下，二者的性能和成本哪一个比较低？

 

监控，为何总让咱们头痛

 

监控一直都是运维工做中不可或缺的部分，一个高效、契合的监控系统是服务赖以健康稳定的基石。随着业务规模的增加、技术的发展、行业的变革，企业对用户体验愈来愈重视，监控的需求发生着突飞猛进的变化，相应的监控工具和解决方案也层出不穷。其中，Zabbix和Prometheus就是两款很是典型的监控工具，应用颇为普遍。

 

提及来，监控在不一样的团队和公司之间，可能会存在各类差别化的需求。如何基于开源产品打造一个符合本身业务场景的监控体系，而且持续迭代？这成为了你们没法绕开的课题。

 

好比说，如何选择监控方案和开源工具？如何为本身的业务场景作定制化适配？如何实现端到端的全链路监控？如何让业务方以更低成本接入到这个系统中？如何作监控的自动化？如何作异常告警的路由、分发、收敛和抑制？如何作统一化的监控大屏、Dashboard等等……这些都是咱们在构建监控系统中可能会面临的问题。

 

围绕这些问题，dbaplus社群特别邀请到美图SRE负责人-石鹏(东方德胜)做为主持人、招商银行技术经理-蔡翔华做为Zabbix使用方、甜橙金融基础技术架构师-刘宇做为Prometheus使用方，针对Zabbix和Prometheus展开实用选型探讨。

 

十问十答，监控工具怎么选

 

Q1：Zabbix和Prometheus分别适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？

 

蔡翔华：咱们和Zabbix官方其实有沟经过，业内他们有一些监控到了40万以上的节点数，固然这个节点数也要根据你每一个节点上监控多少东西。Zabbix其实有一个指标叫作NVPS（New Value Per Second），也就是每秒新增的值的指标，来判断你的监控规模是否是合适的。

 

那么对于5000个节点以上的场景来讲，其实Zabbix仍是OK的，你能够经过多布署一些Proxy，去对后台数据库作一些性能调优等等，以这些方式去提升整个监控平台的可承受、负载的性能。

 

另外关于高可用，咱们的数据库端是会有Mycat或者HAProxy高可用，但服务器端自己它其实没有高可用，那么咱们能够依赖于虚拟化平台，或者是好比像咱们有Vmotion等热迁移这些技术。另外，在将来的5.x版本或者6版本以上的话，官方已经将原生的高可用归入到Zabbix的Roadmap里面了，你们能够期待一下。

 

石鹏：好的，蔡老师的核心观点其实就是咱们须要关注核心的指标，也就是NVPS，这个值是比较关键的。而后蔡老师以前您在实际的应用中，见过这个系统的峰值能够达到多少吗？是否能够给你们作个参考？

 

蔡翔华：在咱们本身的环境里面，NVPS峰值达到过6000以上，但咱们后面其实也作了一些优化，把它调整到3000左右。主要目的是，由于一开始咱们作的时候是但愿作到大而全，什么都监控，但最后发现其实大而全不必定有用，由于不少监控即便它是问题，你也不会care它。

 

刘宇：是的，蔡老师已经讲得比较详细了，其实以多大的规模是取决于你的监控目标，还有就是采集的间隔，好比说5秒采集一次和1分钟采集一次，这个规模都是支持着不同的目标，因此仍是要根据你的需求。

 

通常来讲，咱们会配置成30秒或者是一分钟；若是是对于高频的，会15秒。由于单个Prometheus性能已经比较强了，通常来讲，它每秒百万个指标都是没什么问题的。Prometheus会根据你的指标来计算，就是看你一个监控点上有多少个指标，这样来换算。

 

若是你单个Prometheus的性能达不到它的要求时，也能够去作一些拆分，好比说咱们把Prometheus根据它的功能来作区分，这个去监控node exporter，那个去监控Redis，这样来作区分。

 

固然，若是你单个的性能仍是不够的话，能够用分区，即用hash mod去多分几个Prometheus来作监控。

 

而后关于高可用这块，其实社区Prometheus这部分作得也不是特别好，会用两个Prometheus来同时监控一样的一个目标，这样来作到一个高可用。固然，在容器环境，你也能够去经过K8S的deployment这种方式，来把高可用维护起来。

 

Q2：Zabbix和Prometheus怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？

 

蔡翔华：的确，存储这个问题由于监控写的东西最多就是写到存储里面去，Zabbix之前被吐槽最多的就是它不支持时序数据库TSDB。其实在4.2之后，它就已经开始支持TSDB了，固然可能尚未Prometheus那么成熟，它主要的数据库仍是MySQL为主。

 

若是就存储问题的话，一方面你能够去尝试TSDB的这种方式；另一方面的话，你能够去经过增长SSD，或者说数据库层面的一些性能提高，去解决它的问题。包括数据库自己能够去分库分表，去拆分一下，而后对历史数据作一个归档……就是经过数据库层面的优化，来解决这个问题。

 

那么对于历史存储和分析这些信息，Zabbix提供了两个维度，一个叫history，一个叫trend，也就是一个历史数据和趋势数据。它具体数值是能够本身设定的，它的逻辑是说，若是超过history的保留期限，好比说30天，它自动会把数据归档成trend的数据，trend的数据就会只会保留最大值、最小值和平均值这三个指标，而并不能像history数据能够看到每一秒钟，甚至说每个轮巡周期的指标。

 

咱们实际场景应用的话，主要是用于咱们的性能分析，由于咱们有不少互联网应用，会看一下这个业务增加对我平台的要求，会不会CPU比较紧张、内存比较紧张等等。另外，咱们会根据这些数据作一个分析，为咱们后期的扩容、决策提供一些参考性的依据。比方说我如今看到今年总体的使用率在多少，咱们每一年的增加量是在20%仍是30%，这样咱们后续作一些决策的时候，是须要多少的资源、多少的预算，就比较能有参考价值。

 

刘宇：Prometheus自己存储若是存在本地的话，大概只能存15天，最多你也只能放到30天这样子。官方其实也不建议你把全部的监控数据都存在Prometheus的一个本地的数据库里。因此我在案例分享中也提到了一个远端存储的技术（案例分享内容请关注dbaplus社群后续文章发布）。

 

咱们是存在InfluxDB的，也有一些是能够存在好比说ES，经过remote_write的功能去存到ES或者是其它时序数据库中，或者是好比说HBase这种大数据的也能够存。

 

石鹏：好的了解，其实关于存储这个问题，咱们仍是更多应该从需求出发。总体来看有一些比较通用的思路，最典型的就是这两种：

 

第一种是数据的转储。好比像Prometheus，咱们在本地只存2周或者4周的数据，而后更多的话，就把它写到远端。

 

第二种思路是作数据采样。其实在不少监控系统里面，是一个比较常规的思路，就像在Zabbix里的history、trend，开始多是每30秒一个点，而后数据采样以后，多是每5分钟一个点。就用这样的方式，把这个数据量级减少，而后以此来作存储问题的优化。

 

Q3：Zabbix和Prometheus怎么应对告警风暴和误报？

 

蔡翔华：首先误报这个事情，其实在我理解里是不存在的。也就是说，之因此咱们会以为不少有误报的东西存在，是由于咱们对于规则，比方说我监控东西或者是我配置触发器，自己是有问题的。

 

我碰到不少人说，打算监控它的CPU使用率，不少人会直接记录usage，它的使用率，也有不少人会监控它的free的这个space。但有时候会因为配置错误，致使本来监控cpu usage的使用了cpu free的指标。因此说，其实不少时候报警之因此会产生误报，是由于配置自己不是很正确。

 

Zabbix的工做机制很简单：我去收集数据，去根据这个处罚规则去作比较，而后去发报警。当中全部的逻辑其实自己是不会出任何问题，除非说收集数据配错了、触发规则配错了、报警机制配错了……这些其实更可能是人为的因素在里面。

 

因此说，更多的是要经过这种检查来判断一下你是否有配错。

 

另一个减小误报的方式是经过模板化。由于咱们只要配置一次模板，那我把全部的Linux机型的监控模板都统一块儿来，对于全部监控Linux都套用同一个模板，那么就能够在必定程度上下降误报。关键仍是在于人的问题。

 

关于告警风暴，其实Zabbix里有一个特性叫作依赖项目。就比方说我如今有一台机器宕机，那么它可能里面的端口都会不通，而后ping也ping不通，CPU可能也拿不到，可能会有一堆的报警。那么咱们能够把全部的这种依赖项关联到ping上，一旦ping的机器都死了，上面确定东西都是宕掉了，这样子的话，它只会报ping的这一个问题，而不会把这堆机器上全部的东西都给报出来。就比如一我的若是死了，你跟他说这里有问题那里有问题，其实没有任何意义。它就只会把你最终的Root Cause（根因）给报出来，去防范这种告警风暴。

 

刘宇：是的，误报我其实跟蔡老师的观点是很像的，就是告警中实际上是存在一个误报率的，若是你的误报率很高的话，运维人员就很疲劳了，可能你们都会以为狼来了，没有办法信任你的那种告警，反而你真正发生故障的告警就会被忽略掉。因此制定告警的规则就很是重要，须要想办法把误报率给它下降。

 

那这种规则的制定其实就比较不是那么具体，会比较抽象，可能好比说把必需要人工介入处理的这种，才把它定为告警；而后若是系统能够本身处理掉，就不要把它告出来，或者只是在后面作一个天天发一次的报告也就好了。这是我对误报的一个见解。

 

关于告警风暴，在Prometheus中，对告警风暴的处理方式是这样：能够经过静默告警解决，或者是能够加入维护组，或者是也能够作一个聚合，也就是把告警给汇集，而后同类的告警合并，这样来减小告警的条数，主要是这样来作的。

 

固然若是你有些机器须要维护，它也是能够支持的，就是能够把一些告警直接静默掉。固然还有就是测试环境，好比说这种告警，你就能够彻底忽略掉，我以为能够这样来解决。

 

石鹏：好的，我总结一下，关于误报这个问题，两位老师的意见是比较一致的，我也是比较赞同的。误报其实最根本的缘由就是可能你的使用不合理，无论是你的配置仍是说你的各类姿式可能不合理，才会致使误报。

 

而后针对告警风暴，其实Zabbix和Prometheus也就是alert manager，它们都有提供一些相应的功能、特性。在Zabbix这边的话，能够像蔡老师说的用依赖项，而后也是能够加维护，也能够规避一些告警；而后Prometheus这边是alert manager它里面有silent这个静默规则，也是能够去作一些规避告警这种东西。

 

可能在不少公司，他们除了监控平台自己去作告警风暴的抑制，还会有另一层。好比说咱们公司这边是这样：

 

咱们有一个告警平台，全部的告警都会聚集到这个告警平台里，而后这个告警平台会去作一层合并、收敛和抑制。这样的话，就能够不用特别依赖监控平台自己来提供这些特性，而是由一个统一的平台，在作最后发送动做的时候，再来作一层cover。可能在量级大的场景下，这种是比较推荐的一种思路。

 

蔡翔华：是的，由于真正的监控当中，其实还会归入不少比方说ES等其它监控平台，甚至是一些业务告警。当平台不少的时候，其实你须要有一层聚合的方式，去把告警作一个聚合收敛，而后经过在聚合平台里配置必定规则以后，再去作后续的一些报警。

 

石鹏：没错，而且你有这个平台以后，就能够把一些告警的规则和策略作得更统一，这样的话，给用户的界面和体验也会更好。

 

蔡翔华：对，因此说其实看公司规模，由于这一块会涉及到一些二次开发，若是公司没有这个能力，那就能够把Zabbix全套或Prometheus全套都用上；若是后续有能力去作这种聚合的话，其实Zabbix也好，Prometheus也好，更多的角色定位会变成一个收集器的角色。而后后面的逻辑其实都交给事件管理平台或聚合平台去作。

 

刘宇：没错，这里Zabbix其实也能够把它的报警发送到alert manager里，也能够作一些静默处理，由于Zabbix自己它的静默功能确实不是特别多，仍是alert manager会作的更好一点。因此两个工具其实能够结合起来使用。

 

Q4：在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？

 

 

蔡翔华：首先咱们是有尝试过智能监控，可是包括我看到的不少书籍里面，包括Prometheus的一些书籍里面，也说设这种固定的预知是一个很蠢的方法。

 

根据我这边实际的应用，其实你要作到智能监控，确定要有一些大数据的东西，比方说我有这种规律：

 

例如，按照咱们的实际操做里有不少互联网的应用，有些东西它就是会有高并发高抢购，可能每月固定的时候，好比每月10号放一个活动，活动时它的量是平时的10倍甚至100倍；但也可能有时候，业务会不停地在不一样的时间放，你很难去判断这个点究竟是不是一个故障点。

 

也就是说，你用户数从10变成了1万，这1万究竟是由于故障了，仍是说是由于业务的一些逻辑致使的，很难判断。因此目前来讲，咱们尝试之后，仍是用了一些比较固定的报警预知去作。

 

那么回到这个话题，Zabbix自己它提供了一些预测的功能，它会预测如今个人磁盘消耗大约何时会消耗到20%如下，或某个阈值如下，它自己是提供了这个功能的。还有一些内置函数能够去作这个计算。可是目前来讲，我我的仍是建议使用一个比较固定的阈值，能够方便咱们有一个明确判断，不然你早期会有不少的误报，甚至可能你都会以为这东西很正常。

 

预测的数据也是基于现状的，若是能够对预测数据进行判断报警，理论上，也能够针对现有的数据进行判断报警。

 

刘宇：这块咱们实践的案例倒不是特别多，我主要仍是对数据库的监控比较熟，因此就说一下咱们在数据库的自动治愈上是怎么实现的吧。

 

好比说告警，它发送出来的同时，也会发送给数据库的一个自动化平台，这个平台会有一个程序根据告警内容来调一些自动治愈的程序来处理这种简单的故障。但这个其实作的也比较有限，就是说个人这种可以自愈的程序，都是根据具体场景的，并非全部的东西均可以作。好比说清理日志、杀读库大查询，以及须要加一些表空间这些场景，相似这种比较固定的会采用自愈来作，其余的尝试倒不是太多。

 

石鹏：嗯嗯，这个问题其实比较前沿，而且涉猎的范围是比较广的。像自动治愈，其实Zabbix也有一些相关的功能，它能够去配置action，当发现告警，有问题，我就能够绑定脚本去作一下处理。

 

但这个东西要作到什么程度，或者说要用什么技术来打造这个底座，可能都会有些差异。

 

蔡翔华：是的，由于我以为Prometheus和Zabbix或者说其余平台，都支持调action、调脚本去作一些重启，可是我以为关键问题的点是在于你敢不敢作这个事情。

 

由于咱们知道咱们的环境实际上是很复杂的。比方说，我发觉数据库宕了，服务停了，我敢不敢经过这个服务本身切过去。由于不少时候并非数据库自己的问题，是网络的问题，网络抖动了，监控数据拿不到了。这个是很是依赖于整个总体环境的，你可能要想到方方面面，这个规则会很是复杂。你可能在作服务自愈的时候，还要去对其余的东西作一个彻底的检查，确保其余东西是没有问题的。

 

因此不说服务自愈，哪怕在咱们平常的故障处理当中，也很依赖于经验。就是说这个东西是能作的，可是咱们不太敢，由于要考虑的要素不少，就不太敢去直接作自愈这一块。

 

石鹏：没错，自己其实它是一个体系化的工程，不只仅是跟监控相关。我这边的一个想法是这样，关于自动治愈这块，咱们可能仍是要更多去依靠业务侧的能力。就是说，业务侧要具有一些这种架构设计上的考量，好比说架构的柔性，能够本身去作限流、降级、作熔断，这要求业务侧有这样的能力才能够，而不是说仅仅依靠监控系统去作某些动做触发。

 

至于说一些算法和策略的话，以前美图这边也是有过一些简单的尝试，应用不算很是普遍。但业界的话，DataOps、AIOps的概念也是比较火热，这些东西在像BAT这些公司其实也有一些实际的应用已经在落地了。

 

以前咱们作的话，有作这么几个小东西，关于故障预测是有这么几个算法：有同期的数据比较、同期的振幅比较、有一个移动平均算法、而后再有一个变点监测。而后这几个的话，能够简单说一下思路，其实也比较好理解。

 

• 同期数据，是我按照周期，好比说今天某个时间点这个数据，我去比较昨天这个点是什么样子的，去比较数据；

• 振幅，其实它就相对更柔性一点，里面会给你加上一个权重，加上一个比例，好比正态分布里边的3-sigma，做为振幅系数去比较同期的数据，看在算上振幅以后，你是否是已经超出了，去作一个预测；

• 变点监测，就是说我总体的数据曲线是什么样子的，忽然出现了一个离我正常预测曲线偏离很是远的一个点，这种的话会有一个这样的算法来作这个事情。

 

而后这块相对比较成熟的工具的话，像腾讯以前有开源的运维学件METIS，它里面集成了很是多的算法模型，这个有兴趣的同窗能够去作一些了解。

 

Q5：监控大屏是怎么设计的？

 

蔡翔华：首先从技术自己来讲，5.0版本能够看到Zabbix的UI都很不错，能够不少的组、主机都往大屏里面去拖。大屏的话，咱们大概会分几块：

 

第一块是整个系统运行状态。我可能整个系统有从用户登陆到用户支付，包括到购物车等等，有一个链路。我对于每一个链路其实都会有一个监控，它每个S组 Service的组，那么Service的组里面包括它的应用、数据库缓存、应用系统甚至硬件服务器，一旦这里有任何东西出问题以后，直接会在大屏上显示一个警告，那么我就会知道如今整个生产环节哪一个系统是有问题的。

 

那么另外就是一个summary，一个overview的全局的导览，由于一旦我知道这个有问题，我就但愿更加细化知道这个东西哪里有问题。那么在下面就会有一个trigger list的问题列表，就是说有哪些触发器被触发了，我会看到比方说，数据库端口不通了，仍是说磁盘空间已经满了。下面会有trigger list，而后这个trigger list会按照故障等级是disaster仍是warning，同时对应的管理员或者运维人员也会收到这个短信，就知道要当即去处理了。

 

因此咱们尽量就在大屏里从两方面来把控，一方面从大的来说，有一个over view看到全局，从小的来说，我要知道个人故障发生在哪里。基本上保证这两个要素在大屏里面就OK了。

 

刘宇：咱们这边大屏其实主要仍是应用的维度以及网络流量的维度为主。好比说从公网的一个出口和入口的流量来看会不会有大面积的一个问题。若是发现已经达到外面防火墙或者它流量的一个阈值了，就能够迅速定位问题。

 

若是是细节的话，咱们会在大型活动前夕，梳理活动链路上的全部应用，根据应用的维度来设计这样一个大屏。大屏能够看到链路上全部应用、数据库或者是中间件的状况，一旦哪一个应用的QPS高了，或者是其余压力的状况，就能够第一时间定位到问题出如今哪里，是这样一个思路来作。

 

石鹏：监控大屏作得好，确实能够辅助咱们技术同窗去更快地定位和排查问题，还有一个比较重要的点，我是这么想的，就是老板会关注。有些公司会把大屏设计得很是有科技感，让老板看的话，可能老板也以为个人技术团队还挺牛的。固然这是一个题外话。

 

前面蔡老师和刘老师都给了一些建设上的思路，就是你应该去包含哪些数据，应该怎么去作。这方面的话，个人一个思考是你可能要去作服务的梳理，而后能够以分块、分业务或者说按照分层的方式来作。

 

分块的话，就是你按照业务线来分。你公司可能有不少块业务，而后按照不一样的业务去提供一个视角。在每一个业务里，你能够去作分层，分层的意思就是说能够把整个链路，从客户端一直到CDN、 DNS链路，而后到LB入口层，以及应用这一层是什么样的，再关联到后面的一些后端资源，像数据库、缓存这些东西，还有一些其余的周边依赖，按照这样分层的方式来作。

 

具体实践的话，能够跟你们作个预告，最近咱们美图有一些实践经验能够分享，近期会把一些完整的设计思路和细节放出来，你们能够期待一下，持续关注dbaplus社群的发文。

 

关于技术实现方面，我简单赘述两句。咱们公司的监控大屏是用了Grafana来作的，Grafana可能已经成为了事实上的监控UI、数据可视化的标准了，它能够后面去接各类各样的数据源，而后你各个监控系统、各类数据原理的数据能够统一来展现。

 

这里须要感谢一个社区的插件，叫Flow Charting，这个插件能够很是好地去作监控链路的事情，就是你能够用这个插件去把整个链路关键环节，以这种图的方式绘制出来，而后给每个点、每一条线绑定上监控数据，最后生成的图就动起来了，就能够看到一个全局性的链路状态：从入口一直到后端资源，包括各类依赖，当前它的状态是什么样子的。

 

固然这个前提是，你整个链路的监控数据是要完备的，而后你才能够借助这个插件去把它呈现出来，大概是这个样子的，在这个图上就一目了然了。

 

Q6：自动化运维管理是Zabbix和Prometheus同时使用仍是二选一更合适？

 

蔡翔华：若是是个纯容器化的，就说你环境里面全是Docker，那么说实话我也不推荐你去使用Zabbix。

 

由于Zabbix对容器的监控，虽然官方已经开始重视了，甚至说如今也支持了Prometheus的不少metrics和exporter这种方式去作监控，就是它也能够原生的去支持Prometheus这些东西，但相对来讲，Prometheus在容器化监控这边仍是会更好一些。

 

若是你的监控需求是又要监控硬件服务器，又要监控中间件，又要监控业务指标，那么我推荐使用Zabbix，由于Zabbix覆盖的面会更广一些。

 

的确我以为任何需求Zabbix和Prometheus均可以去作，可是从实现成原本说，相对于Prometheus，你的服务环境越复杂，Zabbix可能就越适合这种比较复杂的异构的环境。

 

刘宇：咱们目前公司状况是两个都在用，的确是偏容器的会往Prometheus优先考虑，若是是旧的，好比说是有偏服务化的这种监控，也会慢慢地往Prometheus作一些迁移。

 

若是你的环境是一种就能够知足的话，建议仍是一种，由于毕竟只须要维护一种技术栈就能够了。或者是你能够作一些偏重，好比说把一些不变的放在一种上面，常常会变的放在另一种上面。尽可能去减小你维护的技术栈。若是你的环境比较简单的话，只用一种，固然是最好了。

 

石鹏：其实仍是看场景，美图跟刘老师这边比较相似，咱们也是多种监控工具在用，不过咱们如今没有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，还有不少基于大数据的一些流式处理的组件，咱们都是混合在用。

 

主要仍是看你具体的需求和场景，没有银弹，没有说一个工具能够很是合适去搞定全部事情。固然它有可能有能力，可是它并不必定特别合适。至于具体的选择上，仍是要看具体场景。比较明确的一个思路可能就是要看你的监控对象究竟是容器仍是非容器，它是这种易变的仍是比较稳定态的。这两个思路的话，也是跟蔡老师和刘老师比较一致的。

 

Q7：Zabbix和Prometheus在配合使用时，应该怎么分工？怎么落地？

 

蔡翔华：其实从场景来讲，Prometheus更适合容器。你能够看一下整个环境里，容器和Zabbix的占比，像刚才刘老师说的，这二者数据实际上是能够互相使用、互相监控甚至是互相触发报警，那么在Zabbix如今其实已经原生支持了Prometheus的这些exporter的功能，即便你没有Prometheus后端，Zabbix也能够直接去exporter上拿一些数据，经过Zabbix的一些逻辑和机制去报警。那么相同的，Zabbix也能够经过action把这些数据扔给Prometheus。

 

也就是说，你能够把它们二者当中的一个做为数据的采集器，另一个做为整个数据的逻辑处理的功能，相似于alert manager或者是在zabbix server同样，这样作的好处就是说，收集数据会很是方便，比方说Prometheus不能收集硬件数据，但Zabbix能够收集，咱们就用Zabbix收集，同时把它的数据扔给Prometheus，作一个统一的报警。这样的确仍是要维护两个平台，可是相对来讲，维护成本会有所下降，不须要对Zabbix那边作太多的模板，它其实只是一个数据采集器。

 

那么稳定性、可用性、性能及监控这些东西，其实也基本上能够基于Prometheus现成的这些规则、Zabbix现成的这些模板来作。其实Zabbix社区里面也有不少模板能够提供到。

 

关键我以为有一点就是，咱们要思考它模板里面提供的东西，是不是我真的须要的，由于不少时候你们以为我啥都要监控，但事实上不是这样子，只有真正须要关注的点，才是须要监控的东西。因此说你们在部署监控以前，要先思考一下监控的目的是什么。

 

刘宇：个人见解其实仍是这样，好比说偏基础的，像主机、网络这种能够用Zabbix来监控，偏服务类的和容器的，就用Prometheus来作监控。

 

咱们监控Redis的一个集群，在之前没有Grafana或者Prometheus的状况下，用Zabbix去看集群的总体状况就会比较麻烦，由于Zabbix依赖的监控的一个点仍是以host为基础的，因此你去看整个服务的话会比较麻烦。而Prometheus由于它是时序的数据，能够方便地去打一些你想要的标签，这样就能够比较方便地监控单个服务上一个总体的状况，因此服务这块来讲，仍是Prometheus比较方便。而前面其余蔡老师也说了，好比说硬件这种仍是Zabbix比较好用。

 

石鹏：OK，这个点上咱们理解仍是很是一致的。像如今美图这边，就单讲Prometheus和Open-Falcon，咱们基础的这些监控都是在Open-Falcon里，而后容器会在Prometheus里。

 

这里须要补充一下咱们的环境，如今咱们全部业务都是基于云上来作的，业务容器化程度的话，应该是只有个别服务没有容器化，整个比例应该95%以上都是容器化的。但即便是这样，咱们也没有彻底摒弃掉Open-Falcon。

 

咱们在这个容器里，容器层的这些服务，像servive、pod这些监控，好比说业务上暴露出来的metrics，这些东西咱们都是用Prometheus来作的。可是像k8s node节点、ECS，它自己的一些监控，包括一些网络质量的监控，仍是要有一个更适合作这种基础监控的平台来作。咱们就是在Open-Falcon里作的。

 

因此主要仍是看场景，怎么去侧重就是看你具体的需求了。

 

Q8：若是已经部署了Zabbix，怎么平稳过渡到Prometheus？

 

蔡翔华：若是已经部署了Zabbix，我估计你直接经过数据库去导入这种方式会很难作，由于它的表结构，包括一个是时序数据库，一个是TSDB，就没办法直接作。

 

我建议若是真的要过渡到Prometheus的话，能够仍然使用Zabbix agent，在数据采样完以后，把它扔到Prometheus，触发一些action去提供给Prometheus。这是一种中转方式。

 

另一种方式，我会经过一些ansible去部署一些Prometheus expoter到那些机器上去，把这些数据扔给Prometheus。其实也就回到刚才那个问题，我这边全部的数据均可以扔给Prometheus使用，去触发报警，这都OK的。

 

刘宇：若是真的要把Zabbix迁移到Prometheus，就是涉及到一个监控迁移的过程。我这边的建议仍是按照Zabbix先模块划分，好比说其中一个模块准备迁到Prometheus，而后首先会把这个模块Prometheus的监控也加上，会把两边的监控进行一个比较，至少Prometheus能把原来Zabbix的监控都能覆盖掉，不只是监控的覆盖，还有告警覆盖，这样一个并行的过程。

 

最终彻底可以达到同样的效果，我就能够把原来Zabbix相关模块的监控给下掉，是这样一个建议的路径。

 

蔡翔华：对，并且其实Prometheus和Zabbix同时存在并不冲突，并非说二者只能选其一。其实能够说，我先把Prometheus的exporter规则都配上去，两边同时监控，而后再根据需求，把Zabbix给下了，也OK，这是不存在冲突的。

 

石鹏：没错，既然你要平滑，那两边同时有，这应该是最平滑的。咱们以前是有从Zabbix迁到了Open-Falcon，迁移通过了一个比较长的耗时，大概用了一年多的时间。其实就是你把另外一边的监控也布起来，同时监控，而后逐步去下旧监控。在这个过程里，你还能够去比较二者之间是否是有差别，是否是都能知足需求，这样的话应该是比较平滑的。

 

Q9：分布式链路的可观测性和端到端诊断怎么作？

 

蔡翔华：分布式链路其实咱们没有用Zabbix，由于分布式链路要考虑上下游的关系，因此咱们会基于APM去作。如今像业内比较流行的CAT，能够参考这些去作。

 

端到端的侦测的话，其实Zabbix也支持，它支持两种方式：

 

一个是它能够在本地跑一些脚本去作，就是说我这个检测是从Zabbix某个Agen端出发，到另一台目标机器，而不是经过Zabbix server去作检测。因此说这是Zabbix 提供的另一种方式，Zabbix active的一种方式，它能够去实现这种端到端的侦测。Zabbix active的监控方式也是比较好的一种方式，能够减轻Zabbix server端的压力，或proxy端的压力，能提供更丰富的一些监控。

 

刘宇：这块由于Prometheus是一个基于数值的监控，对于这种全链路的话，通常不太会用Prometheus来作，基本上会用APM的一些分布式链路追踪的工具，好比skywalking等来作。

 

还会经过一些日志系统来作分布式的监控，在链路上，提早写入一些标签，这样从始至终均可以拿到整个链路上的一个关系，就能够作一些分布式链路上的监控的东西。

 

石鹏：是的，这也就回到咱们前面讨论的，没有银弹，没有一种技术栈能够解决全部需求的。包括Zabbix和Prometheus，其实更关注的仍是在偏服务端，若是是应用端的话，其实仍是要依赖一些APM的工具。就像刘老师说的Apache的skywalking，还有像鹰眼、基于open tracing的其余工具。这些东西其实都是一种思路。

 

还有一些有技术能力的公司，会选择自研一些APM工具，须要本身去开发各类SDK，而后须要迁到客户端，去上报数据，是这个样子的。

 

其实端到端总体的建设思路应该是分段的，客户端的是一段，中间链路是一段，服务端又是另一侧。因此想作端到端，很难说用一个工具就能够彻底覆盖起来。

 

如今基于云原生、微服务这些发展的比较火热，可能会有一些各个服务之间调用链路的服务治理相关的监控需求，可能也不是说经过Prometheus或Zabbix就能够很好地去完成。仍是要看需求场景，选择更合适的工具，而且组合起来使用。

 

Q10：大规模场景下，Prometheus和Zabbix的性能和成本哪一个比较低？

 

蔡翔华：首先我以为仍是看应用场景，由于大规模场景下，要看这个场景是容器多仍是非容器环境多，这是一个主要依据。

 

Zabbix性能的话，其实瓶颈主要是在数据库，只要把数据库的优化作得足够好，其实开头也说了，业内也有作到40万NVPS的这种案例，已是比较变态了。那无非就是说，去作数据库分区分库拆表、加SSD存储，经过这种方式。

 

成本的话，我我的以为在底层资源知足的前提下，成本应该都OK。由于Prometheus是基于exporter，Zabbix是基于Agent，经过Zabbix agent，配合自动发现和低级别发现的这种方式去实现自动化。

 

配置成本可能Zabbix会低不少，由于都是基于UI去作，而Prometheus是基于配置文件去作，这个可能Zabbix会更好些。因此我综合成本，以为Zabbix稍微会好一些，但仍是取决于你的场景里有多少虚拟化。

 

刘宇：我以为若是是性能的话，经过一些分区的手段都能解决。但若是是很是大的规模，经过Zabbix，其实它的数据库瓶颈仍是比较严重的，这块仍是须要一些比较好优化手段才能解决。

 

监控采集的agent的方式而言，我以为Prometheus的exporter作得很是全面，像咱们之前用Zabbix，基本上有不少东西监控都是本身去开发的；而如今用Prometheus，基本上对于这种采集器的开发都没有了，用社区的就能够所有解决了。因此在采集的层面上，去实现它最底层和服务的一个数据采集，我感受Prometheus的成本会更低一点。

 

固然由于Prometheus相对来讲仍是一个微服务的架构，它的全部组件都是分开的，在搭建成本、学习成本会稍微高一点。

 

石鹏：其实仍是要针对个性化的场景去作一些选择。成本的话，若是说你的环境是一个比较纯粹的，要么是全容器，要么是虚拟化或者物理环境，你就选一种就行了。若是说你是异构的话，可能就不可避免的要选两种同时维护。这两种里若是有所侧重的话，成本其实就会有所侧重，因此仍是看你的具体需求。

 

选型，在于抓住监控的核心

 

对于你们比较关注的监控工具选型，用一句话来归纳就是：没有最好的，只有最适合的，要具体场景具体分析。

 

总的来说，若是是比较纯粹的环境，好比是纯物理机、纯虚拟机，更关注一些偏基础设施层面的需求的话，Zabbix会是一个很是不错的选项；若是是容器化场景，Prometheus的适应性会更好；若是是异构的话，建议二者或更多其它工具结合起来使用。

 

纵观整个监控发展史，其实监控方案一直是跟随着行业技术、业务发展不断变化的。到如今，比较火热的技术像5G互联、物联网、人工智能……各类技术层出不穷，咱们须要去监控的目标对象也一直发生着变化。随着多云、混合云架构在更多行业里持续落地开花，容器、云原生等各类技术的蓬勃发展，对监控系统其实也提出了新的需求。

 

技术更新迭代速度愈来愈快，不少同窗不免会有一些焦虑的情绪。这种焦虑是不可避免的，咱们应该作的仍是要去抓住事物的本质。

 

针对监控这个需求，也就是说监控的核心是什么？

 

监控在高度抽象以后，无非能够这么来分：监控数据的暴露、数据的采集和传输、监控数据的存储和处理……这个过程里，包括各类优化、各类格式化处理等；最后是咱们怎么去用好监控数据，把监控数据的价值最大化，好比说咱们去作报表展现、作数据分析，像前面讲到的用一些DataOps、AIOps的算法、能力介入，把监控数据的价值挖掘出来。

 

这其实就是监控系统所要承载的功能，咱们要作的就是抓住这些核心路径里的原理，而后掌握它，其实也就OK了。

 

另外，咱们须要保持对这些新鲜事物的热忱，保持对技术的敏锐，要有行业发展趋势的感知能力。好比企业上云，其实从行业报告来看，从去年就已通过了上云的拐点，会有愈来愈多公司选择把服务迁移到云上；再看容器和云原生，会有愈来愈多的周边生态完善起来。咱们要有这样的感知能力，要可以感觉到这个行业发展的脉搏，而后作好相应的技术储备，只有这样，咱们才可能在技术的浪潮里作到从容不迫，才可以乘风破浪。

    Zabbix与Prometheus     读完本文，你将收获    

1. 二者适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？

2. 二者怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？

3. 二者怎么应对告警风暴和误报？

4. 在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？

5. 监控大屏是怎么设计的？

6. 自动化运维管理是二者同时使用仍是二选一更合适？

7. 二者在配合使用时，应该怎么分工？怎么落地？

8. 若是已经部署了Zabbix，怎么平稳过渡到Prometheus？

9. 分布式链路的可观测性和端到端诊断怎么作？

10. 大规模场景下，二者的性能和成本哪一个比较低？

 

监控，为何总让咱们头痛

 

监控一直都是运维工做中不可或缺的部分，一个高效、契合的监控系统是服务赖以健康稳定的基石。随着业务规模的增加、技术的发展、行业的变革，企业对用户体验愈来愈重视，监控的需求发生着突飞猛进的变化，相应的监控工具和解决方案也层出不穷。其中，Zabbix和Prometheus就是两款很是典型的监控工具，应用颇为普遍。

 

提及来，监控在不一样的团队和公司之间，可能会存在各类差别化的需求。如何基于开源产品打造一个符合本身业务场景的监控体系，而且持续迭代？这成为了你们没法绕开的课题。

 

好比说，如何选择监控方案和开源工具？如何为本身的业务场景作定制化适配？如何实现端到端的全链路监控？如何让业务方以更低成本接入到这个系统中？如何作监控的自动化？如何作异常告警的路由、分发、收敛和抑制？如何作统一化的监控大屏、Dashboard等等……这些都是咱们在构建监控系统中可能会面临的问题。

 

围绕这些问题，dbaplus社群特别邀请到美图SRE负责人-石鹏(东方德胜)做为主持人、招商银行技术经理-蔡翔华做为Zabbix使用方、甜橙金融基础技术架构师-刘宇做为Prometheus使用方，针对Zabbix和Prometheus展开实用选型探讨。

 

十问十答，监控工具怎么选

 

Q1：Zabbix和Prometheus分别适用于多大规模的监控场景？超过5000以上监控节点时怎么办？高可用怎么解决？

 

蔡翔华：咱们和Zabbix官方其实有沟经过，业内他们有一些监控到了40万以上的节点数，固然这个节点数也要根据你每一个节点上监控多少东西。Zabbix其实有一个指标叫作NVPS（New Value Per Second），也就是每秒新增的值的指标，来判断你的监控规模是否是合适的。

 

那么对于5000个节点以上的场景来讲，其实Zabbix仍是OK的，你能够经过多布署一些Proxy，去对后台数据库作一些性能调优等等，以这些方式去提升整个监控平台的可承受、负载的性能。

 

另外关于高可用，咱们的数据库端是会有Mycat或者HAProxy高可用，但服务器端自己它其实没有高可用，那么咱们能够依赖于虚拟化平台，或者是好比像咱们有Vmotion等热迁移这些技术。另外，在将来的5.x版本或者6版本以上的话，官方已经将原生的高可用归入到Zabbix的Roadmap里面了，你们能够期待一下。

 

石鹏：好的，蔡老师的核心观点其实就是咱们须要关注核心的指标，也就是NVPS，这个值是比较关键的。而后蔡老师以前您在实际的应用中，见过这个系统的峰值能够达到多少吗？是否能够给你们作个参考？

 

蔡翔华：在咱们本身的环境里面，NVPS峰值达到过6000以上，但咱们后面其实也作了一些优化，把它调整到3000左右。主要目的是，由于一开始咱们作的时候是但愿作到大而全，什么都监控，但最后发现其实大而全不必定有用，由于不少监控即便它是问题，你也不会care它。

 

刘宇：是的，蔡老师已经讲得比较详细了，其实以多大的规模是取决于你的监控目标，还有就是采集的间隔，好比说5秒采集一次和1分钟采集一次，这个规模都是支持着不同的目标，因此仍是要根据你的需求。

 

通常来讲，咱们会配置成30秒或者是一分钟；若是是对于高频的，会15秒。由于单个Prometheus性能已经比较强了，通常来讲，它每秒百万个指标都是没什么问题的。Prometheus会根据你的指标来计算，就是看你一个监控点上有多少个指标，这样来换算。

 

若是你单个Prometheus的性能达不到它的要求时，也能够去作一些拆分，好比说咱们把Prometheus根据它的功能来作区分，这个去监控node exporter，那个去监控Redis，这样来作区分。

 

固然，若是你单个的性能仍是不够的话，能够用分区，即用hash mod去多分几个Prometheus来作监控。

 

而后关于高可用这块，其实社区Prometheus这部分作得也不是特别好，会用两个Prometheus来同时监控一样的一个目标，这样来作到一个高可用。固然，在容器环境，你也能够去经过K8S的deployment这种方式，来把高可用维护起来。

 

Q2：Zabbix和Prometheus怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？

 

蔡翔华：的确，存储这个问题由于监控写的东西最多就是写到存储里面去，Zabbix之前被吐槽最多的就是它不支持时序数据库TSDB。其实在4.2之后，它就已经开始支持TSDB了，固然可能尚未Prometheus那么成熟，它主要的数据库仍是MySQL为主。

 

若是就存储问题的话，一方面你能够去尝试TSDB的这种方式；另一方面的话，你能够去经过增长SSD，或者说数据库层面的一些性能提高，去解决它的问题。包括数据库自己能够去分库分表，去拆分一下，而后对历史数据作一个归档……就是经过数据库层面的优化，来解决这个问题。

 

那么对于历史存储和分析这些信息，Zabbix提供了两个维度，一个叫history，一个叫trend，也就是一个历史数据和趋势数据。它具体数值是能够本身设定的，它的逻辑是说，若是超过history的保留期限，好比说30天，它自动会把数据归档成trend的数据，trend的数据就会只会保留最大值、最小值和平均值这三个指标，而并不能像history数据能够看到每一秒钟，甚至说每个轮巡周期的指标。

 

咱们实际场景应用的话，主要是用于咱们的性能分析，由于咱们有不少互联网应用，会看一下这个业务增加对我平台的要求，会不会CPU比较紧张、内存比较紧张等等。另外，咱们会根据这些数据作一个分析，为咱们后期的扩容、决策提供一些参考性的依据。比方说我如今看到今年总体的使用率在多少，咱们每一年的增加量是在20%仍是30%，这样咱们后续作一些决策的时候，是须要多少的资源、多少的预算，就比较能有参考价值。

 

刘宇：Prometheus自己存储若是存在本地的话，大概只能存15天，最多你也只能放到30天这样子。官方其实也不建议你把全部的监控数据都存在Prometheus的一个本地的数据库里。因此我在案例分享中也提到了一个远端存储的技术（案例分享内容请关注dbaplus社群后续文章发布）。

 

咱们是存在InfluxDB的，也有一些是能够存在好比说ES，经过remote_write的功能去存到ES或者是其它时序数据库中，或者是好比说HBase这种大数据的也能够存。

 

石鹏：好的了解，其实关于存储这个问题，咱们仍是更多应该从需求出发。总体来看有一些比较通用的思路，最典型的就是这两种：

 

第一种是数据的转储。好比像Prometheus，咱们在本地只存2周或者4周的数据，而后更多的话，就把它写到远端。

 

第二种思路是作数据采样。其实在不少监控系统里面，是一个比较常规的思路，就像在Zabbix里的history、trend，开始多是每30秒一个点，而后数据采样以后，多是每5分钟一个点。就用这样的方式，把这个数据量级减少，而后以此来作存储问题的优化。

 

Q3：Zabbix和Prometheus怎么应对告警风暴和误报？

 

蔡翔华：首先误报这个事情，其实在我理解里是不存在的。也就是说，之因此咱们会以为不少有误报的东西存在，是由于咱们对于规则，比方说我监控东西或者是我配置触发器，自己是有问题的。

 

我碰到不少人说，打算监控它的CPU使用率，不少人会直接记录usage，它的使用率，也有不少人会监控它的free的这个space。但有时候会因为配置错误，致使本来监控cpu usage的使用了cpu free的指标。因此说，其实不少时候报警之因此会产生误报，是由于配置自己不是很正确。

 

Zabbix的工做机制很简单：我去收集数据，去根据这个处罚规则去作比较，而后去发报警。当中全部的逻辑其实自己是不会出任何问题，除非说收集数据配错了、触发规则配错了、报警机制配错了……这些其实更可能是人为的因素在里面。

 

因此说，更多的是要经过这种检查来判断一下你是否有配错。

 

另一个减小误报的方式是经过模板化。由于咱们只要配置一次模板，那我把全部的Linux机型的监控模板都统一块儿来，对于全部监控Linux都套用同一个模板，那么就能够在必定程度上下降误报。关键仍是在于人的问题。

 

关于告警风暴，其实Zabbix里有一个特性叫作依赖项目。就比方说我如今有一台机器宕机，那么它可能里面的端口都会不通，而后ping也ping不通，CPU可能也拿不到，可能会有一堆的报警。那么咱们能够把全部的这种依赖项关联到ping上，一旦ping的机器都死了，上面确定东西都是宕掉了，这样子的话，它只会报ping的这一个问题，而不会把这堆机器上全部的东西都给报出来。就比如一我的若是死了，你跟他说这里有问题那里有问题，其实没有任何意义。它就只会把你最终的Root Cause（根因）给报出来，去防范这种告警风暴。

 

刘宇：是的，误报我其实跟蔡老师的观点是很像的，就是告警中实际上是存在一个误报率的，若是你的误报率很高的话，运维人员就很疲劳了，可能你们都会以为狼来了，没有办法信任你的那种告警，反而你真正发生故障的告警就会被忽略掉。因此制定告警的规则就很是重要，须要想办法把误报率给它下降。

 

那这种规则的制定其实就比较不是那么具体，会比较抽象，可能好比说把必需要人工介入处理的这种，才把它定为告警；而后若是系统能够本身处理掉，就不要把它告出来，或者只是在后面作一个天天发一次的报告也就好了。这是我对误报的一个见解。

 

关于告警风暴，在Prometheus中，对告警风暴的处理方式是这样：能够经过静默告警解决，或者是能够加入维护组，或者是也能够作一个聚合，也就是把告警给汇集，而后同类的告警合并，这样来减小告警的条数，主要是这样来作的。

 

固然若是你有些机器须要维护，它也是能够支持的，就是能够把一些告警直接静默掉。固然还有就是测试环境，好比说这种告警，你就能够彻底忽略掉，我以为能够这样来解决。

 

石鹏：好的，我总结一下，关于误报这个问题，两位老师的意见是比较一致的，我也是比较赞同的。误报其实最根本的缘由就是可能你的使用不合理，无论是你的配置仍是说你的各类姿式可能不合理，才会致使误报。

 

而后针对告警风暴，其实Zabbix和Prometheus也就是alert manager，它们都有提供一些相应的功能、特性。在Zabbix这边的话，能够像蔡老师说的用依赖项，而后也是能够加维护，也能够规避一些告警；而后Prometheus这边是alert manager它里面有silent这个静默规则，也是能够去作一些规避告警这种东西。

 

可能在不少公司，他们除了监控平台自己去作告警风暴的抑制，还会有另一层。好比说咱们公司这边是这样：

 

咱们有一个告警平台，全部的告警都会聚集到这个告警平台里，而后这个告警平台会去作一层合并、收敛和抑制。这样的话，就能够不用特别依赖监控平台自己来提供这些特性，而是由一个统一的平台，在作最后发送动做的时候，再来作一层cover。可能在量级大的场景下，这种是比较推荐的一种思路。

 

蔡翔华：是的，由于真正的监控当中，其实还会归入不少比方说ES等其它监控平台，甚至是一些业务告警。当平台不少的时候，其实你须要有一层聚合的方式，去把告警作一个聚合收敛，而后经过在聚合平台里配置必定规则以后，再去作后续的一些报警。

 

石鹏：没错，而且你有这个平台以后，就能够把一些告警的规则和策略作得更统一，这样的话，给用户的界面和体验也会更好。

 

蔡翔华：对，因此说其实看公司规模，由于这一块会涉及到一些二次开发，若是公司没有这个能力，那就能够把Zabbix全套或Prometheus全套都用上；若是后续有能力去作这种聚合的话，其实Zabbix也好，Prometheus也好，更多的角色定位会变成一个收集器的角色。而后后面的逻辑其实都交给事件管理平台或聚合平台去作。

 

刘宇：没错，这里Zabbix其实也能够把它的报警发送到alert manager里，也能够作一些静默处理，由于Zabbix自己它的静默功能确实不是特别多，仍是alert manager会作的更好一点。因此两个工具其实能够结合起来使用。

 

Q4：在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？

 

 

蔡翔华：首先咱们是有尝试过智能监控，可是包括我看到的不少书籍里面，包括Prometheus的一些书籍里面，也说设这种固定的预知是一个很蠢的方法。

 

根据我这边实际的应用，其实你要作到智能监控，确定要有一些大数据的东西，比方说我有这种规律：

 

例如，按照咱们的实际操做里有不少互联网的应用，有些东西它就是会有高并发高抢购，可能每月固定的时候，好比每月10号放一个活动，活动时它的量是平时的10倍甚至100倍；但也可能有时候，业务会不停地在不一样的时间放，你很难去判断这个点究竟是不是一个故障点。

 

也就是说，你用户数从10变成了1万，这1万究竟是由于故障了，仍是说是由于业务的一些逻辑致使的，很难判断。因此目前来讲，咱们尝试之后，仍是用了一些比较固定的报警预知去作。

 

那么回到这个话题，Zabbix自己它提供了一些预测的功能，它会预测如今个人磁盘消耗大约何时会消耗到20%如下，或某个阈值如下，它自己是提供了这个功能的。还有一些内置函数能够去作这个计算。可是目前来讲，我我的仍是建议使用一个比较固定的阈值，能够方便咱们有一个明确判断，不然你早期会有不少的误报，甚至可能你都会以为这东西很正常。

 

预测的数据也是基于现状的，若是能够对预测数据进行判断报警，理论上，也能够针对现有的数据进行判断报警。

 

刘宇：这块咱们实践的案例倒不是特别多，我主要仍是对数据库的监控比较熟，因此就说一下咱们在数据库的自动治愈上是怎么实现的吧。

 

好比说告警，它发送出来的同时，也会发送给数据库的一个自动化平台，这个平台会有一个程序根据告警内容来调一些自动治愈的程序来处理这种简单的故障。但这个其实作的也比较有限，就是说个人这种可以自愈的程序，都是根据具体场景的，并非全部的东西均可以作。好比说清理日志、杀读库大查询，以及须要加一些表空间这些场景，相似这种比较固定的会采用自愈来作，其余的尝试倒不是太多。

 

石鹏：嗯嗯，这个问题其实比较前沿，而且涉猎的范围是比较广的。像自动治愈，其实Zabbix也有一些相关的功能，它能够去配置action，当发现告警，有问题，我就能够绑定脚本去作一下处理。

 

但这个东西要作到什么程度，或者说要用什么技术来打造这个底座，可能都会有些差异。

 

蔡翔华：是的，由于我以为Prometheus和Zabbix或者说其余平台，都支持调action、调脚本去作一些重启，可是我以为关键问题的点是在于你敢不敢作这个事情。

 

由于咱们知道咱们的环境实际上是很复杂的。比方说，我发觉数据库宕了，服务停了，我敢不敢经过这个服务本身切过去。由于不少时候并非数据库自己的问题，是网络的问题，网络抖动了，监控数据拿不到了。这个是很是依赖于整个总体环境的，你可能要想到方方面面，这个规则会很是复杂。你可能在作服务自愈的时候，还要去对其余的东西作一个彻底的检查，确保其余东西是没有问题的。

 

因此不说服务自愈，哪怕在咱们平常的故障处理当中，也很依赖于经验。就是说这个东西是能作的，可是咱们不太敢，由于要考虑的要素不少，就不太敢去直接作自愈这一块。

 

石鹏：没错，自己其实它是一个体系化的工程，不只仅是跟监控相关。我这边的一个想法是这样，关于自动治愈这块，咱们可能仍是要更多去依靠业务侧的能力。就是说，业务侧要具有一些这种架构设计上的考量，好比说架构的柔性，能够本身去作限流、降级、作熔断，这要求业务侧有这样的能力才能够，而不是说仅仅依靠监控系统去作某些动做触发。

 

至于说一些算法和策略的话，以前美图这边也是有过一些简单的尝试，应用不算很是普遍。但业界的话，DataOps、AIOps的概念也是比较火热，这些东西在像BAT这些公司其实也有一些实际的应用已经在落地了。

 

以前咱们作的话，有作这么几个小东西，关于故障预测是有这么几个算法：有同期的数据比较、同期的振幅比较、有一个移动平均算法、而后再有一个变点监测。而后这几个的话，能够简单说一下思路，其实也比较好理解。

 

• 同期数据，是我按照周期，好比说今天某个时间点这个数据，我去比较昨天这个点是什么样子的，去比较数据；

• 振幅，其实它就相对更柔性一点，里面会给你加上一个权重，加上一个比例，好比正态分布里边的3-sigma，做为振幅系数去比较同期的数据，看在算上振幅以后，你是否是已经超出了，去作一个预测；

• 变点监测，就是说我总体的数据曲线是什么样子的，忽然出现了一个离我正常预测曲线偏离很是远的一个点，这种的话会有一个这样的算法来作这个事情。

 

而后这块相对比较成熟的工具的话，像腾讯以前有开源的运维学件METIS，它里面集成了很是多的算法模型，这个有兴趣的同窗能够去作一些了解。

 

Q5：监控大屏是怎么设计的？

 

蔡翔华：首先从技术自己来讲，5.0版本能够看到Zabbix的UI都很不错，能够不少的组、主机都往大屏里面去拖。大屏的话，咱们大概会分几块：

 

第一块是整个系统运行状态。我可能整个系统有从用户登陆到用户支付，包括到购物车等等，有一个链路。我对于每一个链路其实都会有一个监控，它每个S组 Service的组，那么Service的组里面包括它的应用、数据库缓存、应用系统甚至硬件服务器，一旦这里有任何东西出问题以后，直接会在大屏上显示一个警告，那么我就会知道如今整个生产环节哪一个系统是有问题的。

 

那么另外就是一个summary，一个overview的全局的导览，由于一旦我知道这个有问题，我就但愿更加细化知道这个东西哪里有问题。那么在下面就会有一个trigger list的问题列表，就是说有哪些触发器被触发了，我会看到比方说，数据库端口不通了，仍是说磁盘空间已经满了。下面会有trigger list，而后这个trigger list会按照故障等级是disaster仍是warning，同时对应的管理员或者运维人员也会收到这个短信，就知道要当即去处理了。

 

因此咱们尽量就在大屏里从两方面来把控，一方面从大的来说，有一个over view看到全局，从小的来说，我要知道个人故障发生在哪里。基本上保证这两个要素在大屏里面就OK了。

 

刘宇：咱们这边大屏其实主要仍是应用的维度以及网络流量的维度为主。好比说从公网的一个出口和入口的流量来看会不会有大面积的一个问题。若是发现已经达到外面防火墙或者它流量的一个阈值了，就能够迅速定位问题。

 

若是是细节的话，咱们会在大型活动前夕，梳理活动链路上的全部应用，根据应用的维度来设计这样一个大屏。大屏能够看到链路上全部应用、数据库或者是中间件的状况，一旦哪一个应用的QPS高了，或者是其余压力的状况，就能够第一时间定位到问题出如今哪里，是这样一个思路来作。

 

石鹏：监控大屏作得好，确实能够辅助咱们技术同窗去更快地定位和排查问题，还有一个比较重要的点，我是这么想的，就是老板会关注。有些公司会把大屏设计得很是有科技感，让老板看的话，可能老板也以为个人技术团队还挺牛的。固然这是一个题外话。

 

前面蔡老师和刘老师都给了一些建设上的思路，就是你应该去包含哪些数据，应该怎么去作。这方面的话，个人一个思考是你可能要去作服务的梳理，而后能够以分块、分业务或者说按照分层的方式来作。

 

分块的话，就是你按照业务线来分。你公司可能有不少块业务，而后按照不一样的业务去提供一个视角。在每一个业务里，你能够去作分层，分层的意思就是说能够把整个链路，从客户端一直到CDN、 DNS链路，而后到LB入口层，以及应用这一层是什么样的，再关联到后面的一些后端资源，像数据库、缓存这些东西，还有一些其余的周边依赖，按照这样分层的方式来作。

 

具体实践的话，能够跟你们作个预告，最近咱们美图有一些实践经验能够分享，近期会把一些完整的设计思路和细节放出来，你们能够期待一下，持续关注dbaplus社群的发文。

 

关于技术实现方面，我简单赘述两句。咱们公司的监控大屏是用了Grafana来作的，Grafana可能已经成为了事实上的监控UI、数据可视化的标准了，它能够后面去接各类各样的数据源，而后你各个监控系统、各类数据原理的数据能够统一来展现。

 

这里须要感谢一个社区的插件，叫Flow Charting，这个插件能够很是好地去作监控链路的事情，就是你能够用这个插件去把整个链路关键环节，以这种图的方式绘制出来，而后给每个点、每一条线绑定上监控数据，最后生成的图就动起来了，就能够看到一个全局性的链路状态：从入口一直到后端资源，包括各类依赖，当前它的状态是什么样子的。

 

固然这个前提是，你整个链路的监控数据是要完备的，而后你才能够借助这个插件去把它呈现出来，大概是这个样子的，在这个图上就一目了然了。

 

Q6：自动化运维管理是Zabbix和Prometheus同时使用仍是二选一更合适？

 

蔡翔华：若是是个纯容器化的，就说你环境里面全是Docker，那么说实话我也不推荐你去使用Zabbix。

 

由于Zabbix对容器的监控，虽然官方已经开始重视了，甚至说如今也支持了Prometheus的不少metrics和exporter这种方式去作监控，就是它也能够原生的去支持Prometheus这些东西，但相对来讲，Prometheus在容器化监控这边仍是会更好一些。

 

若是你的监控需求是又要监控硬件服务器，又要监控中间件，又要监控业务指标，那么我推荐使用Zabbix，由于Zabbix覆盖的面会更广一些。

 

的确我以为任何需求Zabbix和Prometheus均可以去作，可是从实现成原本说，相对于Prometheus，你的服务环境越复杂，Zabbix可能就越适合这种比较复杂的异构的环境。

 

刘宇：咱们目前公司状况是两个都在用，的确是偏容器的会往Prometheus优先考虑，若是是旧的，好比说是有偏服务化的这种监控，也会慢慢地往Prometheus作一些迁移。

 

若是你的环境是一种就能够知足的话，建议仍是一种，由于毕竟只须要维护一种技术栈就能够了。或者是你能够作一些偏重，好比说把一些不变的放在一种上面，常常会变的放在另一种上面。尽可能去减小你维护的技术栈。若是你的环境比较简单的话，只用一种，固然是最好了。

 

石鹏：其实仍是看场景，美图跟刘老师这边比较相似，咱们也是多种监控工具在用，不过咱们如今没有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，还有不少基于大数据的一些流式处理的组件，咱们都是混合在用。

 

主要仍是看你具体的需求和场景，没有银弹，没有说一个工具能够很是合适去搞定全部事情。固然它有可能有能力，可是它并不必定特别合适。至于具体的选择上，仍是要看具体场景。比较明确的一个思路可能就是要看你的监控对象究竟是容器仍是非容器，它是这种易变的仍是比较稳定态的。这两个思路的话，也是跟蔡老师和刘老师比较一致的。

 

Q7：Zabbix和Prometheus在配合使用时，应该怎么分工？怎么落地？

 

蔡翔华：其实从场景来讲，Prometheus更适合容器。你能够看一下整个环境里，容器和Zabbix的占比，像刚才刘老师说的，这二者数据实际上是能够互相使用、互相监控甚至是互相触发报警，那么在Zabbix如今其实已经原生支持了Prometheus的这些exporter的功能，即便你没有Prometheus后端，Zabbix也能够直接去exporter上拿一些数据，经过Zabbix的一些逻辑和机制去报警。那么相同的，Zabbix也能够经过action把这些数据扔给Prometheus。

 

也就是说，你能够把它们二者当中的一个做为数据的采集器，另一个做为整个数据的逻辑处理的功能，相似于alert manager或者是在zabbix server同样，这样作的好处就是说，收集数据会很是方便，比方说Prometheus不能收集硬件数据，但Zabbix能够收集，咱们就用Zabbix收集，同时把它的数据扔给Prometheus，作一个统一的报警。这样的确仍是要维护两个平台，可是相对来讲，维护成本会有所下降，不须要对Zabbix那边作太多的模板，它其实只是一个数据采集器。

 

那么稳定性、可用性、性能及监控这些东西，其实也基本上能够基于Prometheus现成的这些规则、Zabbix现成的这些模板来作。其实Zabbix社区里面也有不少模板能够提供到。

 

关键我以为有一点就是，咱们要思考它模板里面提供的东西，是不是我真的须要的，由于不少时候你们以为我啥都要监控，但事实上不是这样子，只有真正须要关注的点，才是须要监控的东西。因此说你们在部署监控以前，要先思考一下监控的目的是什么。

 

刘宇：个人见解其实仍是这样，好比说偏基础的，像主机、网络这种能够用Zabbix来监控，偏服务类的和容器的，就用Prometheus来作监控。

 

咱们监控Redis的一个集群，在之前没有Grafana或者Prometheus的状况下，用Zabbix去看集群的总体状况就会比较麻烦，由于Zabbix依赖的监控的一个点仍是以host为基础的，因此你去看整个服务的话会比较麻烦。而Prometheus由于它是时序的数据，能够方便地去打一些你想要的标签，这样就能够比较方便地监控单个服务上一个总体的状况，因此服务这块来讲，仍是Prometheus比较方便。而前面其余蔡老师也说了，好比说硬件这种仍是Zabbix比较好用。

 

石鹏：OK，这个点上咱们理解仍是很是一致的。像如今美图这边，就单讲Prometheus和Open-Falcon，咱们基础的这些监控都是在Open-Falcon里，而后容器会在Prometheus里。

 

这里须要补充一下咱们的环境，如今咱们全部业务都是基于云上来作的，业务容器化程度的话，应该是只有个别服务没有容器化，整个比例应该95%以上都是容器化的。但即便是这样，咱们也没有彻底摒弃掉Open-Falcon。

 

咱们在这个容器里，容器层的这些服务，像servive、pod这些监控，好比说业务上暴露出来的metrics，这些东西咱们都是用Prometheus来作的。可是像k8s node节点、ECS，它自己的一些监控，包括一些网络质量的监控，仍是要有一个更适合作这种基础监控的平台来作。咱们就是在Open-Falcon里作的。

 

因此主要仍是看场景，怎么去侧重就是看你具体的需求了。

 

Q8：若是已经部署了Zabbix，怎么平稳过渡到Prometheus？

 

蔡翔华：若是已经部署了Zabbix，我估计你直接经过数据库去导入这种方式会很难作，由于它的表结构，包括一个是时序数据库，一个是TSDB，就没办法直接作。

 

我建议若是真的要过渡到Prometheus的话，能够仍然使用Zabbix agent，在数据采样完以后，把它扔到Prometheus，触发一些action去提供给Prometheus。这是一种中转方式。

 

另一种方式，我会经过一些ansible去部署一些Prometheus expoter到那些机器上去，把这些数据扔给Prometheus。其实也就回到刚才那个问题，我这边全部的数据均可以扔给Prometheus使用，去触发报警，这都OK的。

 

刘宇：若是真的要把Zabbix迁移到Prometheus，就是涉及到一个监控迁移的过程。我这边的建议仍是按照Zabbix先模块划分，好比说其中一个模块准备迁到Prometheus，而后首先会把这个模块Prometheus的监控也加上，会把两边的监控进行一个比较，至少Prometheus能把原来Zabbix的监控都能覆盖掉，不只是监控的覆盖，还有告警覆盖，这样一个并行的过程。

 

最终彻底可以达到同样的效果，我就能够把原来Zabbix相关模块的监控给下掉，是这样一个建议的路径。

 

蔡翔华：对，并且其实Prometheus和Zabbix同时存在并不冲突，并非说二者只能选其一。其实能够说，我先把Prometheus的exporter规则都配上去，两边同时监控，而后再根据需求，把Zabbix给下了，也OK，这是不存在冲突的。

 

石鹏：没错，既然你要平滑，那两边同时有，这应该是最平滑的。咱们以前是有从Zabbix迁到了Open-Falcon，迁移通过了一个比较长的耗时，大概用了一年多的时间。其实就是你把另外一边的监控也布起来，同时监控，而后逐步去下旧监控。在这个过程里，你还能够去比较二者之间是否是有差别，是否是都能知足需求，这样的话应该是比较平滑的。

 

Q9：分布式链路的可观测性和端到端诊断怎么作？

 

蔡翔华：分布式链路其实咱们没有用Zabbix，由于分布式链路要考虑上下游的关系，因此咱们会基于APM去作。如今像业内比较流行的CAT，能够参考这些去作。

 

端到端的侦测的话，其实Zabbix也支持，它支持两种方式：

 

一个是它能够在本地跑一些脚本去作，就是说我这个检测是从Zabbix某个Agen端出发，到另一台目标机器，而不是经过Zabbix server去作检测。因此说这是Zabbix 提供的另一种方式，Zabbix active的一种方式，它能够去实现这种端到端的侦测。Zabbix active的监控方式也是比较好的一种方式，能够减轻Zabbix server端的压力，或proxy端的压力，能提供更丰富的一些监控。

 

刘宇：这块由于Prometheus是一个基于数值的监控，对于这种全链路的话，通常不太会用Prometheus来作，基本上会用APM的一些分布式链路追踪的工具，好比skywalking等来作。

 

还会经过一些日志系统来作分布式的监控，在链路上，提早写入一些标签，这样从始至终均可以拿到整个链路上的一个关系，就能够作一些分布式链路上的监控的东西。

 

石鹏：是的，这也就回到咱们前面讨论的，没有银弹，没有一种技术栈能够解决全部需求的。包括Zabbix和Prometheus，其实更关注的仍是在偏服务端，若是是应用端的话，其实仍是要依赖一些APM的工具。就像刘老师说的Apache的skywalking，还有像鹰眼、基于open tracing的其余工具。这些东西其实都是一种思路。

 

还有一些有技术能力的公司，会选择自研一些APM工具，须要本身去开发各类SDK，而后须要迁到客户端，去上报数据，是这个样子的。

 

其实端到端总体的建设思路应该是分段的，客户端的是一段，中间链路是一段，服务端又是另一侧。因此想作端到端，很难说用一个工具就能够彻底覆盖起来。

 

如今基于云原生、微服务这些发展的比较火热，可能会有一些各个服务之间调用链路的服务治理相关的监控需求，可能也不是说经过Prometheus或Zabbix就能够很好地去完成。仍是要看需求场景，选择更合适的工具，而且组合起来使用。

 

Q10：大规模场景下，Prometheus和Zabbix的性能和成本哪一个比较低？

 

蔡翔华：首先我以为仍是看应用场景，由于大规模场景下，要看这个场景是容器多仍是非容器环境多，这是一个主要依据。

 

Zabbix性能的话，其实瓶颈主要是在数据库，只要把数据库的优化作得足够好，其实开头也说了，业内也有作到40万NVPS的这种案例，已是比较变态了。那无非就是说，去作数据库分区分库拆表、加SSD存储，经过这种方式。

 

成本的话，我我的以为在底层资源知足的前提下，成本应该都OK。由于Prometheus是基于exporter，Zabbix是基于Agent，经过Zabbix agent，配合自动发现和低级别发现的这种方式去实现自动化。

 

配置成本可能Zabbix会低不少，由于都是基于UI去作，而Prometheus是基于配置文件去作，这个可能Zabbix会更好些。因此我综合成本，以为Zabbix稍微会好一些，但仍是取决于你的场景里有多少虚拟化。

 

刘宇：我以为若是是性能的话，经过一些分区的手段都能解决。但若是是很是大的规模，经过Zabbix，其实它的数据库瓶颈仍是比较严重的，这块仍是须要一些比较好优化手段才能解决。

 

监控采集的agent的方式而言，我以为Prometheus的exporter作得很是全面，像咱们之前用Zabbix，基本上有不少东西监控都是本身去开发的；而如今用Prometheus，基本上对于这种采集器的开发都没有了，用社区的就能够所有解决了。因此在采集的层面上，去实现它最底层和服务的一个数据采集，我感受Prometheus的成本会更低一点。

 

固然由于Prometheus相对来讲仍是一个微服务的架构，它的全部组件都是分开的，在搭建成本、学习成本会稍微高一点。

 

石鹏：其实仍是要针对个性化的场景去作一些选择。成本的话，若是说你的环境是一个比较纯粹的，要么是全容器，要么是虚拟化或者物理环境，你就选一种就行了。若是说你是异构的话，可能就不可避免的要选两种同时维护。这两种里若是有所侧重的话，成本其实就会有所侧重，因此仍是看你的具体需求。

 

选型，在于抓住监控的核心

 

对于你们比较关注的监控工具选型，用一句话来归纳就是：没有最好的，只有最适合的，要具体场景具体分析。

 

总的来说，若是是比较纯粹的环境，好比是纯物理机、纯虚拟机，更关注一些偏基础设施层面的需求的话，Zabbix会是一个很是不错的选项；若是是容器化场景，Prometheus的适应性会更好；若是是异构的话，建议二者或更多其它工具结合起来使用。

 

纵观整个监控发展史，其实监控方案一直是跟随着行业技术、业务发展不断变化的。到如今，比较火热的技术像5G互联、物联网、人工智能……各类技术层出不穷，咱们须要去监控的目标对象也一直发生着变化。随着多云、混合云架构在更多行业里持续落地开花，容器、云原生等各类技术的蓬勃发展，对监控系统其实也提出了新的需求。

 

技术更新迭代速度愈来愈快，不少同窗不免会有一些焦虑的情绪。这种焦虑是不可避免的，咱们应该作的仍是要去抓住事物的本质。

 

针对监控这个需求，也就是说监控的核心是什么？

 

监控在高度抽象以后，无非能够这么来分：监控数据的暴露、数据的采集和传输、监控数据的存储和处理……这个过程里，包括各类优化、各类格式化处理等；最后是咱们怎么去用好监控数据，把监控数据的价值最大化，好比说咱们去作报表展现、作数据分析，像前面讲到的用一些DataOps、AIOps的算法、能力介入，把监控数据的价值挖掘出来。

 

这其实就是监控系统所要承载的功能，咱们要作的就是抓住这些核心路径里的原理，而后掌握它，其实也就OK了。

 

另外，咱们须要保持对这些新鲜事物的热忱，保持对技术的敏锐，要有行业发展趋势的感知能力。好比企业上云，其实从行业报告来看，从去年就已通过了上云的拐点，会有愈来愈多公司选择把服务迁移到云上；再看容器和云原生，会有愈来愈多的周边生态完善起来。咱们要有这样的感知能力，要可以感觉到这个行业发展的脉搏，而后作好相应的技术储备，只有这样，咱们才可能在技术的浪潮里作到从容不迫，才可以乘风破浪。