2024 Zabbix中国峰会 关于我们 联系我们 加入我们
5

案例|Zabbix在江苏电信的应用及经验分享



本文来自江苏电信智能云网调度运营中心张哲峰在Zabbix Meetup南京站的演讲,张哲峰也是Zabbix中文手册译者,感谢张哲峰对社区的大力支持!

云计算在江苏电信是一项比较新的业务,只有十几年的历史,不像核心网等传统通信业务,由一或几个厂家主导,可以提供一个非常完善的网管,因此云底层的监控天然具有解耦性。一路走来,从最初的人工巡检、写脚本执行定时任务,到采用的定制化网管商业产品。从17年左右,江苏电信开始积极拥抱开源,选择了Zabbix作为集中监控系统,最终融合江苏电信自研云运维平台——凌霄,成为监控的底层实现模块。
Zabbix作为一款成熟的开源产品,在江苏电信的应用非常广泛。省管平台中的CT云,也就是我们部门负责维护的私有云,主要是底层硬件,共计10000+主机,是省内最大规模的监控;其次是IT云,以虚拟机监控为主,也有10000台以上的体量;除了云之外,Zabbix还承载了诸如核心网、数通等专业部门的通用硬件和业务系统约5000台的监控量。
江苏电信的专业子公司,号百、智恒、全渠道,地市分公司维护的行业云、政务云以及一些自建的业务平台,也都应用了Zabbix进行监控。此外电信负责的一些客户项目,比如说华泰桌面云、苏果混合云,也选择了Zabbix作为底层监控系统。总而言之,Zabbix在江苏电信应用规模大、范围广,可以说是监控的中流砥柱。

图片

聚焦到我负责的私有云方面,去年完成物理机上云后,版本从4.0升级为6.0,采用的是docker部署的双server高可用架构,后端采用Postgresql+timescaledb的时序数据库插件,通过电信内网连接位于其他资源池的proxy。系统划分为两套,一套位于吉山数据中心,负责仪征资源池的监控,另一套位于仪征数据中心,负责仪征以外资源池的监控,两套Zabbixagent和web拨测的方式相互监控。我们维护的云底层,硬件设备包括网络设备、服务器、磁阵等,涉及华三、华为、中兴、浪潮、曙光等,可以说几乎涉及所有主流厂商,硬件监控方式以snmp get方式为主,这是传统的网管协议,绝大多数产品都支持,不过具体监控效果就取决于厂家的的协议实现,此外有一些不支持snmp协议的老旧设备,我们用ssh监控方式通过运行脚本登录巡检的方式加以补充。
在软件方面,主要涉及虚拟化软件,比如vmware的vsphere、中电数智,也就是电信自研的基于openstack的虚拟化产品,分布式存储,比如华为等厂商的存储软件,以上软件都支持snmp trap,先将告警发送至内部私网的proxy,再送至外部的server,此外还有一些软件的监控通过厂家开发的Zabbix trapper程序。除了软件硬件,我们内部的操作系统、零星的内部运维系统也会通过Zabbix agent监控,进行常规的端口、进程、自定义监控项,以及通过HTTP拨测业务API等。
虽然Zabbix的功能强大,但是随着使用的深入也逐步发现一些系统之外的问题。随着资源池的增大,一次扩容动辄成百上千,手工添加监控已经人力所不能及,此外随着主机群组、用户、告警方式的增多,账号的权限、告警条件的设置都变得非常复杂容易出错,此时再指望完全由个人去维护监控就变得不太现实了。为了解决这些问题,我们将省内的云运维平台——凌霄平台与Zabbix结合起来,通过平台去管控监控的生命周期。凌霄平台主要做了两件事,第一是由CMDB保证资源的准确,通过调用ZabbixAPI实现监控任务的下发,第二是Zabbix不直接调用告警系统,而是将告警汇聚至凌霄平台,由平台去做告警的预处理和订阅,确保派发策略的可见和统一管理。

图片

当有新设备入网时,集成人员准备好网络环境、设备资料,在设备上完成snmp配置;Zabbix系统管理员完成proxy的部署和群组创建等准备工作;维护人员在CMDB中录入信息,平台进行规范稽核后完成录入,实现主机的创建和关联对应模板,这样三路并进,全部完成之后新设备的监控就完成了。通过这样的方式,首先极大的提高了工作效率,可以一次性下发大量的主机,迅速完成扩容设备的监控纳管;第二,通过CMDB确保了资产的准确,资产录入是在一张excel表完成,表格的设计原则是”尽量避免人工填写、尽量避免重复信息“,一些相对固定的字段比如厂家、型号,采用下拉表格的方式进行选择,尽可能避免人工填写可能导致的错误,而设备的名称也有明确的规范,包含了平台、机房、机柜等物理信息,通过多个字段拼接合成,确保命名不会重复,第三,监控下发过程全部由平台完成,确保不会出现人工操作的比如遗漏和错误,我还将snmp无数据设置为了告警,确保监控项的有效性,第四,取消了普通用户Zabbix账号的操作权限,所有增删修改操作全部通过系统执行,每一步操作都有记录留痕,权责分明。

