案例|华为对Zabbix的3个探索:水平扩展、数据实时消费及网络体验监控

本文整理自肖骏在2020Zabbix中国峰会的演讲，ppt可在网盘获取:https://pan.baidu.com/s/1KL58mpRWcYl4UmBtJbvFDg  密码:ew3p。更多演讲视频可关注官方Bilibili账号主页（ID：Zabbix中国）。

  一 Zabbix在华为的实践历程  

首先介绍华为IT生产环境，华为IT是内部支撑的IT，人数庞大，它对应的IT系统也很庞大，主要包括办公系统、HR系统、财经系统，还有运营商系统等等。

我现在负责华为的全链路压测服务，今天分享的内容包括：Zabbix建设历程，业务体量，架构设计，后面我会分享我们做的三个探索实践。主要是水平扩展，数据实时消费，还有网络的体验监控。

首先看一下华为的一个Zabbix的实践历程，在2015年，华为商城引入了Zabbix，当时使用的Zabbix2.2版本，主要是监控VMall公有云的主机，中间件数据库等，在2016年看到在VMall试点很成功之后，在内网也引入了Zabbix，引入的是3.0版本，覆盖的是主机中间件数据库监控，在2016年试点完之后，在2017年在内网全部铺开了，将ZabbixAgent作为主机监控的标准Agent，存量机器也全部覆盖了。

在全部覆盖之后，在2017年和2018年替换掉原来的Patrol监控，Patrol监控是一个比较老的软件，它面临一些问题，它的监控配置是需要人工手工去上面配的，每新加一个监控项，或者说修改一个监控项。都得上Patrol的界面，去每一个Agent的上面配一下，太影响效率了，而且它的监控数据不能实时消费，也是比较影响监控效率的，用Zabbix把Patrol替换掉之后，可以实现监控策略的自动下发，监控数据是可以实时消费的，就极大地提升了监控效率。

在2017~2018的时候，尝试了做一些网络体验监控，在华为的市场大会都有做的网络设备的监控，在那种运营大屏上展示，当大规模展开之后，单靠Zabbix是满足不了需求的，就得搭很多套的Zabbix，就会有一个Zabbix集群。在2018年做了一个探索，做了一个高可用建设，实现了多套Zabbix的集中管理,就是说Agent可以在集群间自由迁移。

  二 业务体量  

接下来看一下我们的业务体量，我们的业务范围主要分为三大块，第一块主要是主机/中间件监控，第二块主要是端口拨测监控，第三块是网络监控。其中主机/中间件监控主要使用的是Zabbix Agent功能，端口波次监控和网络监控使用的是Zabbix proxy ping监控能力。

大家可以看一下我们的数量级，主要的监控数量级都是10万级以上的，这种规模还比较大，监控频率主要都是按需，有的是分钟级，有的是一分钟级，那种要求最高的是网络体验监控，是一秒级。我在后面会讲到。

  三  架构设计  

接下来讲一下我们监控的整体架构，监控的覆盖范围是很广的，它覆盖了I层P层S层的监控，左边可以看我们的业务范围是很广的。为了做这些监控，有一个监控策略，统一管理平台，类似于对标Zabbix 的trigger，但是它肯定不只，就是说Zabbix因为有很多的监控工具，它其实就是一个告警阈值项。在监控策略管理平台上统一管理，监控策略会下发到监控探针，由所有的探针去做数据采集，并且做告警，我们的Zabbix就在监控探针这一层。当监控探针采集完数据之后，会把监控数据受到一个监控数据底座中做一些更高阶的处理，包括一些实时计算、聚合分析，把它生成那种更高阶的一些运营数据，供用户和领导查看。

我们的告警数据走的是另外一条路，有一个统一告警平台，会做一些 告警的处理，包括它会生成事件，给到指定的责任人去进行处理，会跟自动化平台做结合，做治愈处理。就是监控数据跟告警数据都会统一汇聚在用户入口。有一个IT Monitor门户网站，用户可以在这个门户网站上进行查看，也提供标准的消费API,监控数据跟告警数据都是可以通过API实时消费出去的，就从监控数据的生产到加工，到消费到展示整个一条链路都拉通了。

