案例| 中移在线:云原生下的监控能力演进

本文整理自王漫雪在2020Zabbix中国峰会的演讲，ppt可在网盘获取:  https://pan.baidu.com/s/193LSRNQGmBbqk9Doj4PEpg  密码:ypur 

更多演讲视频可关注官方Bilibili账号主页（ID：Zabbix中国）。

  一 背景-全国集中维护、全球最大  

本次演讲分五个主题，背景、出路、转型、沉淀、蜕变。中移在线服务有限公司是中国移动旗下的专业子公司，不管你是给10086打电话还是通过10086的微信公众号、小程序办理话费查询业务，这些系统都是我们公司在进行支持。

我们公司算是传统的公司，最近也做了很多升级，广东省的用户有可能在使用5G手机，同时用了5G套餐的情况下，非常有可能接待你的都是视频客服，美女小姐姐面对面跟你做服务介绍。随着我们的服务、业务、运维、形态都在升级，目前面临的运维挑战是巨大的。

中国移动有9.1亿的用户，9.1亿用户多不多？我们做个对比，我查了微信的用户是12亿，支付宝的用户是10亿，非常火的抖音的用户是5亿，我们9.1亿应该是非常接近一线的互联网公司了。这么大的用户量代表着系统线上肯定是一个分布式高并发的系统，它是很复杂的，对于我们的运维挑战也是很多的。

大家可以看到，现在线上生产环境的容器已经有3万+了，物理机也有2万多台，业务系统也是变化很快的，采用了很多新的技术，比如说微服务、容器，日均上线是120次，这在传统的运营商里面是非常庞大的数量了。最后就是要求高，很难想象，如果10086电话打不通了，可能这个事就要上新闻了。

  二 出路 拥抱开源  

对于一个传统的运营商，我们怎么选择自己的出路呢？对于传统运营商来讲，我们可能没有像BAT一样非常高精尖的人才，我们可能也不懂系统内核是怎么开发的，想要自己脱离于厂商做一个完全自主化的运维平台系统，在短时间之内几乎是很难很难的，那怎么办呢？我们只能去拥抱开源。

在我接手中移在线的时候，我们的监控系统是一个非常传统的厂商提供给我们的，当时我们的监控数据指标是每15分钟采集一次，我压根看不到监控数据采商长什么样子，只有故障的时候我收到一条短信告诉我你现在CPU利用率高了，当时我很痛苦，那怎么办？

新时期的监控需求也摆在这儿了，我们需要跨层，很多很多各种各样的设备，有新的也有老的，我们还需要跨域，还需要高实时，还需要可持续化，这样的监控需求摆下来，做了很多的技术调研之后，我们选择站在Zabbix这个巨人的肩膀上。利用Zabbix的成熟能力，一个月之内快速完成了监控系统的生产上线。以及包括37个监控模板的搭建，3个月之内就覆盖了总部加31个省份公司100%的技术监控，这个速度是不可想象的，本身Zabbix也是非常成熟的，它可以实现秒级数据采集，从2017年到现在基本上没有出现重大的故障。

最后跟Grafana做了一个很好的结合，利用它的开源可视化的自定义的看板，给大家输出来了很多的监控报表。本身Zabbix的代码写得非常高效，因为是C语言写的，本身系统的资源消耗是很低的。

看下我们的建设模式，刚才忘了介绍，我们公司有两个集中的数据中心，在31个省、市还有31个分公司，为了让监控能力快速推广开，我们就采用了总部集中建设、统一管控，分公司标准化接入的建设模式，快速利用Zabbix通用的监控模板，包括自己开发了一些，适配了一些，做了37项能力，总部就负责把监控能力建设，便边界点的标准化，所有监控数据的上收分析展现与通知，分公司只需要简单的把监控持续维护下去就可以了。

下面来给大家看一些展示，这是所有Zabbix目前覆盖的公司用到的所有通用中间件，这是我们做的，大家都知道中国移动网络设备都是集采，所以你会遇到很多很多各家的网络设备，所以用Zabbix我们也把它统一的搞定了。这是用grafana做的可视化的看板。当时半年的时间我们已经累计了如下的指标，半年时间把2万主机全部覆盖了，也累计了200万个监控项，当时我们看起来觉得这个已经很多的量级了。

所以在200万监控指标的压力下，我们也做了一系列Zabbix的系统优化，包括它的数据库，因为我们当时用的还是老的，3.6版本，所以当时用的是mysql数据库，强烈建议各位如果你们用的也是老版本的话，希望你们也用纯SSD的物理机，这样不会让数据库在一定量级的监控项下成为瓶颈。就是随着监控量级的增加，我们也遇到了一些问题，这些问题相关解决方案也列在PPT里了，时间原因我就先不细讲了。