除了Zabbix之外,我们还有其他的告警源,例如天翼云、prometheus、内部业务以及外部客户的监控系统,如果在每一个系统中进行告警的处理会导致管理的碎片化,因此告警被统一汇聚到凌霄平台,实现告警的预处理和发送。首先实现了统一的大屏展示,对于值班人员接到告警工单时了解全局状况是十分重要的;第二可以对告警进行一些预处理,目前实现的主要是告警压缩和关联预警。在日常工作中有时会遇到告警风暴,比如网络问题导致的大量ping不可达,比如某服务器宕机导致的多个相连交换机端口dwon,在平台上可以自定义告警归并策略,例如按照相同主机、按照相同告警归并,以及根据拓扑将对端相同的交换机端口down告警合并,这样可以有效压缩告警数量,减少重复告警的打扰。除了归并之外,还可以进一步进行故障面的分析,实现告警到业务之间的关联预警,例如宿主机宕机会导致承载的虚拟机重启,此时平台会自动给业务维护人员发邮件通知,尽量减少业务中断时间。
告警经过预处理之后就通过各种媒介进行发送,目前采用的是短信、工单和即时通讯工具三种方式,三种方式各有利弊,因此需要相互补充。短信最为便捷,但是由于缺乏管控手段,也容易被忽略和遗忘。工单会通过语音外呼通知维护人员直至接单为止,确保通知到人,实现了告警的处理留痕和闭环管控,为了减少夜间工单对维护人员的打扰,工单被分成三等,第一等是24小时立即派单,针对的是可能大规模影响业务的重要告警,二等是24小时延时派单,延时期间如果告警恢复了则不派单仅仅短信通知,针对的是可能自恢复的次级告警,三等是仅仅白天派单,夜间工单会延迟至早晨补派,针对的是硬件故障一类无需立即处理的告警。除了告警工单之外,例如带宽利用率偏高等不直接影响业务、但是长期下来可能形成隐患的问题,会通过隐患工单派发给维护人员。以上两种传统方式由于依赖于电信内部系统存在隐患,因此增加了企业微信和钉钉发送群消息作为补充,即时通讯软件消息可以非常方便在电脑上处理故障,另外还具备一定的二次开发能力。

图片


Zabbix的使用在官网手册上已经有了很详尽的介绍,下面和大家分享一下我的经验和教训。
一套原生的Zabbix就只适合一个中小规模的监控场景。单套Zabbix有其性能瓶颈,最初我们用物理机部署了一套4.0版Zabbix对全省业务做集中监控,尽管物理机性能很强大,但是在8000台主机时就超出了系统负荷,不得不进行拆分,而且涉及部门一多需求就变得复杂,人员、权限的变更也变得难以控制,所以这是我的第一个建议,控制系统规模和范围,把系统限制在一个管理单位之内。
第二就是做好系统本身的监控,如果server发生宕机那么是发不出任何告警的,所以最好有另一套系统对server进行监控,这也是我们没有用位于仪征资源池的Zabbix监控仪征资源池,而是另外在吉山建了一套的缘故。
第三是确保告警渠道有效,任何系统都不可能保证永不宕机,因此不要把所有的希望都寄托到单一告警渠道上,最好通过多个相互补充,同时再做好告警拨测,比如我们的系统每天早上都会发一条短信、一个工单、一条企微信息,帮助维护人员发现系统问题。
如果Zabbix规模很大或者有多套,那么就可以通过一个上层系统去统一管控就很有必要了。在创建监控的时候,尽可能的通过模板而非直接在主机上创建监控项,这样一方面方便复用,另一方面变更需求时只需修改模板。在选择监控方法时,首选通过web即可配置的方法而非需要在proxy或者主机上放置脚本的方式,这样在遇到涉及重装、更换proxy的时候可以避免很多麻烦。最后,严格控制好用户的权限,以免出现用户私自停用主机、停用触发器,甚至修改模板的情况。
最后给大家分享一些教训。Zabbix的功能非常强大,但它并不是无所不能,我们曾经做过很多尝试,比如通过ssh监控项进行设备巡检,但是这种方式一来无法灵活控制执行,二来修改密码或者检查执行结果时需要逐台进行查看;我们还尝试过用Zabbix采集数据,通过设置监控项采集例如设备序列号、配置之类的硬件信息,这样做的后果是监控项数量的暴增,甚至于导致最新数据界面无法打开;我们还尝试过用Zabbix做安全扫描之类的定时任务,尝试做业务的日志检查,技术上都可以实现,但是会造成管理的困难,如果维护跟不上,后期就会出现大量失败监控项、无人认领的脚本和文件各种问题。
所以我的建议是明确Zabbix的系统定位,让Zabbix做好自己监控的的本职工作,远程作业有ansible,日志采集有elk,让更专业系统做专业的事,避免职责不清的情况,保证工作的长期有序。

延伸阅读
案例|太平洋保险多云环境下Zabbix的运用实践
案例|海证期货Zabbix建设之路




2024-03-27