可观测 AIOps 的智能监控和诊断实践丨QCon 全球软件开发大会总结

本文主要是介绍可观测 AIOps 的智能监控和诊断实践丨QCon 全球软件开发大会总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：董善东（梵登）

本文是作者于 9 月 5 日在 QCon 北京 2023（全球软件开发大会）上做的《阿里云可观测 AIOps 的智能监控和诊断实践》专题演讲文字版。

大家上午好，很高兴可以在 QCon 稳定性和可观测的场子来分享阿里云可观测 AIOps 的智能监控和诊断实践。

我是来自阿里云云原生可观测团队的梵登。 目前主要在可观测团队负责可观测 AIOps 产品 Insights 的商业化建设、AIOps 解决方案的研发、大模型在可观测领域的探索等。很幸运的过去几年主导了 ARMS 在《Gartner APM 2022》和《信通院根因分析标准 2023》的测评项目，因此今天也会分享我在测评过程中的一些心得体验。

今天主要会从以下四个方面进行分享。

首先会简单介绍下在可观测体系下，AIOps 的核心能力项有哪些。

第二部分则是今天的重头戏，着重介绍我们在可观测场景定义的 AIOps 场景三板斧：检测、分析、收敛的实践。也会在这一部分分享一些我们对于工程架构、业务架构、算法模型的总结。

第三部分则是通过可观测 AIOps 具体的客户案例，看下企业的痛点和需求是什么。

最后，大家从本次会议的多个分享中也可以发现，很多是有关大模型及其应用。在这样的趋势下，可观测 AIOps 有哪些可以落地的场景和方向。

可观测体系下的 AlOps 介绍

好的，在开始第一部分分享前，我们也来看下 AIOps 目前被企业挑战的三个灵魂拷问：

AIOps 是否是个摆设？
如何衡量 AIOps 的业务价值？
AIOps 如何落地，落地成本有多大？

我期待今天在分享过程中，能够让大家对灵魂拷问产生一些思考和找到一些答案。

可观测这几年随着云原生的概念普及，被越来越多的人所关注和提及。但其本身并非新概念。最早的可观测概念来源于：控制论书，里面强调：要控制一个系统的前提是对其具有可观测性。

新一代的可观测产品我们认为，必须以应用为中心，向上关联业务成败与用户体验，向下覆盖基础设施与云服务监控。 其中用户体验重要性凸显，而对于业务的分析、用户行为的分析、以及出现故障下的根因分析能力，需要被重点关注和建设。如何实现这些能力项？我们的回答是 AIOps。

最早的 AIOps 概念来源于 Gartner 在 2016 年发布的报告中首先提出了基于大数据及算法（Algorithmic IT Operations）的 IT 运维概念。随着人工智能的快速兴起，Gartner 在 2017 年将 AIOps 概念从基于大数据及算法，扩充为基于人工智能（Artificial Intelligence for IT Operations，AIOps），认为通过大数据、机器学习及高级分析技术，提供具备主动性、人性化及动态可视化的能力，直接或间接地提升目前传统 IT 运维（监控、自动化、服务台）的能力。因此，在官方定义中，AIOps横跨了监控、ITSM、Ops 三大领域。

当前，AIOps 从 2016 年的兴起，到 2018/2019 年达到期望顶峰，到如今 AIOps 处于达克效应认知曲线中的绝望之谷阶段。

我个人的见解是：

当前 AIOps 的概念是过大的，导致没有清晰的产品边界和落地的核心能力项，进一步加大了落地的不清晰度。
另一方面，AIOps 对于可观测类产品的数据采集、数据质量和数据丰富程度有着严重依赖，与可观测产品的功能高度一致。然而，AIOps 中的关键词 “Ops” 往往与 DevOps 的功能重叠度过大。这种过度依赖其他领域的情况导致 AIOps 很难作为独立产品真正落地。

我认为更好的选择是在当前阶段，深入到某一个具体领域，例如可观测，在其中做可观测各类场景中建设 AIOps 能力项，再逐渐形成统一的 AIOps 品牌产品。国外的 Datadog 构建 Watchdog、Dynatrace 构建 Davis 的 AIOps 品牌产品，都验证了这条道路的可行性。

