vlambda博客
学习文章列表

AIOps建设与数据治理




在上一篇中,我们明确了AI的能力边界、智能运维能够解决的问题,以及相应的解决方案。

本篇文章我们来谈一谈这些解决方案,应如何落实到实际的运维应用当中去。


我们曾经提到,不能把数据和场景不加拆分,直接丢给算法,期待它们能产生所谓的“效果”,在IT运维领域更是如此。 其实将运维工作拆解开来,无非就是最为经典的“故障发现”和“故障定位”。

常见的运维数据有以下几类:时序指标类数据 (包括性能指标和基础监控指标) 、日志 (应用日志、中间件日志、服务器日志等等) 、交易明细、由监控数据产生的告警、报文等。

01

  指  标  



在传统运维监控中,运维人员一般会给指标数据配上固定的阈值,为了让其能在紧要关头发挥作用,就需要不断调整阈值大小并配置各种告警规则来避免误报。


AIOps建设与数据治理

周期性波动指标


一个数据中心会有数以万计的指标数据,不同的指标又有不同的趋势周期。对于有上升或下降趋势的指标,管理员需要不断的调整阈值以保障告警准确性;而如果我们想对图中这样一条有周期性波动的指标配置上述规则,往往只能在“高误报”和“高漏报”之间权衡取舍。当管理员面对海量指标时,繁重的配置工作量、后续维护的人力成本,以及告警的高漏报率/高误报率是现阶段运维人员共同面对的普遍性难题,“动态基线算法”呼之欲出。


AIOps建设与数据治理


02

 日 志  



日志中包含了大量有价值的信息,一个大型的数据中心每天的日志增量能达到TB级规模,如何挖掘这些日志的深层价值,从海量日志中提取有价值的信息,是目前运维领域的另一个挑战。

AIOps建设与数据治理

对于“千人千面”的日志数据,很难做到实时对每一条日志进行分析。目前常用的手段是通过“关键字提取”和“正则表达式匹配”快速获取运维人员所需信息,这需要我们在已知日志“长相”情况下,尽可能完善关键字和正则的信息。而实际的情况是,除了依靠现有的运维人员经验外,往往要在故障发生之后我们才知道如何优化配置规则,更好地监控这些日志。随着软件系统的不断更新和硬件设备的不断升级,已知的日志通常是非常有限的,“智能化日志分析产品”需求迫在眉睫。

AIOps建设与数据治理


传统运维监控工具更侧重于描绘整个系统的运行状况,将IT系统产生的数据统一集中管理,但受限于数据分析能力,对数据本身没有严格的要求,可以忍受数据的断点、乱序、采集规则不统一等问题。AIOps产品作为集中的数据分析软件,对于实时数据的质量要求堪称“严苛”。在面临复杂的运维场景时,需要面面俱到地发现系统中存在的问题,并找到其原因,首先要求数据覆盖范围尽可能广泛,其次对具体的智能运维算法来说,也会有具体的数据需求。

就上文提到的指标和日志举例来说,为了让“动态基线”算法更精准地发挥作用,需要指标数据有均匀的采集间隔,不能有数据缺失 (尽管少量的数据断点不会影响算法对数据趋势的学习) 。而日志则需要高度规范化,且有统一的管理工具进行整合,才能更好的将数据实时输入给AIOps平台。

AIOps建设与数据治理

AIOps平台作为海量异构数据的分析平台,确实会对运维数据有比较高的要求。高标准的数据会极大提高算法分析结果的价值。没有全面的数据,智能运维的价值会大打折扣,但这并不意味着一定要提升了数据质量,再来做智能运维。

智能运维是检验运维数据质量的试金石。 没有数据需求方,数据治理便无的放矢。在我们的AIOps落地经验中,由智能运维倒逼数据治理是一个非常不错的策略,随着智能运维场景的不断增加和扩展,我们会对接下来的数据改善方向了如指掌,从而有目的性地进行数据治理。

AIOps建设与数据治理

我们之前的文章提到过,支撑AIOps整体能力背后的,其实是一个一个非常具体的智能运维算法,在相应的非常具体的场景中发挥价值,再通过这些不同智能运维场景的组合,使运维工作的智能化程度不断提升。事实上每一个场景的诞生,都经过了无数真实案例的打磨。必示AIOps就是这样一些具体场景的组合,每一个场景看似独立却又可以联动发挥更高的价值。从故障发现到故障定位分析,其过程是全自动的。我们可以在接到告警的几分钟内得到一份覆盖范围非常广的故障定位报告,将传统情况下需要人工排查的、可能反映故障原因的数据合理的展示给运维人员。

AIOps建设与数据治理
相比传统的故障发现手段,必示应用故障预警产品线下的业务指标异常检测( 动态基线算法) 、日志异常检测 (自动对日志进行模式识别,按不同模板进行异常检测的算法) 、指标趋势预测 (目光更长远的算法,指导我们在适当的时间进行扩缩容操作) 、批处理异常检测 (根据历史上跑批任务的执行情况,对当天跑批任务的合理性预测) 等产品,分别擅长对某一类数据、某一类场景进行故障预警,提前或在故障发生之初就将告警反馈给运维人员。

应用故障定位产品线下又分为调用链根源系统定位 当产生告警风暴时,根据调用明细确定故障传播链,并找出潜在的根源系统) 、业务明细多维定位 (从多个维度或维度组合分析业务失败明细) 、机器指标定位 (将告警业务下的相关机器、实例等的性能指标进行快速分析,找出潜在的故障模块) 等,也是对细分场景的定位,有各自擅长的数据领域。而细分场景的好处就是,误报大量减少,且不需要人工进行繁杂的配置操作了。在故障发生的时候,快速从故障分析报告中看到故障相关的所有信息,无需在多个监控工具中收集线索,避免错过最佳的故障处理时机。

AIOps建设与数据治理

随着这样的细分场景越来越多,我们聚焦于“应用故障预警”和“应用故障定位”的效果也会越来越明显。

当然我们也可以根据数据现状,灵活选择可行方案,解决当下最迫切的需求。单一场景AIOps产品如日志异常检测和业务指标异常检测,也可以在运维工作中为我们节省很多人力和时间,产品和AIOps平台的解耦设计,会让后续的升级扩展工作更加从容。



  总结  


完整的AIOps产品在实际运维工作中可以为我们节省大量人力和时间成本,但同时也依赖高标准的运维数据。但这并不意味着两者的建设无法并行。相反,两者并行是一种更高效的选择,部分AIOps场景“初见疗效”的同时,它也在指导我们后续的数据治理工作。



相关阅读:


AIOps落地实践常见问题解读系列(一)