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

“和大家分享华为对Zabbix的三个探索实践,为了解决集群管理、Agent迁移、高可用管理问题,设计了水平扩展方案。为了实时监控数据实时呈现,设计了数据实时消费方案,还有为了构建万物互联的智能世界,设计了网络的体验监控方案。
——肖骏,华为技术有限公司,SRE


本文整理自肖骏在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就降低了,跟其它的一些在别时性能基本上是一致的。

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

    ppt可在网盘获取https://pan.baidu.com/s/1KL58mpRWcYl4UmBtJbvFDg 密码:ew3p

猜你喜欢

转载自blog.51cto.com/15094852/2630968

相关文章