当然，这几年 AIOps 从最初模糊的概念，到日益可以在一个领域内通过标准化的方式去落地，信通院和各公司的专家们还是在里面起到了很大的作用，我们可以看到如 AIOps 能力成熟度模型标准的发布、也可以看到在可观测领域中，对于构建根因分析技术要求的评测项的公布。这些都可以更好的牵引我们来完成可观测 AIOps 的落地。

当然，目前无论从各个可观测产品中 AIOps 的能力输出，还是国内外的专家评测对于可观测 AIOps 的理解是存在一定的差异性的。

国外的典型代表如 Gartner，每年都会针对 APM 领域做出分析报告，在其 Critical Capacities（简称 CC）的考核中，围绕着六大类场景：IT Operations、Security Operations、数字体验监控、DevOps、业务和应用线、SRE 进行考题的设计，每个场景都有一个模拟的角色和需要解决的一系列问题。如在 SRE 这个场景中，你可能需要来应对：

变更前后，能否发现异常
微服务的异常下的连锁反应分析
资源层面的根因分析

我们从其要求考核的核心能力看，需要 AIOps 在里面发挥巨大作用的包括：用户的行为分析、业务的分析、以及全链路下的根因分析。而 Gartner 考核的重点也是围绕着如何把这些能力用好。

国内的代表则可以来看下信通院在今年发布的《根因分析技术要求》标准。其核心考核的能力项包括：信息收集、决策分析和结果输出，考核的则是对于能力项进行分级，来看你当前产品能力项处于哪个级别。这里面考核的重点还是在看有没有 AIOps 的能力。

对比国内外的考核要求，国外更注重用好 AIOps 的能力，国内则还停留在有没有能力项的考核上，由此可以看到我们在落地 AIOps 的过程和持续迭代中，要进一步发挥 AIOps 能力项的优点，持续的可以用好 AIOps 能力才是落地的关键。

好，到这里呢我们就对可观测和可观测的 AIOps 做了简单的介绍，也简单的理解到了国内外对于可观测 AIOps 理解的差异性。接下来第二章，则是我们今天分享的重点，我们一起来看下阿里云可观测团队在智能监控诊断上的实践。

阿里云可观测 AlOps 智能监控&诊断实践

首先对于可观测 AIOps 场景的定义，我们总结了落地三板斧：检测、分析、收敛。

我们认为，在可观测领域产品中，我们应该围绕着这三板斧进行落地实践和持续迭代，而传统 AIOps 中讲到的容量规划、故障自愈、安全等等则不在我们落地的考虑范畴内。

其中，在落地的过程中，我们总结了每一板斧可以具体做优化的能力项：

首先是检测场景：

我们应该首先对告警系统中的存量告警规则和将要配置的告警规则做告警治理。梳理哪些是发现问题需要配置的检测对象。这里举个例子：在业务监控中，业务的核心指标如在线人数，成功率则是应该配置的检测告警对象；在应用监控中，应用的黄金三指标 RT（平均时延）、Error Rate（错误率）、QPS（请求量）则是应该配置告警的指标。而有些指标则更应该在根因分析来使用，如 JVM 类指标、基础设施的资源指标如 CPU 使用率等。
第二我们应该对告警规则做分级设计，一方面对于核心指标和预警类指标，我们可以构建分级的机制：核心指标如 RT，预警类指标如 CPU 使用率。另外一方面，对于核心指标的规则，也可以做分级：如 RT 从 50ms 到 200ms，可以是 P3 类告警，从 50ms 到 1s，则应该是 P1 类告警。除了人工的定义分级机制，我们也可以通过算法来构建自适应分级的机制能力。
第三则是对告警风暴或者说大范围告警的监控，我们的解决方案是对告警的告警指标做检测。
第四则是除了人工的阈值告警外，对于业务类指标、波动性比较强的指标，我们需要智能巡检来提供自适应巡检的能力。

其次是分析场景：