今年我们也做了Zabbix的双中心高可用方案，因为我们现在公司的所有核心系统全部都是双中心高可用的，我们在北方的省份有数据中心，在南方的省份有数据中心，北方中心承担了15个省份的业务流量，南方中心承担了15个省份的业务流量，但是因为历史原因，监控系统刚开始建立在了北方中心里面，Zabbix server大家知道我们采用的是只有一个server存活在北方中心里面，左边半边我们做了一些高可用，但是有一天领导把我抓过来问了我一句，他说万一北方中心挂了怎么办？

那我们业务是可以实现通过DNS域名解析把北方事故流量快速切换到南方，但是我们突然发现那个时候我们没监控了，这个是老板不能允许的。后来我们就想了一种方案，能在10分钟之内帮助我们把这个监控全部切换到南方中心的备节点上，保证我们在所有业务切到南中心的时候，我们还有监控可以看，只是历史数据看不了了，但是会有新鲜的监控产生，给了我们一个备用的方案。

在这儿总结一下，前期野蛮推广的经验，在线当时推广的时候，因为时间的原因，我们希望能够快速地把能力覆盖到31个分公司，所以我们走了一条不太正常的道路，我们是摸着石头过河。先是需求分析，功能验证完直接就全网推广了，随着监控数量的增加，我们才想起来要做性能监控，包括一些典型问题的处理。最后才做了规范化的制定和整改。

中间我们付出了非常惨痛的代价，我们发现这个加着加着，当前的模板没有做好规范化的处理，回头再改的时候会发现之前加的监控找不到了，或者有些监控我想改也不知道怎么改。所以推荐大家，先做需求分析，然后做标准化的规范制定，比如说模板名称、主机群组、主机名字、动作名字、展板名字，都是需要有一定的关联性的，最后做一下性能调优，才能去全网推广，这是一个比较合理的顺序。

  二 转型 几个问题及解决方案 

1. 200万监控指标，出了问题仍不知道？

2. 海量日志是否有利用价值？

3. 容器上的监控怎么做？

到了转型期，我们依然面对了很多问题，下面大家来看第一个问题，累计了200万指标还很得意的时候，我们的业务系统有一次挂了，挂完之后老板把我们叫到面前，漫雪，为什么挂了我没有收到短信，你都200万指标为什么没有告警，这个时候我才幡然醒悟，我那200万指标做的都是基础监控的一些监控指标的覆盖，业务监控系统挂了不挂了我还是不知道。

后来血泪史才发现，原来以业务监控和客户体验才是我们最终的目标。所以我们要把从基础设施管理到应用系统管理，一直上升到后面业务质量管理与客户体验管理。这里面我做了很多事情，第一个是加了应用性能的监控，也就是传统业界所说的APM，另外也把核心系统全部梳理了一遍，按照谷歌SRE的五项黄金指标，要求了每个业务系统都必须更我们梳理一些核心的KPI，方便我们对业务系统的实时运行状态来做监控。

这时候又有一个问题了，老板说什么时候是个头呢，你怎么能告诉你的老板，我现在已经能把加的监控全部加完了。这个时候我们又做了一个事情，就是梳理了一下云化架构下我们认为的监控分层，以及每一层都应该涉及到的监控指标，就是这个金字塔型结构。这个时候我们就会发现，其实业务监控能发现70%的问题，基础监控可能只能发现30%的问题，所以会把更多的经历投入到了在业务监控方面的添加。

面临到第二个问题，我们刚才讲到了线上的业务监控系统大概有200多个，全网的主机大概有3万台，不管是业务系统产生的日志也好，网络设备产生的日志也好，海量日志是不是有用？为此我们发现了，其实对于亚健康状态，异常日志要比系统故障出现得更早一些。所以本着这个，我们能更早地发现故障，我们去做了一套统一的日志平台，通过这种有代理的模式和一些无代理的模式，把所有跨厂商的设备日志，包括业务日志全部集中到了一个日志平台里面，做统一的查询处理和告警分析。

这是我们的统一日志平台，采集的方式有很多种，包括HTDP、TCP、UDP、文件监听、SYSLOG的。另外，我们也做跨网传输，刚才讲了我们有31个分公司，有31个边缘节点，所以要把分公司的日志全部传到本部的平台上面来，也用了Flink实时大数据的计算能力，把日志汇聚在一起，最后也实现了，通过全局的唯一追踪ID，实现了业务系统日志里面的上下文的查询，以及全链路的调用链的分析。