讲完监控的整体架构之后，讲一下Zabbix的整个架构，从下往上看，Zabbix就分为Agent层，Proxy层，Server层，因为是全球分布式的一个公司，我们的Agent跟Proxy都是分布于全球的，Server可能主要集中在我们的数据中心，东莞的数据中心上，为了管理这么多的集群，在上面还有一个数据跟服务层，这数据跟服务层它主要有一个就是Zabbix高可用管理，因为你这么多集群它是要管理的。

还有一个监控策略管理，也就是刚才我说到的监控策略统一管理平台，还有监控数据的存储分析和处理，这种是监控数据的一个更高阶的分析功能。还有告警信息处理，在数据跟服务层上面还有一个可视层，给用户去查看，做一些操作，还有告警的通知和自动修复，类似于这样一些功能。

  四  水平扩展方案  

讲完架构之后，后面就讲几个我们自己做的一些探索。当Zabbix Agent的数量多了之后，那么就会面临问题，就是一套Zabbix Agent是满足不了我们的情况的。在2017年的时候做了一下调研，发现业界最佳实践一套Zabbix监控的主机数量大概是2万左右。昨天在这里会议交流的时候，发现好像有公司能把一套Zabbix的NVPS做到6万，是比较厉害的，待会应该会有讲师会讲到，也想学习一下。

这里我先讲一下我们的一个解决方案。因为Zabbix的瓶颈是在数据库上，就在MySQL那一层做了一些优化，用物理机加上存储的方案提升数据库的性能，这样可以将单套Zabbix的监控数量从2万提升到4万，但是4万这个量级还是不能满足需求。

因此就必须要构建多套Zabbix，但它会带来一个集群管理的困难，你有单套的时候你比较好看，你每天上班去一套Zabbix上面点一点，你就知道整个情况。当你数量很多的时候，你就没法说我上班的时候我这一套点一点，那一套点一点，你就点了很多，希望有一个统一管理的页面去看所有Zabbix性能情况。

第二个问题，当你多套Zabbix的时候，Agent是打到标准镜像里面去，新增一台主机，Agent会自动连到一套Zabbix。比如说Zabbix01上，业务规模扩大很大，Agent真的很多，所有的Agent的都会往Zabbix01上面挤，这样Zabbix01是永远就面临它的性能瓶颈问题的。这时候就需要有一个水平迁移的功能，将Zabbix01上面的Agent无损地迁移到另外一套Zabbix去，就保持所有的监控都不丢。

还有一个问题，Zabbix它作为生长环境的主要监控工具之后，它的重要性是日益提升的，你每一套Zabbix都不能出问题，因为你一出问题，就会有很多机器的基础建构是失效的，这种风险是很高的。Zabbix的高可用也提上了日程。

为了解决上面三个问题，第一个是集群管理的问题，第二个是Agent迁移的问题，还有一个高可用管理的问题，所以设计了一套方案。

大家可以看一下示意图，我们在进行迁移的时候，定义了一下每一个Host它会有标准项和非标准项。标准项是那种配置了主机的自动发现，在自动发现的时候它会自动关联一些基础模板，基础模板主要是比如说CPU、内存文件系统类似于这些标准的监控，但是每一个主机它还有一些非标准的监控，因为Zabbix它这种自定义监控是很强大的，你可以在每个主机上配置很多那种自定义监控，但自定义监控你没法用统一的那种策略管理去管理，你只能把它留在Zabbix上面。但当你迁移的时候，你这种非标准的监控项，你是不好迁移的。像示意图一样，你迁移的时候，我去改Agent的配置，把它Agent的Server的指向筹一套，指向另外一条的时候，那些标准的监控项它会迁移，但是非标准的监控项它会留在原来的地方。这时候就构建了一套配置总库，配置总库它将每一套Zabbix所有的那些监控配置数据都保存在一起，去配置总库时，拿出这些非标准的监控项也进行迁移，这样我就可以实现：

第一，Zabbix Agent在集群间自由迁移；

第二，我所有的配置数据都在配置总库里面，虽然说每一套Zabbix是做了高可用的部署，比如说Zabbix server我是有组备的，Zabbix DB我也是有组备的，但是高可用这个东西，你多考虑一点总是没错的。所以用了一个配置总库去保存所有的配置。当你一套可能面临那种极端情况的下情况下，它所有的东西都丢了的时候，配置总库也是可以去拿出它所有的那种配置信息，就实现了多套的Zabbix集群统一管理，也支持Zabbix的集群的水平扩展，当你一套挂了的时候，我可以快速将这一套的这些Agent，迁移到另外一套里面去。