分析场景可以构建的第一个能力项是对多维指标做关键维度的定位。举个例子：作为在线总人数指标发现异常时，我们可以通过对改指标下的某一个维度如地域（北京、深圳、上海）做出维度定位分析，可以快速的知晓是所有地域的在线人数指标都出现问题，还是只是上海这一个地域的个性化问题。从而可以快速的缩小故障范围。类似的能力在多维明细日志、调用链路的 span 都可以做出使用。
在定位到业务的维度范围后，围绕着微服务中服务的调用，服务的资源依赖，我们则需要有一套可以快速定位到异常节点的机制。我们将这一能力项统称为异常节点定界。通过这个能力项的构建，我们可以快速的知晓是哪一个 POD 出现了问题，从而针对性的进行异常根因分析。
在真实的排障过程中，我们给出异常节点是否就足够了呢？我们是否可以进一步分析和排查，直接给出导致故障的真实根因：到代码，方法栈级别，或者到调用的 SQL 命令级别呢？这则需要代码级根因定位能力项的支撑。
最后则是影响面分析能力项，这往往是很多人在落地分析场景容易忽略的一个点。但是影响面分析往往是很关键的，通过它，我们可以快速的知晓某一个故障当前影响了多少个应用，影响了多少次事务请求，影响了多少个用户。这对于用户体验监控的分析是很有帮助的。当然，从业务到后端服务到用户的分析，这也是需要在数据层面实现关联，比如可以通过前端-后端-业务中去透传 userid 来实现。

最后，收敛场景通常用于解决告警系统中告警发散和过多的问题：

首先，可以建设的能力项是对相同的告警进行合并。在告警未恢复的状态下，可以按照 1-5-10-30 的频率来通知，并在通知中包含发送历史项的属性。
我们也可以对于告警事件做噪音分析，来识别当前告警可以传递的信息量到底有多大。对于那些无价值/低价值的告警事件，则可以认为是噪音，实现噪音的过滤。当然，具体怎么来判定告警是不是噪音，则有好几种方案，我们后续也会分享下我们是如何实施的。
第三则是告警的关联，告警关联其实不一定降低告警的数量，但是可以提高告警的信息密度。通过在告警事件中，附上所有相关的告警信息，这样 SRE 在处理单条告警时，则收获更多的信息，从而辅助排障。
最后则是系统如果构建了根因分析，则可以在收敛中，对于相同的根因进行合并，从而真正意义上的实现告警收敛。

接下来我们则来看下这三板斧场景落地中，具体的一些挑战和方案。

第一个挑战是：如何构建快速且准确的检测。

智能检测相比于传统阈值检测的优点，我相信在过去的几年里已经被越来越多人所知，业务类指标一方面不太好配置阈值，另外一方面则是阈值需要做出定期的维护。相比而言，智能检测则可以自适应的捕捉和学习其历史规律，得到持续的好的检测能力。但是，构建智能检测的方案也不是那么容易的。这里面最大的两个挑战是：

指标的形态各异。
异常的定义不清晰，包括像均值变化异常、趋势异常，甚至周期漂移，可能有人也认为是异常。

再来看下目前业界通用化理解的检测方案分类：

使用最广的是统计类算法，包括像同环比，k-sigma，箱线图等。

对于同环比算法而言，环比是对比值的变化率是否超出一个设定的阈值，同比则是对比同一个周期的值是否超出设定阈值。这一些算法在周期性强且固定不变的场景效果不错。

第二种统计算法则是 k-sigma，当数据分布符合正态分布时，大部分的点都在均值附近波动。而超出均值加减 3 倍的标准差的概率是 0.3%，属于一种小概率事件。这一类算法将小概率的值认定为异常，由此演变出了 k-sigma 检测算法。

第二大类的检测算法则是时序分析，时序分解类算法，如 EWMA，STL 等。以 STL 为例，认为任意一个时间序列都可以分解为周期项、趋势项和残差项。通过对时序分解，对于其中的趋势项，残差分别做检测，从而期望取得更好的检测效果。

第三大类的检测算法是预测类算法，典型的如 Prophet，LSTM。这一些算法则是通过对历史上的指标趋势拟合，预测未来一段时间内的走势和合理边界。当真实发生的值超出了拟合的上下边界，则认为是异常点。以 Prophet 为例，此算法可以分成 4 个核心步骤。首先是对曲线数据中选择改变点，自动检测趋势的变化。其次则是对时序构建分解，相比于传统的 STL，Prophet 支持配置的方式加入节假日的日期，从而来解决节假日效应带来的检测不准问题。第三步则是对获得的趋势、周期进行分别拟合，再进行相加/乘得到拟合曲线。最后则是通过预测值和真实曲线的分布差异，来计算上线边界。这一步和传统的 EWMA 构建检测边界其实是类似的，不过 Prophet 对于上手实践还是很友好的，通过简单的调参也可以快速的得到一个 60-80 分的检测器，感兴趣的可以试试。