这个时候我们已经清楚地具备了业务系统，比如说A调B，B调C，C挂了影响AB，或者是用户说很慢、很卡顿，但是具体不知道慢在哪一个业务系统的调用链上，这个时候通过日志平台做到了这个层次的监控。来看一下日志平台的相关数据，我们每天要处理600亿行的日志，目前整个日志平台的集群节点有400多个。

接着就是在2019年底，公司的底层技术做了升级，把我们也折腾了不轻，从之前以openstack技术为主的虚拟化云计算升级成了容器，在容器上的监控应该怎么做成为了首要思考的问题。这个时候因为我们公司底层的容器云量是基于k8s二次开发得来的，所以当时选用了跟k8s相生的prometheus。

当时在容器上面做了包括容器主机的监控、云资源使用近况的监控，容器状态的监控，包括一些集群事件之间的监控，还总结了一些包括容器上跑的业务的监控，包括入口返还量的监控，接口的调用监控，包括核心日志的异常关键字监控，dubbo线程池状态的监控等等。

最后总结一下，这个时候通过大家前面听我的讲述，底层用了很多不同的开源平台，去为我们采集各种各样适合做的监控数据采集，所以我们就发现现在该要整合了，怎么能打造一套统一的监控平台呢？底层、通过日志平台、prometheus、Zabbix，APM、包括一些传统的专业网管设备，把它统一地划分成了数据采集的平台，上面把采集上来的监控数据，不管是统一送到ES里面，把它分为好多份，不管是做实时处理也好，做离线分析也好，还跟资源管理的数据，以及智能化的规则关联在一起，做了很多上层的应用。

这些应用就贯穿到了整个故障处理的场景，包括监控系统，做了这种智能故障发现，故障定级，告警系统要做智能通知，流程要去派单，完成告警的闭环管理。接着我们要做大数据的分析与决策，最后通过自动化平台来完成故障自愈。

  四 沉淀-让监控更多可能 

第一，刚才做了这么多监控，我们怎么能保证监控服务更及时？31个分公司，每人一天给我提一个工单，我一天就31个工单，所以我在很长一段时间，在没有做自动化之前，我被投诉最多的事情就是漫雪你的监控需求支撑不到位，我的分公司想要加个监控还要等上两天，这不行，监控不等人。怎么办，当时已经雇了15个厂商，每天专门做工单，这个代价成本是很高的，后来我们就想办法，发现其实很多监控能力，像Zabbix，通过模板的标准化，通过ZabbixAPI，我们其实是可以实现自动化的增删改，所以现在通过一系列标准化梳理，已经做了二次开发，基于Zabbix和prometheus，我们做了这一整套的监控自助的工具，能实现覆盖目前85%的监控需求，把这套工具放上去，把权限给你，把监控的列表也给你，你就可以实现自助化的添加了，只需要做简单的培训，只需要在页面上点点点就行了，不需要去了解Zabbix原理是什么，什么是prometheus，我把它透明化了。

但是这个时候就带来了下一个问题，服务自动化的底线在哪里？因为我把这些服务都放出去之后，我们是属于运维团队的，运维是为公司的生命线做保障的，但是我们把有些自助服务放给了研发同学，这个时候不是黑他们。放给研发同学之后，研发同学就会觉得每天收的短信太多了，我们原本可能把CPU大于75，然后我就告警了，后来发现大于75也不一定每回都有事，那要不然我改改吧，我改成90，过两天我可能就改成95了，因为我总觉得它会没问题。这时候就出现我把自动化的服务权限放给所有人之后，我很难保证所有人的思想意识能高度统一，所有人都有责任心。有可能今天为了少收两条短信就把这个监控给我删掉了。这个时候出现故障了，老板不会去找他，老板只会找你，你这个监控平台怎么又没告警？

所以面临这个问题，我们在用户便利性和监控的管理上面做了很长时间的思考和battle，最后划了17种网源监控类型，定了一些不可更改的生命线，这个活动我们叫得很通俗，就叫“挂了我知道”。这些监控是你不能改的，是我们默认添加的。比如说你今天有一个业务系统上线，你用监控自助加了，你添加的过程当中，这底下不可更改的生命线是我们默认给你加上去的，对你来说是透明的，你也不能改，因为我们要知道生产所有的系统，挂了情况下运维团队是要第一时间知道的。

接着就是数据化的赋能，刚才大家看到了整个监控平台上面是有一层dpas层的，把很多的自助化的监控工具，把数据抽上来之后做什么用呢？可以做很多的报表分析，可以提供非实时性的业务健康性的周报分析之类的，另外还可以丰富很多的指标，最后给大家重点推荐的还是应用的扩展，做了很多故障快速定位、根因分析、故障自愈和容量管理。

