智能采集组合文章(智能运维（AIOps-AlgorithmicITOperations）基于算法的IT运维)

　　智能采集组合文章(智能运维（AIOps-AlgorithmicITOperations）基于算法的IT运维)

　　智能运维（AIOps-Algorithmic IT Operations algorithm-based IT运维）是人工智能技术在IT运维领域的应用，引用Gartner报告中的一段话“到2020年，将近50%的企业将 AIOps 在业务和 IT 运维中的采用率远高于今天的 10%。” 智能运维的概念近2-3年随处可见，各大互联网公司、传统IT公司、金融行业都在谈智能化，同时也有人谈及AI变色，认为人工智能只是一个愿景，实施起来比较困难。其实AI并不是一个新概念。百度、微软等公司，

　　

　　不多说，人工智能这么强大，应用场景非常广泛，当然包括运维领域，面向业务的运维是运维发展的一个热门趋势。下面给大家分享一下“面向业务的智能运维”。维度体系构建的探索与实践”就这个话题发表我个人的看法。

　　2、传统运维-痛痛快快

　　传统运维存在诸多痛点：

　　（1）被动低效运维难以保证业务连续性

　　(2）缺乏统一的运维监控体系和技术工具

　　（3）海量运维数据价值无法充分挖掘

　　（4）缺乏完善的端到端运维监控手段

　　

　　3、商业智能运维的切入点

　　针对上述传统运维的痛点，智能运维的出现必然具有划时代的意义。智能运维系统的设计可以从以下几个方面考虑：

　　(1）实现业务维度的异常检测

　　业务运维是运维的大势所趋。需要从最复杂的业务维度入手，根据业务维度指标（如PV、响应时间、错误率、GC等）的变化进行异常检测和预警；

　　(2）提供业务全球关系视图

　　业务应用维度的复杂度在运维过程中是最高的，往往也是二线和三线运维界限最模糊的区域。因此，智能运维首先可以解决为用户提供全面清晰的业务关系视图，让运维人员对业务应用的掌控得心应手的问题；

　　（3）KPI可视化和下钻定位

　　KPI指标可以通过丰富的可视化方式展示给运维人员，业务系统的故障可以在可视终端上清晰的体现出来。同时支持详细的下钻方法，直到定位到故障环节甚至代码段；

　　(4）使用动态阈值思想的异常检测

　　避免传统固定阈值告警的弊端，引入机器学习算法进行动态阈值异常检测效果；

　　(5）注意故障的全流程管理

　　当故障发生时，可以提供一定的手段将业务层面的KPI异常与故障原因联系起来，支持人工钻取和自动定位关联；

　　(6）立体监控体系建设

　　涵盖了从资源、平台层、应用监控、微服务调用链三个维度的运维分析能力。

　　

　　4、商业智能运维架构

　　4.1 智能运维核心要素

　　构建智能运维系统架构应考虑以下因素：

　　数据

　　构建智能运维平台，首先要数据驱动。在数据驱动下，我们必须做到以下几点：

　　

　　分析能力

　　分析能力是智能运维平台的核心。可以应用大数据+机器学习的分析能力，结合成熟的开源分析算法，实现基础数据分析，再结合具体应用场景，做一些自适应变换或匹配，达到比较好的分析效果，不要只想着打造一个分析平台。创建这个平台并不难。关键是这个平台在运维领域没有实际意义。

　　利用历史数据的价值，并能有效识别数据各个维度的规律，如周期性、趋势等，分析能力必须结合应用场景识别出相对合适的算法模型来训练数据，从而保证预期的假设。

　　分析能力可以随着时间的推移而发展，新的数据特征可以被引入模型中，以不断提高算法的准确性。

　　

　　4.2 智能运维架构

　　一个广义的商业智能运维的架构一般设计如下：

　　

　　在上述架构设计中：

　　(1）用户层：

　　面向业务的智能运维不仅仅针对传统运维人员，业务监控人员、业务部门主管、客服人员可以在系统上找到自己需要的数据，想看什么就看什么；

　　(2）查看层：

　　提供丰富的WEB端可视化视图，大屏业务状态视图，满足移动办公需求的手机APP；

　　(3）服务层：

　　商业智能运维将为用户提供业务视图服务、拓扑服务、性能KPI服务、运维分析服务、告*敏*感*词*务、报表服务、系统服务，为用户提供丰富的监控、分析、告警视图功能。

　　(4）核心能力层：

　　智能运维系统最关键的部分可以分为“智能监控”、“智能分析”和“智能报警”三大模块。

　　

　　智能监控：

　　实现各级监控覆盖，包括用户体验监控、应用性能监控、中间件监控、基础设施监控。只有采集全面的数据，才能从数据中发现关联，从关联中发现规律。丰富运维知识库。

　　洞察力：

　　智能分析是整个核心能力层的核心部分，应该涵盖离线算法训练模块和在线实时分析模块

　　离线算法训练模块需要根据历史数据离线训练和修正算法模型，然后生成的算法模型类似于通过一一[if else]判断形成的规则组合。当最新的数据输入到算法模型中时，会实时给出推测，用于预测、异常检测、故障定位等场景。当然，需要机器学习和深度学习算法来支持场景。

　　为了实现实时算法分析，在线实时分析模块不依赖历史数据训练的离线模型，而是进行实时计算，这需要大数据的实时计算技术。

　　智能警报：

　　智能报警需要能够有效遏制“报警风暴”，这是报警系统必须要面对的问题。因此，需要提供一种更高效的分析算法来实现告警的自动分类和自动消除。那么分类中最合适的方法就是找到告警之间的关系，将相似的告警合并为一个发送，避免告警风暴。

　　智能告警还可以动态调整告警短信/邮件发送的频率和周期，以及智能配置告警通知对象，保证运维人员可以集中精力处理告警，不会被突如其来的海量告警淹没。

　　5、商业智能运维典型应用场景及关键设计

　　5.采集 的 1 个数据

　　

　　(1）采集的业务层数据

　　包括接口响应时间、调用次数、服务间调用关系、延迟、慢SQL、JVM内存消耗、线程栈信息等，以上数据的采集可以参考google的思路实现Dape，其中一个更好的开源软件就是 pinpoint。

　　pinpoint采用JavaAgent字节码增强技术实现应用服务器数据采集，非侵入式设计，使用方便，无需更改业务代码。可内置支持兼容JAVA程序中的http、okhttp、mysql、oracle、postgresql、dbcp、cubrid、kafka、rabbitmq、springboot、log4j、logback、redis等几十种协议。

　　Pinpoint的架构*敏*感*词*如下：

　　

　　HBase 用于存储海量数据。部署在业务远端的代理通过UDP+thrift将应用采集的数据传输到采集器。处理后实现hbase的存储。用于监控可视化的 Web UI。

　　

　　上图是通过pinpoint进行链路跟踪的*敏*感*词*。可以简单理解为，在一个事务过程中，在整个分布式系统的每一个环节都维护着一个唯一的transactionid，并且允许记录上下文环节的spanid。这使得洞察链接信息成为可能。

　　并且pinpoint允许开发者自定义开发插件，实现对更多协议的监控支持，如activemq、zookeeper、consul等。

　　但是，pinpoint的功能如此强大的同时，我们还需要进行适当的优化，例如：

　　当agent向collector发送海量udp数据时，很可能会遇到网络和collector的阻塞。那么，这时候可以在agent和collector之间加一层kafka来缓冲消息，提高系统稳定性。

　　Pinpoint没有用户权限系统，需要我们自己实现。

　　您可以通过参数自定义的方式指定实际需要采集的索引项，避免agent不必要的性能损失，减少系统负载。

　　

　　(2） 关联数据的 采集

　　关联数据包括基础设施数据和中间件数据。

　　首先是服务器性能状态数据等基础设施数据，包括CPU、磁盘、内存、IO、负载等各种参数的获取，大家可能首先会想到zabbix，那么zabbix确实很强大，但是“杀鸡没用” 上面提到的CPU/磁盘/内存等参数都是我们简单打代码就能搞定的事情，但是作为定时任务就可以搞定，所以不需要zabbix，转轻量级的开源手段。其实TICK数据采集Framework大家可能听说过，那我们就模仿TICK，通过TIG（Telegraf+influxdb+grafana）框架就可以轻松搞定。

　　Telegraf是一个轻量级的采集框架，支持秒级的间歇性采集粒度，占用服务器资源少（小于3%）；

　　Influxdb是一款高性能时序数据存储引擎，可支持百亿级时序数据的存储，并内置强大的持续计算和API功能，可以轻松实现数据聚合和外部调用；

　　Grafana 是一个基于 JS 的前端可视化引擎，支持丰富的仪表板组件，如图表、仪表板、表格、列表等，您可以使用它轻松实现各种高级性能监控页面，以及 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层）的集中采集和聚合，所以有了数据，要做的事情简直太多了。

　　

　　5.2 业务层级精细划分

　　建立面向业务服务维度的监控体系，首先需要对业务服务进行层次划分，即建立业务监控对象的管理体系。智能运维产品业务服务管理体系结构如下：

　　

　　如上图②③④层所示，在重点监控业务维度的同时，还需要细化业务层面的分层。最容易想到的方法就是建立系统、服务、实例三层业务监控体系。

　　对系统、服务和实例进行概念普及：

　　

　　这三个层次的性能监控，实现了业务应用自上而下的数据关联，服务运维人员可以更深入地控制系统业务的关联状态。

　　那么我们可以分别监控系统、服务和实例的性能吗？如果发生故障，您可以追查根本原因。例如：如果一个服务层指标（比如服务的整体平均响应时间异常高），一定是它下面的一个或多个实例造成的。现在我们来看看每个实例的性能信息，通过Pearman相关系数，发现性能曲线和*敏*感*词*能曲线最接近的实例就是异常实例，然后可以下钻分析Top N请求获取故障对应的代码行。问题解决了。

　　上面建立的系统服务实例之间的关系是基于业务应用运行时存在的关系，那为什么不使用呢？我们还没有使用先进的人工智能和机器学习。

　　5.3 故障可视化和故障再现

　　故障可视化

　　当发生故障时，可以在指标的运行图中突出显示异常点，这在可视化工作中也是必须的，如下图所示：

　　

　　上图中，系统已经识别出“响应时间”异常。当前时间点的异常指标为11ms。同时，友好的智能运维系统此时也会显示系统其他方面的指标，让运维人员直观地看到不同曲线之间的关系，以及每条曲线的右上角图中坐标图显示了指标与异常指标之间的“相关系数”，它们按照相关系数绝对值的倒序排列，相关系数的绝对值越接近。到 1，越有可能是问题的直接或间接原因。

　　无法重现

　　另外，当业务系统的某个请求发生错误时，如果我们能提供一种手段来重现这个请求的过程，那么对运维人员的排错支持也将是“极好的”。

　　

　　如上图所示，可以回放一个应用请求，一目了然每个环境执行了多长时间。

　　5.4 异常检测

　　说到异常检测，应该是商业智能运维领域最常见的场景之一。异常检测的方法有很多。在本文中，我将重点介绍我的见解：

　　(1） 传统异常检测方法

　　在传统模式下，完全基于人的主观经验，即基于固定阈值的异常判断。例如，如果 CPU 使用率高于 80%，则会发出警报。这种方法适应性较差，需要针对不同的场景设置不同的阈值。，甚至同一业务在不同时间段的门槛都不一样，大量的个性化配置需求对于运维人员来说是非常崩溃的。

　　后来出现了一定的改进，比如3-sigma算法，根据正态分布的概率自动调整报警阈值。可以，报警阈值的配置不需要手动进行，一定程度上提高了运维效率。但是这种算法机器往往会忽略指标的周期性和趋势性，误判的问题也很常见。

　　

　　(2） 基于统计和机器学习的异常检测方法

　　总结以往的异常检测方法，可以总结为两点：人工运维工作量大，算法适应性低。其实归结为一句话，就是如何评估动态阈值的问题。

　　这时候更适合引入机器学习，比如基于指数的三次平滑算法、基于分解的傅里叶/小波分解算法等，可以有效识别指标的周期性和趋势，可以快速识别一些峰（spike）异常。

　　此外，自回归移动平均模型（ARIMA算法）对于稳定时间序列数据的异常检测非常有效，该算法也非常适用于时间序列数据的预测场景。

　　还有基于深度学习的循环神经网络RNN算法和长短期记忆网络LSTM算法，更适合处理和预测时间序列上间隔和延迟比较长的重要事件。

　　许多基于机器学习的算法可以大大提高运维效率，发现人工难以发现的问题，提高预警的及时性。

　　(3） 异常检测模型优化

　　上一节提到的各种机器学习算法虽然功能强大，但往往也有一定的局限性。那么当我们在对特定场景指标（比如响应时间）进行异常检测时，我们应该选择哪一个呢？算法呢？

　　例如，对于“响应时间”指标进行异常检测，同时使用同比、环比、ARIMA、LSTM、KNN、Gaussian 5种算法进行异常检测. 当其中一半（即 >=3） 算法确定异常时，方认为该时刻的索引异常。

　　(4）问答

　　

　　但是，有些朋友可能会遇到以下问题：

　　Q：如果我要检测的指标刚上线，完全没有离线训练模型怎么办？

　　A：那么初期不要使用离线模型算法，先用ARIMA、同比、链比、KNN等算法运行，等待历史数据足够生成离线模型，然后然后使用相同的权重（获得与现有算法权重相同的权重）的平均值，然后进行100个分支均衡）添加到算法集中。

　　问：我使用了很多算法来进行异常检测。配置前端报警规则时，如何选择使用哪种智能算法？

　　A：异常检测的目的是识别异常并发出告警，所以配置告警规则，选择智能的方式检测异常是正确的，但是不需要普通运维人员看我们有什么完毕。提供了许多算法和算法逻辑。对于他们，我们只需要让他们选择“智能报警”等选项，后面的算法选择就交给专业的“运维算法工程师”。.

　　Q：有了“智能报警”，就不需要固定阈值报警了吗？

　　A：不会，智能报警解决了不能直观简单判断故障的场景。但是对于错误率、CPU利用率、磁盘剩余量等基本场景，仍然可以使用阈值告警，甚至是分级阈值告警（如一般告警、重要告警、严重告警等），这些基本阈值告警一般是需要处理的严重情况；而且这些告警信息可以聚合起来，也可以作为业务层面异常故障定位的参考，基于此，因为这些固定阈值触发的告警很有可能是业务层面故障的根本原因.

　　(5）算法训练与模型管理平台

　　好吧，聊了半天，我们似乎忽略了一个关键问题，那就是离线训练模型是怎么来的，怎么用，怎么选算法，怎么调优。算法确定好用吗？

　　带着这一系列的问题，我们可以想象一个离线的算法训练和模型管理平台是非常有必要的。这是“运维算法工程师”需要用到的平台。这个平台至少要实现以下功能：

　　离线算法训练管理平台的设计可以参考以下模型：

　　

　　离线算法训练管理平台架构图

　　平台可以获取需要检测的指标，并显示过去一段时间（如一周或一天）的曲线；

　　特征分析器会根据预设的特征组合（预定义的曲线各种可能特征的识别判断方法库），提示指标曲线的各种特征（如上升趋势、周期性、随机性等）。 ) 的支持度，支持度越高，指标越有特点；

　　然后算法推荐器会根据预设的特征-算法组合（预先定义哪些算法适用于各种特征的映射库）推荐一组推荐算法（一个或多个），当然也允许“运维”算法》“工程师”，查看第一步的曲线后，自定义选择算法库。

　　下一步是通过上一个算法推荐者推荐的算法或者运维算法工程师定制的算法组合训练模型，并保存生成的临时模型；

　　然后，用真实的在线数据运行这个临时模型，就会得到相应的告警；

　　运行一段时间（比如一周或者一天）后，对比临时模型发出的告警和在线模型产生的告警，去掉重复的部分，通过注解得到两个模型的错误以及运维工程师的反馈。如果临时模型的误报率低于在线模型，则认为模型有效，可以进行发布环节。临时模型取代在线模型并进入生产。

　　注意：如果临时模型和在线模型的对比无法通过运维工程师的评估快速得到，也可以使用更通用的算法评估方法进行计算，但最好的方法是“使用运维工程师评价方法》。法官”。

　　

　　5.5 关联分析

　　相关性分析一般用于故障定位和告警采集。

　　(1） 故障定位

　　基于关联关系的基本可视化辅助

　　有效检测系统异常后，故障范围大大缩小。例如，如果将故障减少到几分钟，然后将相关的其他指标曲线和故障曲线同时可视化，可以帮助我们更深入地挖掘数据。要定位问题：

　　

　　基于多维数据的异常诊断与分析

　　那么贡献度越高，子维度的异常相似度越高，则该维度为根本原因维度的可能性就越大。

　　因此，可以对数据的各个维度进行扩展，分别计算各个维度的贡献度和一致性，构建评价参数P=贡献度/一致性。值越高，子维度越有可能是根本原因维度，性别越大。

　　

　　可以定位到实例4的404错误是导致错误多的主要原因，可以针对性排查

　　(2） 告警采集

　　基于关联挖掘的告警分析

　　利用机器学习算法实现告警的关联挖掘，实现告警前的合并优化，告警后的数据分析反馈合并策略。

　　

　　注：置信度是针对一个关联规则A告警->B告警定义的，表示A告警会导致B告警发生的可能概率

　　智能报警系统下，充分利用业务到主机的垂直数据关联，实现报警的聚合和汇聚

　　业务视角：服务/实例/告警类型

　　展开角度：机/机房

　　同一角度、同一水平、同一时间的警报很可能是相关的，因此可以将这些警报组合起来。

　　

　　概括

　　实现了上述基于关联关系的辅助故障定位和告警智能采集。其实落地场景还有很多，比如根据事件依赖关系构建动态事件概率模型图。如果有大量的历史数据进行分析，完全可以识别。各种事件之间的因果关系是最有价值的运维知识库。

　　5.6 负载均衡优化

　　同时，智能运维系统也将辅助优化软件负载策略。通过对集群的全面监控和分析，当负载层更新时，可以及时发现集群整体的健康恶化情况，及时发现负载策略的变化。问题，并向负载层软件报告负载策略优化的问题或建议，从而以更智能的方式提高系统的高可用性和效率。

　　

　　负载均衡优化模型

　　辅助负载优化的常见场景包括：

　　如果同一负载下某台主机的硬件指标出现告警，可以考虑将其上的应用转移到其他低负载主机上，或者降低负载均衡器的分配权重，实现所有主机的整体健康；

　　当发现某台主机上的应用响应慢，会出现故障时，负载均衡tcp探针找不到，运维系统可以实现提前预警，定位事故原因（通常是硬件或负载均衡器共享错误），同时上报负载均衡器，并提前采取负载再分配等止损措施；

　　在灰度发布过程中，您可以通过智能运维产品监控新版本的性能。如果能及早发现新版本的应用性能差或者有错误警告，可以及时上报灰度发布系统，及时止损，或者触发自动回滚自愈操作部署节点。

　　5.7 日志分析

　　日志分析的作用往往体现在以下场景：

　　

　　(1） 业务日志多维度业务分析

　　比如通过CDN的日志，可以实现用户的行为画像，也可以实现故障分布的拓扑视图；

　　(2） 用于日志中出现的各种关键日志

　　可以提取关键事件。如果这些事件与之前的业务异常相关联，则可以追溯业务异常对应的根本原因事件；

　　(3） 利用 ELK 等平台

　　分布式日志经过聚合索引后，可以起到与业务层性能一样的作用采集。解析日志后，也是逐列的性能指标，然后还是可以做异常检测的。;

　　(4） 使用日志进行运维审计合规

　　也是智能运维的典型场景。

　　6、智能运维的最高境界——故障自愈

　　对于故障自愈，应在准确故障定位的基础上进行，需要逐步实施。这里结合几个场景（根据云计算系统分层描述）来讨论故障自愈的设计方案，辅助落地：

　　

　　（1）Saas 层：

　　（2）Paas 和 Daas 层：

　　(3）Iaas 层

　　发现故障第一次不触发自愈操作，同一故障连续5次触发自愈操作；

　　采集某段时间的平均值，如果平均值不超过阈值，则不认为故障，不触发自愈操作

　　7、智能运维不是万能药

　　

　　智能运维不是万能的。智能运维的成功，在于精通业务和实践。要点如下：

　　8、感慨万千

　　业务智能化运维是运维发展的大趋势。没有恐惧，世界上的一切都是相连的。凭借人工智能这个强大的工具，再加上我们对业务的深刻理解和在运维领域的丰富经验，相信中国移动智能运维维度体系的完成和落地指日可待！！

　　注：文中一小部分内容的想法和启示参考了百度、清华、Linkedin、雅虎等公司运维领域专家的杰作，谢谢。

　　进一步阅读：

　　引用：面向业务的智能运维：中国移动智能运维体系的探索与实践