最后一大类则是机器学习/深度学习的模型，将检测问题看成是 2 分类问题，通过有监督的训练得到一个可用的检测器。这一类算法模型比较适合已经具备了一定标注数据集的场景来落地。另外一种思路则是通过主动学习结合的方式，对正常时序做无监督学习来应对典型的正常和异常，再结合一些边界 case 的标注的方式，进行有监督的训练来提升分类能力，这种思路可以在小样本的情况下来通过机器学习/深度学习类模型来实现异常检测的落地。

综合考虑了各类异常的定义，各类算法模型的优缺点，我们采取了多模型融合的检测方案，通过结合各类无监督模型和部分场景下我们训练的 xgboost 模型，通过投票机制，融合多种检测集成方案。整体方案分成 3 个核心步骤：

1. 数据层： 在该层主要进行数据验证（有效性验证，缺失值验证）和数据的预处理（缺失值处理，归一化处理）等。

2. 算法层： 算法层整体采取了 STL+多模型投票的方案。通过 STL，来进行周期性和趋势性的识别。这里我们通过 FFT、ACF 和片段相似的三种方案实现多周期的判定。

3. 业务层： 在业务层主要是完成业务个性化的设置，特殊指标处理以及构建偏业务的算法策略。如：异常值的置信度，异常区间和正常区间。

整体算法可以从三个特性来细看下：

“LSTM 带来的长短结合”思想，短时特征和长时特征组合

长时特征检测不仅在检测效果上带来了提升，同时对于一些期待低成本的检测场景需求，也可以通过长时序列的特征和边界计算实现低成本的动态检测方案。

“分而治之”，不同时序不同的检测器

对于平稳性很强的指标，我们从检测效率出发，一般采取多种弱检测器组合的强检测器，其中弱检测器包括：K-sigma KDE，EWMA，箱线图。
对于非平稳，Insights 则对指标先进行了差分，再通过平稳性验证后，转为通用检测模型进行检测。
对于周期性强的指标，并结合傅立叶和相似性，进行了单/多周期的准确识别，在去除周期后再进行通用异常检测。
对于具备检测数据集沉淀的场景，Insights 巡检则可以支持 xgboost，孤立森林等算法进行检测识别。

“投票机制”，利用多个弱检测器组成一个强检测器

业界常见的弱算法，如 K-sigma，箱线图算法，KDE，EWMA 都是融合方案中的一个基础检测器。利用多种弱检测器，基于投票策略完成了一个强检测器算法的构建和优化。

总结来说，在这样的“投票机制”，“分而治之”，“长短特征结合”的思想指导下，我们在保持大部分模型都是无监督的基础上，在三大黄金指标的检测效果上普遍达到异常样本的精确率 95%，召回率 90%，整体准确率高于 95% 的评测成绩。

云原生环境下，服务之间拓扑复杂，一个应用可能直接或间接地调用了上百个微服务，需要快速、准确、低成本地定位根因。“三板斧”落地场景的第二大挑战则是在微服务场景下，如何快速，低成本的实现根因分析。

目前典型的根因定位可以分成 3 大类：

第一种是多维度定位：当多维度 KPI 发生异常，如何定位到其根因维度，也叫指标下钻分析。

第二种则是关联辅助定位：这类定位通过利用指标之间的关系（CMDB 关联，算法包括：相似，频繁项挖掘等），找到故障时不同指标之间的关联关系。

最后一种方案是拓扑/调用链路定位：这一类根因分析一般具有明确的服务调用拓扑关系图和实时调用链路。依托于拓扑图的随机游走/整体建模等方案。

这里我们把微服务级别的根因分析拆解成了 2 个关键点。第一个关键点是：如何低成本的定位到异常节点。