关于配置总库我详细讲一下。配置总库构建大部分是基于Zabbix原生的表结构去构建的，取数据是通过Circle 去每一套Zabbix上面取比较关键的这种监控项，监控的那些配置项，把它存到配置总库里面去。在迁移的时候，标准项会对比一下类似于一些trigger的状态，因为标准模板里面也有一些trigger可能是会打开或者关闭。这种会去更新，标准里面就不去做增删改。非标准项，通过从配置总库里面拿出那些关键的监控配置数据，通过Zabbix API在新的那一套Zabbix面把它给创建起来。

这里有一点也讲一下，我们尝试过，就用Circle去创建那些非标准项，因为你用Circle可以大批量创建，这样效率会很高，但是梳理了一下，Zabbix创建新的item、trigger、host的操作，每个操作它的Circle大概都有100多个，100多个Circle，它中间有很多校验的过程，这样的方式它会相对比较安全，但它很损耗性能。看到那100多个Circle也无从下手，就没有通过那种Circle的方式去创建，通过Zabbix API的方式去创建,这里会导致性能会有点差.大规模迁移的时候会有点慢，这样迁移标准项是可以迁移的，至少能保命，非标准项这样在一段时间内迁移过去，这样也能接受。

还有一点刚才说的Zabbix API因为它很多那种校验的Circle,导致性能很慢，在其它的场景下面遇到一个坑，当数量上去之后，使用多线程去调Zabbix API来创建新的Host、item和trigge，r它因为有性能问题，它可能会处理不过来。它有一个ID自增的表，里面会存一些ID数据，它跟实际的配置的表会对不上。比如说Agent表有一个Agent ID，它在自增ID的那张表里面，它会存一个10000，但是你多线程去调的时候，Agent表里面它的AgentID已经到10,001了，你下一次调的时候，自增ID的数据它会增一，它会从10000增到10,001，你Agent表里面10,001已经存在了，这个时候你就会操作不下去，它会报错。下一次调Zabbix API的时候就会报错，它永远会卡在那里，你永远创建不了新的，你也删除不了老的。

这里没有做太多的深入的研究，用了一个比较土的办法，我定时在ID表里面做一个自侦，写一个定时任务，做一个自侦。这样就可以避免你在创建的时候导致ID一样，你就创建不了新的，这个就是小小的吐槽一下。通过这样一套，实现了Zabbix的水平迁移，还有高可用建设。

  五  数据实时消费方案  

接下来就讲一下我们的一个数据实时消费方案。就当你把监控布好之后，你的监控数据消费肯定是一个大头，包括用户跟领导都希望监控数据能够很实时的，最好你采集完你就能在页面上给我展示出来其它页面而不是Zabbix的页面，针对这一个也搞了一套方案。因为Zabbix的数据本来是存在MySQL里面的，你如果直接对MySQL进行大批量的消费，它会影响性能。它的适用性可能没有那么好，通用性没那么好。

大家可以看一下这套方案，我们在左边，有一秒级的监控，可以实时监控，监控数据采集完通过Zabbix发送到数据库，数据库它主从复制它会产生BinLog，BinLog里面记录了一些新增的那些历史数据，取出这些历史数据来，在redis缓存了那些配置数据，把历史数据跟配置数据一起结合，就生成了那种可供消费的数据，它发送到Kafka，发送到Kafka之后，会用Flink做一些更高阶的处理。

因为要求的是高度实时，Flink它是一个流计算平台，可以将数据做更高级的加工，发送到logstash、elastic search，通过实时管道，可以把整个耗时控制在5~10秒左右，数据送到elasticsearch之后，会提供API，供用户去实施消费。我们也会有页面，供用户实时消费。像用户可能在这里就只需要做一些很简单的处理，它就可以在页面展示出来。这样整个数据从产生到展示，整条链路大概可以控制在10秒左右，这个时延是可以接受的，因为当量级大了之后，你是不可能做到那种特别实时的，有10秒左右是可以接受的。

