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

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

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

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

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

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

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

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

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

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

监控，为什么总让我们头痛

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

说起来，监控在不同的团队和公司之间，可能会存在各种差异化的需求。如何基于开源产品打造一个符合自己业务场景的监控体系，并且持续迭代？这成为了大家无法绕开的课题。

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

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

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

蔡翔华：我们和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这种方式，来把高可用维护起来。

蔡翔华：的确，存储这个问题因为监控写的东西最多就是写到存储里面去，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分钟一个点。就用这样的方式，把这个数据量级减小，然后以此来做存储问题的优化。

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

我碰到很多人说，打算监控它的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会做的更好一点。所以两个工具其实可以结合起来使用。

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

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

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

也就是说，你用户数从10变成了1万，这1万到底是因为故障了，还是说是因为业务的一些逻辑导致的，很难判断。所以目前来说，我们尝试以后，还是用了一些比较固定的报警预知去做。

那么回到这个话题，Zabbix本身它提供了一些预测的功能，它会预测现在我的磁盘消耗大约什么时候会消耗到20%以下，或某个阈值以下，它本身是提供了这个功能的。还有一些内置函数可以去做这个计算。但是目前来说，我个人还是建议使用一个比较固定的阈值，可以方便我们有一个明确判断，否则你早期会有很多的误报，甚至可能你都会觉得这东西很正常。

预测的数据也是基于现状的，如果可以对预测数据进行判断报警，理论上，也可以针对现有的数据进行判断报警。

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

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

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

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

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

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

所以不说服务自愈，哪怕在我们日常的故障处理当中，也很依赖于经验。就是说这个东西是能做的，但是我们不太敢，因为要考虑的要素很多，就不太敢去直接做自愈这一块。

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

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

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

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

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

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

然后这块相对比较成熟的工具的话，像腾讯之前有开源的运维学件METIS，它里面集成了非常多的算法模型，这个有兴趣的同学可以去做一些了解。

蔡翔华：首先从技术本身来说，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，这个插件可以非常好地去做监控链路的事情，就是你可以用这个插件去把整个链路关键环节，以这种图的方式绘制出来，然后给每一个点、每一条线绑定上监控数据，最后生成的图就动起来了，就可以看到一个全局性的链路状态：从入口一直到后端资源，包括各种依赖，当前它的状态是什么样子的。

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

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

因为Zabbix对容器的监控，虽然官方已经开始重视了，甚至说现在也支持了Prometheus的很多metrics和exporter这种方式去做监控，就是它也可以原生的去支持Prometheus这些东西，但相对来说，Prometheus在容器化监控这边还是会更好一些。

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

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

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

如果你的环境是一种就可以满足的话，建议还是一种，因为毕竟只需要维护一种技术栈就可以了。或者是你可以做一些偏重，比如说把一些不变的放在一种上面，经常会变的放在另外一种上面。尽量去减少你维护的技术栈。如果你的环境比较简单的话，只用一种，当然是最好了。

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

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

蔡翔华：其实从场景来说，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里做的。

所以主要还是看场景，怎么去侧重就是看你具体的需求了。

蔡翔华：如果已经部署了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，迁移经过了一个比较长的耗时，大概用了一年多的时间。其实就是你把另一边的监控也布起来，同时监控，然后逐步去下旧监控。在这个过程里，你还可以去比较两者之间是不是有差异，是不是都能满足需求，这样的话应该是比较平滑的。

蔡翔华：分布式链路其实我们没有用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就可以很好地去完成。还是要看需求场景，选择更合适的工具，并且组合起来使用。

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

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了。

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

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

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

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

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

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

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

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

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

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

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

监控，为什么总让我们头痛

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

说起来，监控在不同的团队和公司之间，可能会存在各种差异化的需求。如何基于开源产品打造一个符合自己业务场景的监控体系，并且持续迭代？这成为了大家无法绕开的课题。

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

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

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

蔡翔华：我们和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这种方式，来把高可用维护起来。

蔡翔华：的确，存储这个问题因为监控写的东西最多就是写到存储里面去，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分钟一个点。就用这样的方式，把这个数据量级减小，然后以此来做存储问题的优化。

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

我碰到很多人说，打算监控它的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会做的更好一点。所以两个工具其实可以结合起来使用。

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

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

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

也就是说，你用户数从10变成了1万，这1万到底是因为故障了，还是说是因为业务的一些逻辑导致的，很难判断。所以目前来说，我们尝试以后，还是用了一些比较固定的报警预知去做。

那么回到这个话题，Zabbix本身它提供了一些预测的功能，它会预测现在我的磁盘消耗大约什么时候会消耗到20%以下，或某个阈值以下，它本身是提供了这个功能的。还有一些内置函数可以去做这个计算。但是目前来说，我个人还是建议使用一个比较固定的阈值，可以方便我们有一个明确判断，否则你早期会有很多的误报，甚至可能你都会觉得这东西很正常。

预测的数据也是基于现状的，如果可以对预测数据进行判断报警，理论上，也可以针对现有的数据进行判断报警。

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

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

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

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

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

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

所以不说服务自愈，哪怕在我们日常的故障处理当中，也很依赖于经验。就是说这个东西是能做的，但是我们不太敢，因为要考虑的要素很多，就不太敢去直接做自愈这一块。

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

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

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

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

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

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

然后这块相对比较成熟的工具的话，像腾讯之前有开源的运维学件METIS，它里面集成了非常多的算法模型，这个有兴趣的同学可以去做一些了解。

蔡翔华：首先从技术本身来说，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，这个插件可以非常好地去做监控链路的事情，就是你可以用这个插件去把整个链路关键环节，以这种图的方式绘制出来，然后给每一个点、每一条线绑定上监控数据，最后生成的图就动起来了，就可以看到一个全局性的链路状态：从入口一直到后端资源，包括各种依赖，当前它的状态是什么样子的。

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

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

因为Zabbix对容器的监控，虽然官方已经开始重视了，甚至说现在也支持了Prometheus的很多metrics和exporter这种方式去做监控，就是它也可以原生的去支持Prometheus这些东西，但相对来说，Prometheus在容器化监控这边还是会更好一些。

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

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

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

如果你的环境是一种就可以满足的话，建议还是一种，因为毕竟只需要维护一种技术栈就可以了。或者是你可以做一些偏重，比如说把一些不变的放在一种上面，经常会变的放在另外一种上面。尽量去减少你维护的技术栈。如果你的环境比较简单的话，只用一种，当然是最好了。

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

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

蔡翔华：其实从场景来说，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里做的。

所以主要还是看场景，怎么去侧重就是看你具体的需求了。

蔡翔华：如果已经部署了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，迁移经过了一个比较长的耗时，大概用了一年多的时间。其实就是你把另一边的监控也布起来，同时监控，然后逐步去下旧监控。在这个过程里，你还可以去比较两者之间是不是有差异，是不是都能满足需求，这样的话应该是比较平滑的。

蔡翔华：分布式链路其实我们没有用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就可以很好地去完成。还是要看需求场景，选择更合适的工具，并且组合起来使用。

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

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了。

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