这里我们给的方案是对微服务的拓扑进行了水平和垂直的梳理。水平的分为服务之间的调用。垂直的分为服务到资源的依赖部署。每一个可能都是 1 对多的关系。通过这样的梳理后呢，我们可以在不获取整个拓扑图的基础上，构建逐层的下钻分析。也就是只需要当前着一层的节点和它下一层的节点信息即可。这样的好处是数据拉取成本相比整体建模要小得多，本质上是对拓扑图做了一层剪枝。

那具体到每一层的下钻分析呢，我们则根据微服务的场景，设计了归因算法模型。以双因素归因算法为例，对于 RT 类的调用指标，当 RT 出现了异常后，需要考虑 2 个因素：服务请求量和请求耗时。通过双因素的拆解，我们可以准确的知晓每一个因素的变化对于最终整体结果的变化影响是多大。这样通过逐层下钻和归因算法模型，我们就实现了低成本、准确的异常节点定界。

第二个关键点则是，在构建根因分析的过程中，我们不断思考，我们到底应该给出什么样的分析系统。给出异常节点和异常相关信息是否就足够了？当前业界的很多方案都是实现到第一层就结束了，给出异常节点和异常信息后呢，则更多的依赖运维专家自行的判定。

我们则是更近了一步，把运维专家的很多分析步骤和流程，通过决策树的方式，实现了模型化。这样我们则可以去在定位到异常节点后进一步的分析异常节点中的代码、方法栈调用，指标，异常日志等信息，实现到代码级别的根因分析。

整体方案呢，则是依托于算法+专家系统的决策树模型化，先通过水平分析服务依赖贡献，垂直分析基础设施异异常进行故障定界，实现到具体的异常节点。再通过专家插件的分析，可以在具体的异常节点下，针对典型故障实现插件化深入分析，从而整体实现一个从节点定界 -code 级别的根因分析能力。

那目前我们针对多种场景实现了决策树模型化的专家插件，如：下游依赖问题、慢 SQL 问题、流量不均问题等，针对这些场景实现了到代码级别的根因定位。

最后在分析场景，我们来看下具体的使用案例。

首先是某一个用户应用的 RT 指标发生了突增异常，传统的人工检测和排查，首先需要针对这一个应用去配置相关的告警，在收到告警后，需要手动的去收集异常信息：查日志、查告警、看大盘、执行临时命令。再通过了解系统部署情况、各种领域知识等来实现根因的分析和判定。

智能监控诊断呢，则在无需配置的情况下，智能化识别到了该异常事件并确定严重级别。在给用户发送通知的同时，进行了根因分析。在根因诊断报告中我们列出了导致本次耗时突增的原因：下游应用 B 的部分接口在执行 SQL 请求的耗时突增，从而导致了上游应用的 RT 变高。

基于这一信息，用户快速进行了确认，最后发现是 SQL 索引失效导致的本次问题。

第三板斧所解决的挑战是，告警过多的问题怎么解？首先我们来分析下告警为什么会过多？原因一般有 3 种：

检测不准，带来的告警配置偏保守。
系统中天然存在一定量的告警噪音。
多个地方配置了相关的告警，如机器配置了告警，机器上的服务也配置了告警，就会出现机器、服务多个地方都在告警，其实背后的本质，是同一个故障根因。

通过收敛的手段呢，我们就可以对告警中的一些噪音做出识别，对发散的告警可以通过关联手段，根因合并的手段来解决。

我们先来看下业界目前场景的几种收敛方案：

第 1 种是对告警事件的内容进行相似聚类，比如常见的对告警标题，告警内容。告警内容的相关性往往取决于选择的字段，而很多告警内容都是通过模板化方式生成的，这种就给文本相似带来了很多的干扰，从而降低了准确性。

第 2 种则是对告警产生的时间序列进行相似关联，这两种方案比较简单直接，但是缺点是往往都是构建的相关性，确定性不强。可以作为关联信息展示。

第 3 种则是对历史上的告警项进行频繁项的挖掘，来构建不同告警对象之前是不是存在一定的相关性。这种方案初看还是有一定的道理，但是在真实的落地过程中会发现，其实频繁一起出现的，可能包含了多种关联性在里面，简单的通过这种构建相关，准确率是比较差的。

