作者:胡建华 中国移动苏州研发中心,IT支撑产品部,技术研究员 主要从事集中化系统架构设计,以及数据保护(存储、备份、云盘)、智能运维相关领域的技术研究和开发工作。 智能运维(AIOps-Algorithmic IT Operations基于算法的IT运维)是人工智能技术在IT运维领域的运用,引用Gartner 的报告的一段话“到2020年,将近50%的企业将会在他们的业务和IT运维方面采用AIOps,远远高于今天的10%”,最近2-3年智能运维的概念随处可见,各大互联网公司、传统IT公司、金融业等都在谈他们的智能运维设想,同时也有人谈AI色变,觉得人工智能只是一个愿景,要落地很难。其实AI已经不是一个新的概念了,百度、微软、谷歌等公司早就在10几年前开始自己的人工智能布局了,到现在均已成为人工智能行业的领跑者了。 话不多说,人工智能那么强大,应用场景十分的广泛,当然也包括运维领域,而且面向业务的运维更是运维发展的热点趋势,下面我就和大家就“面向业务的智能运维体系建设的探索与实践”这个话题发表下我的个人见解。 传统的运维中,存在着诸多痛点: (1)被动低效的运维难以保证业务连续性
(2)缺乏统一的运维监控体系和技术工具
(3)海量的运维数据的价值无法充分挖掘
(4)缺乏全方位端到端的运维监控手段
针对上述这些传统运维中存在的痛点,智能化的运维出现必定具有划时代的意义,智能运维系统的设计可以从如下几方面进行展开思考: (1)面向业务维度实现异常检测 业务运维是运维的大趋势,需从最复杂的业务维度入手,根据业务维度的指标(如PV、响应时间、错误率、GC等)上的异动进行异常检测,提前预警; (2)提供业务全局关系视图 业务应用维度的复杂性是运维过程中最高的,往往是二线和三线运维之间界限最模糊的区域,所以智能运维可以先解决的就是向用户提供全面、清晰的业务关系视图,让运维人员对业务应用的掌控得心应手; (3)KPI可视化与下钻定位 KPI指标可以通过丰富的可视化手段展示给运维人员,业务系统的故障可以清晰的体现在可视化终端,同时支持详细的下钻手段,直至定位到发生故障的环节,甚至代码段; (4)采用动态阈值思想的异常检测 避免传统固定阈值告警的弊端,引入机器学习算法来进行阈值动态化的异常检测效果; (5)重视故障的全流程管理 故障发生时,可以提供一定的手段将业务层面的KPI异常与引起故障的原因联系起来,支持手动下钻之余还可以自动定位和关联; (6)立体化监控体系的建设 覆盖从资源、平台层、应用监控和微服务调用链的立体化的运维分析能力。 智能运维体系架构的建设应该考虑如下因素: 数据 我们要搭建智能运维平台,首先要数据驱动,数据驱动下要做好以下几件事:
分析能力 分析能力是智能运维平台的核心,可以应用大数据 机器学习的分析能力,结合成熟的开源分析算法实现基本的数据分析,再结合具体的应用场景,做出一些适应性改造或匹配来实现相对较好的分析效果,千万不要只想着做出来一个分析平台来,这个平台做出来不是难事,关键在于这个平台在运维领域没有实际意义。 运用起历史数据的价值,且可以有效识别出数据的各维度的规律,如周期性、趋势等,而且分析能力必须结合应用场景,判别相对适合的算法模型来训练数据,方能保证预期的设想。 分析能力可以随着时间的推移不断的演进,可以将新数据的特性带入到模型中来,以不断提高算法的准确度。 一个通用化的业务智能运维的体系架构一般如下设计: 在上述的架构设计中: (1)用户层: 面向业务的智能运维面向的用户,不光光是面向于传统的运维人员,此外,业务监控人员、业务部门主管、客服人员都可以在系统上找到自己所需要的数据、看到自己所想看到的东西; (2)视图层: 提供WEB端丰富的可视化视图、大屏方式的业务状态视图、以及满足移动办公需求的手机端APP; (3)服务层: 业务智能运维将提供给用户业务视图服务、拓扑服务、性能KPI服务、运维分析服务、告警服务、报表服务以及系统服务等,为用户提供丰富的监控、分析和告警视图功能。 (4)核心能力层: 智能运维系统的最关键部分,可以分为三个较大的模块“智能监控”、“智能分析”和“智能告警”。 智能监控: 实现针对各个层面的监控覆盖,包括用户体验的监控、应用性能的监控、中间件监控、基础设施的监控,只有收集了全面的数据,才有可能从数据中寻找关联,从关联中发现规律,丰富运维知识库。 智能分析: 智能分析为整个核心能力层中最核心的部分,该部分应该涵盖离线算法的训练模块和在线实时分析模块 离线算法训练模块要根据历史数据来以离线的方式训练和修正算法模型,然后生成的算法模型就类似于一个个的[if else]判断形成的规则组合,当最新的数据输入到算法模型,就可以实时的给出推测,用于预测、异常检测、故障定位等场景,这里面当然就需要机器学习和深度学习的算法来撑场面了。 在线实时分析模块要实现实时的算法分析,并不依赖于历史数据所训练出的离线模型,而是进行实时的计算,这里则需要大数据的实时计算技术了。 智能告警: 智能告警需要可以有效的遏制“告警风暴”,这个可是告警系统中必须面对的问题,那么需要提供较高效的分析算法,实现告警的自动归类、自动消除,那么归类中最合适的方法就是寻找告警之间的关系关系,将相近的告警合并为一条发送,避免告警风暴。 智能告警还可以动态调整告警短信/邮件发送的频率和周期,还有告警通知对象的智能配置,保证运维人员处理告警的专注性,不会被突如其来的海量告警所淹没。 (1) 业务层数据的采集 包括接口响应时间、调用次数、服务间调用关系、时延、慢SQL、JVM内存消耗、以及线程栈信息,上述数据的采集可以参考Google Dappe的思想实现,其中一款较好的开源软件就是pinpoint。 pinpoint运用JavaAgent字节码增强技术实现应用服务端数据的采集,且无侵入式的设计,使用方便,无需更改业务代码。可以内置支持JAVA程序内几十种协议交互的兼容,如http、okhttp、mysql、oracle、postgresql、dbcp、cubrid、kafka、rabbitmq、springboot、log4j、logback、redis等。 Pinpoint的架构原理图如下: 采用hbase 实现海量数据的存储,通过部署在业务远端的agent通过UDP thrift的方式将应用采集的数据传输到collector,经过处理后实现hbase的落存。Web UI实现监控的可视化。 上图是通过pinpoint进行链路追踪的原理图,可以简单的理解为在一次交易过程中,贯穿的整个分布式系统的各个环节内都维持着一个唯一的transactionid,且允许记录上下文环节的spanid,从而实现链路信息的洞悉。 且pinpoint允许开发者自定义开发插件,实现更多协议的监控支持,如activemq、zookeeper、consul等。 不过pinpoint的功能如此强大的同时,还需要我们做适当的优化,如: Agent发送海量的udp数据到collector,很有可能遇到网络和collector的阻塞,那么,这个时候可以在agent和collector之间加一层kafka实现消息的缓冲,提升系统稳定性。 Pinpoint没有用户权限体系,需要我们自己实现。 可以通过参数自定义的方式来指定实际需要采集的指标项,避免agent多余的性能损耗,降低系统负载。 (2) 关联数据的采集 关联数据包括基设施数据和中间件数据。 首先,基础设施数据如服务器的性能状态的数据,包括CPU、磁盘、内存、IO、负载等维度各个参数的获取,您可能首先想到的是zabbix,那么zabbix确实功能强大,但是“杀鸡焉用牛刀”,上述CPU/磁盘/内存等几个参数就是我们随手敲行代码就可以搞定的事,只不过做成定时任务即可,所以我们不用zabbix,转向轻量化的开源手段,其实TICK数据采集框架您可能都听过,那么我们模仿TICK,通过TIG(Telegraf influxdb grafana)框架也可以轻松搞定了。 Telegraf是一种轻量级的采集框架,支持秒级别间歇的采集粒度,对服务器的资源占用很小(不到3%); Influxdb是一种高性能的时序数据存储引擎,可支持百亿级别的时序数据的存储,而且内置强大的连续计算、API功能,你可以轻松的实现数据的汇聚和外部调用; Grafana是一款基于JS的前端可视化引擎,支持丰富的dashboard组件,如图表、仪表盘、表格、清单等,你可以利用它轻松实现各种高大上的性能监控页面,另外grafana和influxdb的兼容性也异常的友好。 同样,常见的Paas和Daas层中间件,如nginx、apache、zookeeper、docker、mesos、ZFS、Elasticsearch、mysql、mongodb、postgresql、sql server、rethinkDB、influxdb、couchDB、redis、memcache、rabbitmq等的组件的监控也都可以通过TIG框架实现监控。 至此,我们已经可以实现应用层数据和其关联数据(Iaas层、Paas层)的集中采集和汇聚,那么有了数据,能做的事情简直太多了。 欲建立面向业务服务维度的监控体系,首先需要针对业务服务做出分层次的划分,即对业务监控对象的管理需要建立体系,智能运维产品的业务服务管理体系结构如下: 如上图中的②③④层,专注面向业务维度的监控的同时,更要对业务层面进行精细化分层,比较容易想到的办法就是建立系统、服务、实例三层的业务监控体系。 针对系统、服务、实例做一个概念的普及: 系统:完成某一类完整需求的系统体系,如OA系统,系统是一个比较抽象的概念,一般由一个或多个运维人员来管理 服务:系统的下一层模块,即完成系统内某一个完整的相对独立功能的模块,如个人信息管理服务、薪资管理服务、流程引擎服务等;一个服务一般部署为一个集群,包含多个应用实例(如tomcat) 实例:属于一个服务集群中的一个具体的应用实例,一般一个服务集群会部署多个实例到不同主机上,如薪资管理服务实例一、薪资管理服务实例二,实现负载均衡。 在这三个层次上进行性能的监控,实现了业务应用从上到下三层的数据关联,服务运维人员可以更深入的掌控系统业务的关联状况。 那么我们是否可以针对系统、服务、实例分别进行性能监控呢?如果发生故障,就可以寻根溯源,举例:如果一个服务层的指标(如服务整体平均响应时间发生偏高的异常),那么必定是由其下的一个或多个实例导致,现在我们去查看每个实例的性能信息,通过皮尔曼相关系数,发现性能曲线和服务性能曲线最近的实例,就是异常实例,进而可以针对该实例的Top N请求进行下钻分析就可以得到故障所对应的代码行,问题就可以解决了。 上面所建立的系统服务实例的关系,本身就是利用了业务应用运行时本身就存在的关系,那么为何不利用起来呢,到这里还没用到高大上的AI、机器学习呢。 故障可视化 当发生故障时,可以在指标的运行图谱高亮显示该异常点,也是可视化工作中必须的,正如如下图: 上图内,系统识别到了“响应时间”的异常,当前时间点的异常指标为11ms,同时一个友好的智能运维系统会把该时刻系统其他方面的指标也展示出来,运维人员可以直观的看到不同曲线之间的关系,并且图中每一个坐标图的右上角都展示了该指标与异常指标之间的“相关系数”,并且按相关系数绝对值倒序排列,相关系数绝对值越接近于1,那么就越有可能是问题的直接或间接原因。 故障重现 另外当业务系统的一次请求发生了错误,如果我们可以提供手段将该次请求的过程进行一次重现,对于运维人员的排错支持也“将是极好的”。 如上图所示,可以对一次应用的请求进行回放,每一个环境执行了多长时间都可以一目了然。 说到异常检测,应该是业务智能运维领域中的一个最常见的场景了,异常检测的方法很多,本篇中会重点的介绍一下我的见解: (1) 传统的异常检测方法 传统模式下完全基于人的主观经验,也即基于固定阈值的异常判断,如 CPU usage高于80%就告警,这种方式适配性是很差的,需要针对不同的场景设定不同的阈值,甚至同一个业务不同时间段的阈值都是不一样的,大量个性化的配置要求,对于运维人员来说是十分崩溃的。 后来就出现了一定的改进,如3-sigma算法,是根据正态分布的概率,自动的调整告警阈值,是的,告警阈值的配置不用人工进行,一定程度上提高了运维效率。但是,该类的算法机器容易忽略指标的周期性和趋势性,造成误判的问题也很常见了。 (2) 基于统计学和机器学习的异常检测方法 总结前面的异常检测方法,可以概括为两点:人工运维工作量大、算法适配性低下。其实归结为一句话,就是动态阈值怎么评定的问题。 这个时候就比较适合引入机器学习了,比如基于指数的三次平滑算法、基于分解的傅里叶/小波分解算法等,可以有效的识别出指标的周期性、趋势性,可以快速识别出一些尖峰(spike)异常。 另外自回归移动平均模型(ARIMA算法),对于稳定的时序数据的异常检测是非常有效的,该算法也非常适合用作时序数据的预测场景。 还有基于深度学习的循环神经网络 RNN算法和长短期记忆网络LSTM算法,比较适合处理和预测时间序列中间隔和延迟相对较长的重要事件。 基于机器学习的众多算法,都可以大大的提高运维的效率,发现人工难以发现的问题,提高预警的及时性。 (3) 异常检测模型优化 上一小节提到的各类机器学习算法,虽然都功能强大,但是往往都有一定的局限性,那么我们在对具体的一个场景指标(如响应时间)做异常检测的时候,我们到底选哪个算法呢?
举个例子,针对“响应时间”指标进行异常检测,采用同比、环比、ARIMA、LSTM、KNN、高斯共5个算法同时进行异常检测,当其中的一半(即>=3)的算法判定为异常时,方认为该时刻的指标是异常的。
(4)答疑解惑 不过有朋友可能会遇到如下问题: Q:如果我要检测的指标刚刚上线,我根本就没有离线的训练模型怎么办? A:那就初始阶段不利用离线模型的算法,先使用ARIMA、同比、环比、KNN这类的算法跑起来,等待历史数据足够了生成离线模型之后,再以同等权重(取得和现有算法权重的平均值,再进行100分支均衡)的方式加入到算法集合中。 Q:我使用这么多的算法来进行异常检测,对于前端告警规则配置的时候来说,我该怎么去选择我去使用哪种智能的算法呢? A:异常检测的目的就是要识别异常并发出告警,那么在告警规则出进行配置,选择智能化的方法来检测异常的思路是正确的,但是没有必要让普通的运维人员来看到我们所提供的众多算法,还有算法逻辑,对于他们来说我们只需要让他们选择诸如“智能告警”这样的选项就好了,后面的算法选择交给专业的“运维算法工程师”来搞定就好。 Q:有了“智能告警”之后,是不是固定阈值告警就不需要了呢? A:并不是,智能告警解决的是无法直观、简单判定故障的场景,但是对于错误率、CPU利用率、磁盘剩余量这些基本场景时,还是可以使用阈值告警的,甚至做分级阈值告警(如一般告警、重要告警、严重告警等),这些基本的阈值告警发生后一般都是比较严重的情况,都是需要处理的;而且,这些告警信息汇聚起来,也可以作为业务层面异常故障定位的参考依据,因为很有可能这些固定阈值触发的告警就是业务层面故障发生的根因。 (5)算法训练和模型管理平台 好了,长篇大论了半天,我们似乎还忽视了一个关键的问题,那就是离线训练的模型是怎么来的,怎么用起来,怎么选算法,怎么调优,算法一定好用吗? 带着这一系列的问题,我们可以想象的到,一个离线算法训练和模型管理平台是十分必要的,这就是“运维算法工程师”所需要使用的平台了,这个平台至少要实现如下功能:
离线算法训练管理平台的设计可以参考如下模型: 离线算法训练管理平台架构简图 该平台可以获取需要检测的指标,展示过去一段(如一周或一天)时间的曲线; 特征分析器会根据预设的特征组合(事先定义好针对曲线可能的各种特征的识别判定方法库),提示出该指标的曲线对于各类特征(如上升趋势、周期性、随机性等)的支持度,支持度越高代表着该指标越具有什么特征; 然后算法推荐器会根据预设的特征-算法组合(事先定义好各种特征所适用何种算法的映射库),推荐出建议的算法集合(可1可多),当然也允许“运维算法工程师”在查看了第一步的曲线后,自定义选择算法库。 下一步就将通过前面算法推荐器推荐的算法或运维算法工程师自定义的算法组合进行模型的训练,将生成的临时模型保存起来; 然后,采用真实的线上数据来跑这个临时模型,会得到对应的告警; 当运行一段时间(如一周或一天)后,将临时模型发出的告警和线上模型产生的告警进行对比,去掉重复的部分,剩余部分通过运维工程师的标注和反馈,得到两个模型的误报率(当然也可以采用漏报率),若临时模型的误报率低于线上模型,则认为模型是有效的,可以进行发布环节,该临时模型替换线上模型,进入生产。 注:临时模型和线上模型的对比如果无法通过运维工程师的评估快速得到的情况下,也可以采用比较通用的算法评估方法来计算得出,不过最好的手段就是“利用运维工程师的判断”。 关联分析一般会作用在故障定位和告警归集两个差劲 (1) 故障定位 基于关联关系的基础可视化辅助 在针对系统的异常进行有效的检测后,极大的缩小了故障的范围,如将故障缩小到了某几分钟内,然后将相关的其他指标曲线和故障曲线同时可视化展示,则可以辅助我们深入数据进行问题的定位:
基于多维度数据的异常诊断分析
那么贡献度越高、子维度的异常相似度越高,则该维度为根因维度的可能性越大。 因此,可以将数据的各维度展开,分别计算各维度的贡献度、一致度两个特征,构建评估参数P=贡献度/一致度,该值越高,则该子维度为根因维度的可能性越大。
可以定位到实例4的404错误是错误数的主要原因,可针对性进行排查 (2) 告警归集 基于关联挖掘的告警分析 采用机器学习算法实现告警的关联挖掘,进而实现告警前的合并优化,与告警后的数据分析,反哺合并策略。
注:置信度是针对一条关联规则A告警->B告警而言定义的,代表了A告警导致B告警发生的可能的概率 智能告警体系下充分利用从业务到主机的纵向数据关联,实现告警的聚合与收敛
业务角度:服务/实例/告警类型 部署角度:机器/机房 同一角度同一层次同时刻的告警,很可能存在着一定联系,故而可将这些告警合并。
小结 上述基于关联关系实现了故障辅助定位和告警的智能归集,其实还有很多落地的场景,如根据事件依赖关系构造动态事件概率模型图,如果有大量的历史数据做分析,就可以充分的识别出各类事件之间的因果关系,这些因果关系就是最宝贵的运维知识库。 同时,智能运维系统也将辅助软件负载策略的优化,通过针对集群的全面监控和分析,在负载层做出更新时,可以及时的发现集群整体的健康劣化的状况,及时发现负载策略变更导致的问题,并向负载层软件上报问题或针对负载策略优化的建议,以更加智能化的手段提高系统的高可用性和效率。 负载均衡优化模型 辅助负载优化常用场景包括: 相同负载下某主机的硬件指标告警,则可以考虑将其上应用转移到其他低负载主机上,或降低负载均衡器的分配权重,达到所有主机整体健康; 当发现某主机上应用响应变慢,并且将会发生故障时,负载均衡的tcp探查无法发现,运维系统可以实现事先预警,并定位事故原因(一般为硬件或负载均衡器分担错误问题),同时上报负载均衡器,事先负载重分等止损措施; 灰度发布过程中,可以通过智能运维产品监控新版本的性能情况,如可及早发现新版本应用性能较差或者存在错误警告,则可以及时上报灰度发布系统,及时止损,或触发自部署节点的回滚自愈操作。 日志分析的作用,往往会体现在如下几个场景: (1) 针对业务日志进行业务的多维分析 如通过CDN的日志,实现用户的行为画像,也可以实现故障分布的拓扑视图; (2) 针对于日志中出现的各类关键日志 可以提炼出关键的事件来,这些事件如果和前面的业务异常所关联起来,就可以实现业务异常所对应的根因事件溯源; (3) 利用诸如ELK这样的平台 针对分布式的日志进行汇聚和索引后,就可以发挥和业务层性能采集一样的作用,将日志进行解析后,同样是是一列一列的性能指标,而后再来做异常检测还是可以的; (4) 利用日志做运维审计与合规 也是一个智能运维的典型场景。 针对于故障自愈应该以故障定位准确基础之上开展的,需要逐步推行,在此我就结合几个场景来聊一聊故障自愈的设计方案(按照云计算体系进行分层描述吧),以辅助落地: (1)Saas层:
(2)Paas和Daas层:
(3)Iaas层
首次发现故障暂不触发自愈操作,待连续5次出现同样故障,触发自愈操作; 采集一定时间段的平均值,如平均值不超过阈值,则不认为是故障,不触发自愈操作 智能运维并不是万能的,智能运维的落地成功性在于精于业务、切合实际,关键点如下:
业务智能运维,是运维发展的大势所趋,无所畏惧,世间万物皆连接,有了人工智能这一利器,加之我们对于业务的深层理解,以及运维领域的丰富经验,相信中国移动智能运维体系的建成和落地,指日可待!! 注:文中少部分内容的思路和灵感参考于百度、清华大学、Linkedin、Yahoo等公司运维领域专家的大作,谢谢。 本文来源:移动Labs |
|
来自: 辉仔runmwo0nbv > 《通信》