这里分享一下我们的一个例子。每年在有一些展会上，会展示一个网口，在现场展示一个网口，上面有一个对应的运营页面，你可以实时插拔网口，过一小会你就能看到运营页面上网口的状态的变化，你把它拔出来，稍等一小会，运营页面上网口它就变红了，你把它插上，过一小会它就变绿了。

这是一个很好的展示效果，也证明了数据实时消费的能力，关于数据实时消费详细讲一下。传统的这种数据消费方案可能是它采集器采到可消费的数据，送到Mysql，通过API发送到Kafka，Zabbix数据是采集到原始数据，发送到Mysql，使用了一个转换器，把它发送到Kafka，供用户消费。大家可以看一下转换器，转换器Zabbix Agent采集完数据之后，它会通过server发送到Mysql，主从复制它会产生BinLog。

BinLog里面会有几张表，对那5张表进行监听，只要那张表里面有数据更新，就把它采集出来，采集的原始数据类似于这种形式。item_ID、value还有时间戳，但这个数据你是没法给用户直接消费的，因为用户是不理解这个东西是什么含义，这时候从Mysql 的存库取一些那些配置数据，缓冲到redis里面，类似item ID, item key, host name, 通过ETL将这两个数据通过item_ID整个结合起来，这样它就具备了可消费数据的那些基本的要素。

它可以有Item ID代表它的意义，host name代表它的对象，value代表它的值，时间戳代表它的时间，这样整个它是变成可消费的数据。整套方案它对数据库的消耗是很小的，因为读BinLog，它对数据库基本上影响很小，而且通过Mysql去Mysql的存库里面读配置数据影响也很小，而且它是高度实时的，因为实时监听BinLog而且用了拉力式缓存，这种都是时延很小的，这样就能实现整个链路的那种低时延的数据消费。

  六  网络体验监控方案  

我介绍一下做的一个探索性工作就是网络体验监控。首先讲一下，华为公司有一个比较伟大的愿景，把数字世界带入每个人每个家庭每个组织，构建万物互联的智能世界，这是一个很伟大的愿景。在公司内部已经实现了一个比较基础的互联世界，因为大家都是用电子设备进行办公交流，所有的设备都是联网的，这种是一个比较基础的互联的世界，但因为公司是高度全球化的公司，所有的人都分布于全球，那么会面临一个很重要的问题就是网络问题。

网络问题就是因为网络线路会经过很多地方，它可能会有一些时延，时延突变，丢包类似于这些动作，它会影响到用户的一个体验。比如说南非的同事在观看东莞的直播的时候，可能因为一个时延突变，它直播就卡顿了。比如说南非的同事在跟东莞的同事进行会议，还有进行投影类似于这样，可能因为一个丢包导致整个链路就断了。这个时候网络管理员感知不到的，因为网络监控大部分的监控频率不是很高，可能那种秒级的一秒级的那种时延突变，还有丢包，对于用户来说影响是很不好的，就是我的体验很差.如果说我心情差的时候，我看了精彩直播，你给我卡顿一下，我都想拍桌子那些这样，但是网络管理员感受不到。这就是一个很大的问题。

为了解决这一个问题，就引入了那种网络体验监控，网络体验监控就是对用户访问应用的网络时延、丢包、时延突变等指标进行实时监控，确保用户拥有良好的体验。是很高度实时的，定义为一秒级，因为这样才能协助网络管理员去发现问题，后面才好针对这些指标去进行改进。可以看一下用户访问我们应用的示意图，它中间会经过很多的网络设备，比如说用户终端AP，AC还有数据中心，这里可以简单介绍一下，像用户终端可能就大家用的电脑手机，AP就是大家头顶上的那种无线路由，AC可能是存在于每个办公园区，或者说每个楼里面的一个网络设备，数据中心大家应该都知道，当然了这只是一个比较简化的示意图，实际的网络线路比这个要复杂。

也可以看到从用户到应用这一侧，整个数量级别是在不断降低的。用户终端它可能是10万级或者百万级的，AP可能是万级的，AC是千数量级的，数据中心可能是十数量级的。因为我们是做了探索性工作，选定了AC到数据中心的那一段，我们这栋楼的网络到数据中心的那一段，因为用户到AP到AC到我们这栋楼的这种网络还好，就是整个耗时还好，AC到数据中心是能够比较接近真实场景的。