我们的收敛方案融合了多种技术选型的优点，构建了事件的处理和分析流。其中最核心的部分是：

告警事件的过滤，整体的过滤是依托于告警智能噪音识别来实现的，对于识别为噪音的，可以将其降级，甚至是过滤掉。
告警事件的收敛，这里面包含了 2 种维度的关联信息：

第一种是： 对告警对象在历史上的告警事件进行关联：这个可以给运维专家提供历史上告警信息，处理建议等。

第二种是： 对告警对象当下的相关信息（如上下游拓扑图，相关的告警指标等）进行关联。

收敛下的一个案例是：告警事件的噪音识别。

对于任意一条告警，都可以给他分成以下 4 中类型中的一种：

噪音： 当前告警用处不大，可有可无
新奇： 预期之外的告警事件，或者从未见到和很少见到过的告警
重要： 关键指标的告警
异动： 告警发生频率出现了变化，举个例子：某一个告警事件虽然为噪音，但是之前一天出现 5 次，现在变成 1 天出现 50 次了。那这可能代表系统发生了什么重要的变化。

通过对于噪音事件的分类，我们可以通过 NLP 算法加信息熵模型来计算一条告警所包含的信息量大小。

整体分成四步：

Step 1： 基于自然语言处理和领域词汇库，完成事件内容的词向量化，实现事件最小粒度的度量；
Step 2： 基于信息论中信息熵的概念，结合 tfidf 模型，构建词向量的信息熵值和重要性度量模型；
Step 3： 利用 sigmod，完成事件的非线性和归一化“信息熵”度量；
Step 4： 结合历史事件的处理记录和反馈，构建模型迭代训练与验证。

第二个关键点则是可以对告警事件做关联。这里我们尝试了多种角度的关联信息。包括从基于拓扑的确定性关联，如资源层相关、应用层相关实践、网络调用的关联事件、时间窗口内的变更事件。其次则是可以通过相似性出发，如时间序列的相似性，告警文本的相似性来构建关联。最后，还有从历史上来看的关联性，如历史上相同的事件出现情况，当时的处理人和处理记录情况。

好，到这里呢就分享完了从检测-分析-收敛的三板斧场景的实践。下面我们来介绍一些更加通用化的东西。如果说今天你想去从 0 到 1 去建设可观测 AIOps，那我相信下面的内容你可以直接拿回去用上的。

首先是通用化的 AIOps 算法模型。这里我们对三板斧场景的算法进行了总结和对比，从常见的时空复杂度，样本复杂度，可解释性等多个角度做了对比，这里由于时间原因，不对算法对比做展开，相关内容感兴趣的同学可以会后从 PPT 详细进行对比分析。

那第二个呢则是 AIOps 可以用的工程架构。

在一个 AI 项目中，关键的部分往往是 3 大块：数据层，离线建模，在线服务。

在数据层呢，我们通过构建统一接口的方式，去和时序数据库、日志 Trace 库以及事件中心进行交互。

在具体的 AIOPs 场景需求明确后，我们往往都是先进行离线建模，通过统一的数据接口，获取到对应的数据，并清洗成离线的数据集。再根据具体的模型进行建模和迭代训练。

训练出可用的模型后，可以通过算法平台发布。这里算法服务发布我推荐下 FC 的方案，他主要是可以免运维，同时对多版本功能轻松实现 A/B 测试。

在在线服务层，则是来构建具体的业务逻辑，反馈机制和自监控能力。业务逻辑和算法服务可以通过 api 的方式进行交互。

那具体到可观测 AIOps 的业务逻辑架构，则可以参考这个：

首先是需要和可观测的数据源，可以通过统一的 API 进行交互。另外一个要强调下的则是数据模型，包括像你检测的数据对象模型，根因分析的对象模型等，需要有一个统一的定义。

接入到智能检测后，系统则可以去创建一个定时任务，去进行定时化的巡检。当巡检出异常时，则将异常放入到候选异常对象库中。这时可以通过同步/异步的方式去触发分析模块。

分析模块包括像前面提到的：多维分析，微服务根因定位分析，影响范围分析，关联分析等等。

同时，对于候选异常库，系统存在一个定时收敛逻辑，定时化的对候选故障库的故障进行收敛计算，收敛完的同步更新到故障库中。

