Skip to main content

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

· 8 min read
Kindling-OriginX
故障根因推理引擎

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

运维的挑战与责任

在数字化时代,运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能,还要快速响应并解决故障,以减少对业务的影响。在这种背景下,运维团队急需工具和技术,能够帮助他们提高效率,减轻负担。AIOps(人工智能运维)应运而生,旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps当前技术与输出

AIOps核心功能包括事件聚合、异常检测、自动化根因分析等。这些技术能够帮助运维团队从海量的监控数据中快速识别问题,预测潜在故障,并自动化常见问题的解决过程。通过AIOps,许多组织已经显著提高了故障响应时间,减少了误报,优化了运维流程,提升了IT系统的整体可靠性和性能。

AIOps仍然存在挑战:故障根因与可观测性数据割裂

尽管AIOps技术取得了显著进步,但在故障根因分析方面仍面临一个重大挑战:故障根因与可观测性数据(如日志、指标、追踪)之间的割裂。AIOps系统虽然能够推荐可能的故障根因,但往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识,在海量的数据中寻找证据来验证这些推荐,这一过程既耗时又容易出错。

Gartner 魔力象限中领先象限做到的效果

Dynatrace 效果

Dynatrace 的AI故障推理效果和介绍详情可参见 Dynatrace 官方网站。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

从 Dynatrace 的视频中,如果发生了故障之后,AI推荐出AI根因之后,用户仍然需要使用根据 Visual resolution path 去从众多的Trace以及各种可观测性数据中筛选出证据来证明这个AI的推断。

Dynatrace 做到全球最牛的地方,就是能够将各种可观测性数据融为一体,并以时间线为维度还原故障现场,这个本质上还是人为分析,所谓的AI推荐,给出的是关键节点。

如果没有这个故障根因推荐,用户使用 Dynatrace 怎么做呢?仍然是围绕着故障时间点,利用 Dynatrace 的 Visual resolution path 人为分析故障根因。

结论:故障根因的推荐聊胜于无,还是需要人为在可观测性数据中分析找证据。

Datadog 效果

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

Datadog 的 Watchdog RCA给出仍然是可能性,具体从可观测性中找证据来证明这点,仍然需要用户自己来做。

结论:故障根因的推荐聊胜于无,还是需要人为在可观测性数据中分析找证据。

可观测性盲区的存在导致AIOps的根因结论与可观测性数据存在割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

举例说明:Dynatrace 的根因例子为节点CPU利用率达到100%,其实绝大多数运维人员都能识别出100% CPU利用率是有问题的。但是如果CPU利用率是50%,这个时候人是很难判断程序是否会受到CPU供给瓶颈,需要额外提供更多的数据去判断CPU利用50%的时候,程序的执行是否会受到调度器的影响,这取决于很多因素,比如机器上需要调度的程序多少,CPU调度器排队的长度等,总而言之,可观测性数据存在盲区。

可观性数据由于存在盲区,导致人都很难根据可观测性数据推理出故障,只能根据事后的结论去关联出CPU利用率50%在某些场景下也是存在可能性导致故障根因的(资深运维人员在判断这两点的时候CPU利用率为50%,是故障根因也是需要非常深厚的经验)。

可观测性数据盲区更详细的介绍,请参考之前的文章。

内核视角持续剖析解决AIOps的故障根因结论与可观测性的割裂问题

在之前的文章介绍了可以使用内核视角下持续剖析,能够形成基于北极星指标的排障体系。可参见:内核视角下持续剖析 VS 代码视角下的持续剖析

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

基于这个标准化排障体系进行故障根因推导的时候,就能够同时自动化关联相关指标。比如如果发现网络时间很长,这个时候就可以关联网络相关性指标,必要时还可以同步 DeepFlow 等关键网络事件及数据,提供证据证明网络确实有问题。