选定了这一段的时候会面临一些问题，如果说所有的数据中心，对所有的那种AC点都进行监控，那种监控数据量会很大。这里做了一个模拟，比如说有1000个AC，有15个数据中心，有时延跟丢包两个监控指标，因为Zabbix只支持时延跟丢包，时延突变可能后面我会讲到，这样每秒监控数据就有3万，对应Zabbix的NVPS是3万，这样它会很消耗那种监控资源，可能你要搭多套来确保它的实时性，这个就很耗资源，它每天产生的监控数据大概是26亿。对比一下生产环境的监控业务量，生产环境监控大概数10万的监控对象，每天的监控数据是数10亿，这里如果只对1000个AC就进行监控，就产生这么多数据，它会带来太多的问题了。不仅是监控资源很高，整个数据管道，设备消耗也很高，包括数据湖所有的那些消耗资源都是恐怖的。

如果简单的使用这种监控方式，肯定是不行的，那么就想到其它办法，其它办法就是发现网络是有拓朴的，网络的拓朴它跟那种地理拓朴是接近的，而且网络访问它都是就近访问的。比如说南非办公园区的一位同事访问东莞的应用，那么肯定是先访问南非的AC点，南非的AC点接入到南非的数据中心，南非的数据中心在接入东莞的数据中心，这样可以把整条链路拆分一下，进行分段监控，再把数据加核做一个处理。

为了构建网络拓补，使用了一个低频监控的一个方式，比如说我有一个AC点，所有的数据中心都会对它进行一个时延监控，比较低频的。取它时延最小的值将AC归属到数据中心上，这样就能够构建一个网络拓扑。比如说AC点是南非的，那么它到南非的数据中心，网络时延肯定是最低的，它到其它的数据中心时延肯定更高，我可以把这个AC点归属到南非的数据中心，我们的网络拓扑这样就能构建出来。

只需要每个数据中心对归属于它的AC点进行实时监控，每个数据中心之间进行实时监控，这样我就可以极大的减少监控数据量。而且如果说我要知道就是一条AC，到比如说东莞的AC到南非数据中心的时延，可以通过两者求和得到，丢包也可以通过一些计算得到，这样就极大的降低了监控数据量。还是以数据为例，比如说有1000个AC，15个数据中心，监控指标是2000，每秒的监控数据从3万可以降低到2000，每天的监控数据量可以从26亿降低到大概1.7亿，这种倍数是降了很多的，而且实际AC数量会比高，数据中心数量也会比高，实际降低的监控数量其实很多的，这样可以减少很多的那种资源消耗。

这里还得讲一下监控指标这一块，因为Zabbix原生只支持那个时延跟丢包，那么时延突变是引入了那种实时计算的Flink平台，做一个取最近100次的时延值，求个平均，跟当前值做一个对比。这样就可以得到以时延突变的一个指标。还有丢包，也是做了一个简单的处理的。取最近100次的丢包，通过Flink就做一个平均值计算，这样你就可以看到一条比较光滑的丢包曲线，这样就是用户体验比较好。

  七 经验分享  

讲完这些方案之后最后讲一些小提示，在做的过程的要点：

1. 就是数据库一定要分区，可能大家应该都是常识了。

2. Proxy可以打入到Docker里面，在Docker里面便于安装好。这样在扩展的时候就比较方便。因为proxy很多，之前装的时候，每次我都要去编译安装一次，这样太耗时了，而且可能有一些组件装的还比较麻烦，我把它打入到Docker里面，这样就很方便的扩展。
   

3. 面对防火墙的问题，可以将proxy前置，去解决大量防火墙的问题。

4. 可以使用过滤功能去除掉无效的监控项，我们购买了Zabbix的高级维保服务，会有老师上门服务。去年周松老师上门服务，就发现有一套Zabbix，性能异常的高，NVPS异常的高，就一直在排查，发现有一个网络自动发现的监控，有很多无效的网卡，在一直监控采集数据，导致NVPS异常的高。在自动发现那里加了一个过滤的功能之后，过滤了大概100万的监控项，整个NVPS就降低了，跟其它的一些在别时性能基本上是一致的。

我今天分享就到这里，谢谢各位。