最后，实时告警和 dashboard 展示收敛问题列表则和故障库进行交互。

好，详细的看了可观测 AIOps 的智能监控诊断实践、以及介绍了通用化的工程架构、业务架构、算法模型对比后，我们来看一个具体的公有云上的 case。

可观测 AlOps 具体案例

传音控股采用 Spring Cloud 进行全面应用微服务化，应用运行在阿里云容器服务 ACK 之上，并分布在欧洲、亚洲等地区，真正实现多地区服务体系。对于该体系而言，要构建完整可观测体系，挑战非常大。主要包含了 4 个大的痛点：

第一个痛点是观测对象复杂且数量众多：观测对象分布在不同的技术栈和架构中，要实现全面覆盖并有所侧重，是非常大的挑战。

第二个痛点则是排查问线上问题缓慢：微服务化后的业务结构变得复杂，排查线上问题需要分析复杂的调用链路，需要花费很长的时间。

第三个则是内部推广难度大：新业务上线频率高，有些业务为了减少上线工作量，不愿意接入可观测平台，需额外进行推广。

第四个痛点则是监控数据源难以聚合：在实现多地区部署后，每个地区都有一套独立可观测平台，分散在多个地区的可观测数据无法聚合。

其中和可观测 AIOps 最相关的则是排查问线上问题缓慢。我们期待通过 trace 链路诊断和可观测 AIOps 能力的整合，助力诊断效率的提升。

针对这四个痛点， ARMS 提供的解决方案是：

1. 无侵入式接入方案： 只需要在应用部署时添加 2 行注解，自动注入 Agent 实现全链路监控，对代码无侵入，运维团队无需花费精力在可观测平台推广上。

2. 提供统一指标体系： 通过 ARMS 和可观测监控 Prometheus 版，建立覆盖资源层、容器层、服务层、应用层、用户体验层的统一指标体系，实现从零散单点到规模化全覆盖。

3. 全链路追踪诊断： 接入 ARMS 应用监控后，可以非常方便地查看服务的健康状况和依赖关系。在线上出现问题时，以快速拉起全链路的调用链追踪并定位到代码级别，极大的提高排查问题效率。

4. 全局数据聚合： 通过可观测监控 Prometheus版的全局聚合实例及智能报警中心，对部署在全球各地的业务系统进行统一大盘呈现、统一报警。

最后传音控股在建立全新可观测技术能力后，不仅提升问题诊断效率，还大幅提升用户体验。可观测 AIOps 在这里面提供的异常检测、智能诊断能力也是得到了客户的认可。

大模型时代下，可观测 AlOps 将走向何方？

最后，大模型时代下，可观测 AIOps 将走向何方？ 这次的 QCon 分享议题也可以看到，大模型及其应用是非常的火热，大家都在想如何通过大模型来重构原来的应用场景。

在可观测领域，大模型已经在带来了一些新的变化，目前国外的可观测厂商已经通过 chatgpt 的助力，在纷纷秀出自己的可观测大模型的 demo。主要包括了像：new relic 的 grok，在 4-5 月份 chatgpt 刚刚开始火热的时候，率先推出了 Grok，号称可观测领域中第一个生成式 AI 助手。

Datadog 在可观测领域常年处于领导地位，其强大的产品力一直被众多对手竞相模仿。其在今年 dash 大会重磅推出了 AI 的端到端可观测方案，包含从基础设施，向量数据库，模型部署到运维，模型开发，任务编排。此外，还推出了生成式 AI 机器人，BITS.AI，助力 datadog 实现对监控数据的查询，洞察，行为反馈以及组织协作等。另外还值得关注的则是近期 google 刚刚推出的 Duet AI，通过大模型的方式将云产品重新做了一遍，其中和可观测密切相关的如 Promql 生成，这和我们的一些实践不谋而合。

未来，一方面我们期望通过大模型、langchain 的架构，构建可观测领域中的 copilot（副驾驶），实现像日常答疑，数据查询，调用可观测实践工具箱来完成一系列应用场景。另一方面，则期待大模型的通用化理解能力，结合 Agent，构建主驾驶的能力，助力我们在检测、分析、收敛场景中进一步提升模型能力！