下面来看第一个就是根因分析，现在很多业界都在讲AIOPS，很多厂商来跟我们说通过智能化的算法，可以给你做到根因定位，但事实上来说，短时间之内智能化算法能起到什么作用，完全取决于数据的质量以及数据的累计。在这些东西都没有的时候怎么办，我们打造了一套法典——两套拓扑。

第一套拓扑，就是我们把监控告警数据跟资源管理，CMDB里面的数据深层结合起来，形成了一个纵向的拓扑，它能告诉你，我的业务系统现在都用了哪些中间件，用了哪个数据库，用了哪个MQ，这个业务系统都部署在哪些基础设施上面，我的网络设备挂了，到底能影响哪些业务系统，这是一层纵向拓扑。

接着就是一项横向拓扑，这个讲到刚才利用日平台，整个跟企业消息总线关联在一起，打造了一层横向拓扑，它用来干吗？它告诉你业务系统之间调用关系，业务A挂了，能影响哪些业务系统，当横向拓扑和纵向拓扑联合在一起，你就能实现最终的四看一报了，这个时候我就能拍着胸脯跟老板讲，业务系统哪挂了，至少我知道。

接着就是故障自愈，这个是把监控数据提取出来之后，我们跟自动化运维平台结合在一起。至少实现一些简单场景，固定场景下的故障自愈。比如说自动扩容、自动重启以及自动的接口关闭，这个地方要讲一下，如果你想实现自动的接口关闭，必须得做到业务系统的配合，不能业务系统不配合，你就把接口关了，那业务系统有可能会挂。

接着就是通俗意义上的容量管理，容量管理还是很重要的，大家都在讲开源、节流、降本、增效。怎么降本？其实都要看监控采上来的数据做精细化的处理，可能要给你的运维团队或者是业务团队定期发一些报表，告诉他哪些主机资源利用率用的实在是很低，然后你可以退回去，或者提高一下资源利用率。

来看一下现在的数字，就是一系列监控平台在线上跑了三年之后，全网有3.4万主机，我有2606监控项，78万触发器，每天处理600亿的日志，给大概将近1000个用户提供一系列的服务。

  五  蜕变- AIOPS在监控告警的应用  

最后，忍不住要尝试一把AIOPS，毕竟最近这么火，我们觉得很多经验累计起来，底下要讲的应用是我们觉得最初级、最入门，大家普遍都能去尝试的一个东西。首先还是问题，我写这个PPT的思路就是遇见问题解决问题，然后来推动平台去往前技术的演进。

这个问题就是领导要求，发生故障了必须得监控系统第一时间知道，你得有报警短信发出来，这是这个系统存在的意义和价值。我们的运维人员就会说一天处理2000多条短信，我根本看不过来，我压根就不想看。那在多和少之间，我们怎么去权衡这个问题，然后我们做了一系列的数据分析，然后就发现了在告警这个层面，可能正常告警缺少的是关联和压缩，误报漏报中间有很多问题都是基于阈值设置的不太合理，也就是说没有人，新业务系统上线，可能开发人员自己就没有办法很精准地告诉你，我什么情况下这个业务系统核心KPI指标是不正常的，这个时候怎么办？

我们研究了一下阈值设定有三个层面，包括规则设定，大家拍脑子，CPO利用率大于95%普遍都觉得有问题，到通过大数据分析，我看了一下历史的三个月，这个系统核心KPI指标跑在哪儿，最后就是智能化的阈值预定，这个业界普遍叫做指标的异常检测。

我们是通过这种首先把监控单个指标的数据做历史数据的分析，因为周期性的数据是比较好做智能预测的，非周期性的要做一定的数据清洗，接着做一些毛刺检测，最后用LSTM一些数据分析的算法去做异常判定，它能智能地帮你找到系统现在到底异常还是不异常。

这是一个图的举例子，比如说蓝的指标是预测指标，绿色指标是实时指标、现实指标，黄的现在就是异常判定的方差线，三个线放在一起，超过黄线的，或者是高于黄线、低于黄线都是异常点，这个就可以充分证明你的系统现在是有问题的。

最后，为什么讲这个事？主要是觉得智能化运维离传统的运营商和传统的其他厂商来讲并不是那么遥远，本身具备了很多数据，现在业界有很多成熟的算法，基于结构化的数据，需要的计算资源是非常少的，不是像语音、图像需要服务器，虚拟机数量少的话虚拟机都可以起步的。

白皮书应该很多人都见过，AIOPS实施的白皮书里面有三个常见的应用场景，在这些应用场景里面红色的是我们现在正在尝试并且取得了一定成果的，异常检测、根因分析以及智能客服。这是我们正在做的，比如说日志的异常检测，告诉你压缩关联、根因分析，以及一些容量管理上面的缺失预测之类的。