云监控 2.0：全栈智能可观测平台-阿里云开发者社区

云监控 2.0：全栈智能可观测平台

内容介绍：

一、可观测概述

二、Demo演示

三、未来展望

由阿里云智能集团资深产品专家司徒放，分享云监控 2.0：全栈智能可观测平台。

司徒放是阿里云负责云原生可观测产品线的产品经理。

本次介绍一下云监控2.0，这是我们可观测产品线今年最重大的产品升级。在升级的背后的思考，怎样去做全栈智能可观测，怎么理解这个事情。

一、可观测概述

监控就像汽车不能没有仪表盘，一个线上的生产系统要保证正常运行，不能没有监控。监控也是一个历久弥新的技术，早期的监控主要以采集指标为主。随着分布式技术、大数据、微服务、容器化等技术架构出现，系统的运维复杂度急剧上升，除了指标，日志和链路也成为了重要的排查手段。阿里云对应日志发展出了日志服务SLS，对应链路发展出了应用实时监控ARMS。可观测大概是在2016年出现的，把指标、日志和链路作为三个非常重要的支柱做定义，同时也把它具备的问题定位能力作为可观测区别于监控的重要目标。随着云原生的兴起，越来越多的企业有了选择开源和标准化技术选型的新思潮。

可观测也是一样的，它有 Prometheus、grafana、 openTracing 等开源的事实时标准。越来越多的云上的客户在拥抱这些可观测的实时标准。云产品现在也是非常积极的去兼容这些标准。这些标准也成为我们今天去聊云监控2.0的一个非常重要的基础。到了2024年，云监控、ARMS、SLS 三个可观测产品正好走在一起。大家一起重新思考怎么样帮助客户构建可观测才是最优解。从发展图可以看出，经过了大概六七年的三个产品各自的独立发展，肯定会有一些需要解决的问题，比如体验不一致，存在产品割裂的问题。要解决这些问题，需要有一个产品去做打通和融合的载体，这就是我们最初做云监控2.0的初衷。

但是单纯去融合解决割裂问题不是我们最终的目的。2023年，非常多业界大模型上的突破，感觉到可观测领域即将要迎来下一次非常重要的变革机会。在可观测里，基础设施可观测、容器可观测、云产品可观测、应用可观测、用户体验可观测，这些多个层次的可观测已经可以对复杂的IT系统进行从头到脚的完整分析。除了链路、指标、日志这三个支柱外，可观测上还有事件和剖析这两个后背的热门支柱也在跃跃欲试，我们能看到会有越来越多的数据进来。全栈的可观测是一个工程问题。难在假如有一天到了全栈可观测之后，客户做了各种可观测数据接入之后，会产生各种大量的数据，这些数据怎么样产生更大价值，怎么样加速运维排查效率，怎么样提升系统的执行效率，是更重要的难题，需要解答。

大模型出现后， AI天生就好像有很多本科生、硕士生通用的常识，也有更好的学习和理解能力，也有自然语言的对话能力，会说人话，有思考能力，有泛化能力，也有很好的总结能力，这是我们能看到从全栈和观测变成成全栈智能可观测的机会，把海量的全栈可观测数据变成智慧的机会，从而提升运维上效率。

说到怎么把海量数据提炼成信息，形成更加高价值的洞察、智慧，其实早在四十多年前，在知识管理领域或者信息工程领域已经提炼出非常成熟的层次模型，叫做DIKW金字塔。所谓的DIKW，分别是数据、信息、知识和智慧四个英文的首字母。金字塔越往上，它的价值越高。有了这个层次模型之后，从大量的数据抽取、提炼成智慧不是一蹴而就的过程，还可以再细分，中间还有两步。有了细分的迭代后，我们可以更容易逼近最终目标。我们尝试把DIKW金字塔运用到可观测领域，像数据这层对于可观测，大量可观测的数据、日志、指标、链路都是可观测的数据，信息是人基于数据配置出的大盘、大屏、告警，这是人脑对数据提炼，形成信息的过程。知识是我们看大盘、大屏排查的过程，或是自己去写自动化、智能化的工具，做自动化诊断形成的一些东西、知识，沉淀在这里。

智慧是一个更大的集合，一个公司、一个大部门的一个消防应急群里面集中了各种各样顶尖的有十年以上的领域经验运维老司机，可以在出现问题的时候应急排障，他们有一套安全生产的排障流程。这些都是我们落实在金字塔上的、在可观测领域可以看到的分类。不知道大家发现问题没有，这些东西其实说的都是人的问题，都是长在人的世界上的，都是以人为主的，这些东西特别是往上的东西对AI来说并不友好。怎么样把人了解的东西迁移到AI上，让AI也具备同样的智慧呢？这是我们需要去尝试去解决的。

先解决下面那信息和数据这两侧。数据层有一个非常大的问题，就是碎片化的介入。所谓碎片化的介入，就是现在一个公司里有非常多的工种，比如研发、运维、还有质量以及各种管理财务的、管理稳定性的、管理成本的，有很多不同的人员需要介入，就还有各种横向的团队，像SIE团队、DBA团队、云的运维团队、上面业务的运维团队、稳定性团队等，这些人员接入可观测的方式、使用可观测的过程是碎片化的。数据接入后，虽然都是可观测数据，但是可能会落在不同的平台上，导致我们排查的一个问题的时候可能要跨多个系统，有些系统不能导数据，有些系统只能看大盘，可能是存在ES上面，有些是存在国民，有些只能导出excel或者调API。

这些系统之间，如果人去解决还可以逐个沟通、汇聚、获取，但想用AI自动取用这些数据和自动化分析这些数据非常困难：

第一，大量数据形成了一个数据孤岛；

第二，智能化挑战是这些数据即使是摞在一起，也有很多语义模糊。比如grafana是开源大盘的实施标准，但是人配盘的过程，配出来的大盘和那个大盘不一定有什么关系，可能也有关系。它看到大盘的一个曲线出现波动，会看另一大盘对应的东西，但这个关系是缺乏联系的，而且叫法也不同。前一位嘉宾也说到，他们遇到了智能体的问题，像云上、ECS、主机机器，有的人喜欢叫实例，有的人叫节点，用K8s的人又喜欢叫node，同一物种有很多不一样的叫法，同一IP有可能是私网的IP, 但是不是同一实例呢？可能在不同的VBC就是不同的实例，它也有语义模糊的问题。同样描述一个变化的状态，有可能是数字，有可能是英文，也可能是中文。这些东西对于人来说都是能理解的，但是对于AI来说是像天堑、鸿沟一样的事情。要解决这些问题，我们的思路是对碎片化问题，要做一站式的统一接入，做统一化的采集、存储。对语义模糊的问题，有统一的观测模型，通过对观测模型建立数据连接，把信息关联。

首先我们做到的是云监控2.0有一个统一的接入中心。在这个接入中心，我们针对基础设施、云服务、中间件、服务端应用、网关、前端/移动端等不同的层面，它的接入和统一在一个接入中心里面接入，它有日志、链路、指标都可通过这一方式标准化的接入。

今年我们推出了loong collecter，我们之前已经开源了，在此基础上升级了loong collecter，可以对机器上安装的探针做统一管理和采集，有更高的吞吐和非常低的开销。数据采集后统一按日志、指标、链路、事件、剖析还有观测对象等方方面面都会存储到SRC。这些存储对客户都是可见的，可以用统一的数据语言查询分析。基于这套采集、接入和存储的基础设施，我们构建了可观测的应用中心，将阿里云上多个可观测产品做成轻量的应用中心，底层复用可观测能力，背后布用同一套告警体系，数据处理是同一套，有统一的可观测大盘，后面做到的算法也能统一，应用中心也会非常轻量。同一客户的数据对上面的应用可以直接取用，互联互通，这是我们在一站接入的统一采集、统一存储上的解法。

做完后，接下来做是统一观测模型。首先说一下什么叫统一观测模型。不同的接入方式接入后，比如它属于云产品，我们会按照云产品不同的类型抽象出对应的观测对象。应用场景不管是用什么样的SDK或什么样的方式接入，我们都会抽象出对应的应用接口、数据库访问实例等标准的对象。不同的接入方式看到的都是应用。告警实体在Prometheus上面采集的数据，包括安全扫描收集上来的数据，都有对应的像阻击进程这样的一些观测对象创建出来，甚至安全扫描创建出来的AK都会有对应的实体处理。我们构建的这些可观测对象可以因为不用关心用什么方式接入，只关心要关注的对象是什么，然后提供对应的统一功能给最后的客户。之前很多客户遇到的产品间的告警，没办法在同一地方看到。我们可以通过告警通报中心把所有的告警按统一的方式建模，客户就会有一个统一的管理方式。这是在统一观测模型上。另外，对齐语义是怎么体现？大家看到这里的橙色对象，我们在橙色对象上有一些虚线连接，是在不同的领域，比如云产品里叫ECS, 到应用里叫实例，到了告警和事件的场景又叫主机，在这些的跨域场景会做一个对象关联，是一个等价的含义。在这个事情上面再去解决。当我们在跨域中做跳转时，就可以从一个域关联到另一个域。以上是在对齐语义上做的工作。

二、Demo演示

接下来是一个Demo，基于观测对象做全局搜索。如果大家用过mac，可能会对spokesman有了解，如果用windows，就everything，只要在系统弹出的输入框上面搜，就能索引到你关心的文件。云监控2.0里也有一个输入框，只要输入可观测对象的IP也好、名字也好，或者是一些什么样属性，就可以直接到达这个观测对象的主页，不需一个个点击页面。我们发现客户去找观测对象的时候很麻烦，要到不同的控制台，关注的是一个IDS的话，得找到RDS对应的链接，是一个比较耗时的部分。

在左上角散发五彩光芒的菜单，可以同时支持快捷键直接唤起，点击后，我们在这个输入框上可以输入，比如一个实例名称，就可直达这个ACK集群的对应的大盘主页。比如再输入AK链接，就可把AK最近访问过哪些资源，也可搜到有哪些非法的访问。比如arms上的应用，可以把这个应用名输入进去后，一键跳转到arms应用大盘。假设他是一个K80的development, 可以直接跳转。输入一个IP可能有多种含义，比如是一个应用场景下的一个主机，或是一个容器场景下的promt，都可以跳转到对应的大盘。这就是我们基于观测对象可以去做的全局搜索，虽是一个小功能，但能体现整个可观测在背后的数据打通，以及怎么样提高检索可观测数据大盘的效率的功能。

还有一个步骤是当建立完观测对象模型后，对齐了语义，需要去建立观测对象之间的连接，且打通数据孤岛。里面建模这里橙色表示的，一圈圈表示的就是一个个观测对象。背后其实是符合统一的可观测模型，有它的标准在里面。比如说它要有一个名称，它的属性是什么？对于一个观测对象来说，它需要有哪些维度？它的黄金指标是什么样子？它需要有哪些事件关联？我们都会做一个标准化的定义和对齐。这是对于圆圈对象做的设计。我们要进一步会可观测数据的自关联。所谓的自关联是因为有很多可观测的支柱数据，像日志、大盘、指标数据、像链路数据，在一个观测对象上，我们会通过一个数据的连接，把他们的建立起来。在看到一个观测对象的时候，很容易能找到和它相关联的可观测数据。

第三，把观测对象之间的关系也建立了实线的连接，相当于把数据孤岛和孤岛之间建立桥梁。当我们在看一个观测实体的时候，有可能要故障定位，有可能要看到实例，或者可能看到数据库客户端有问题。他想看服务端时，在云监控2.0上面，天然会自动生成一个连接，从客户端直接跳转到服务端，看到对应数据。这个连接的关联是我们在做统一接入，创建观测对象的时候创建。我们会形成一个观测的图谱，在知识领域叫知识图谱，在这叫观测图谱，专门用来描述观测对象之间的关系。

后面也是一个demo，这基于观测图谱做问题排查，是典型的电商微服务系统。现在我们看到一个问题是在微服务的网关上，受到超时告警，我们需要去定位根因在哪里，问题在哪里发生。我现在扮演一个运维的老司机，怎么样去利用云监控2.0去，通过观测图谱层层跳转，排查问题。为方便大家理解，我把这个做成是像一个小地图一样，放到视频的左下角，到时候我在看哪个大盘，哪个实体，这个地方它会标成重点，标成另一高亮的颜色，我们去看一下。

我们现在发现网关异常，进入网关主页面，看到超时的情况。但超时只在某一路口有问题，所以我们直接在入口上定位调用链。在调用链上面，我只要找符合超时要求的这些调用链。现在看到的是一个调用链视图，我们作为老司机可以直接看到这个调用链是一个从数据库导致的问题。

中间的一个链路过程，这些系统有没有问题呢？我们现在一个个排查，在这里看到它的下游系统word系统是没问题的。我们通过关联的跳转能力，直接跳转到对应的客户端，看一下客户端对应的大盘有没有问题。下面已经跳到客户端了，发现客户端这个大盘有慢调用分布的问题。我们再根据关联跳转到对应的可观测大盘。这是服务端的大盘，可以看到服务端的RDS的CPU非常高。同时也有大量的慢查询请求的问题。基本上能确定是由服务端导致的。

这时我们再看关联的慢查询日志，可以发现这个数据库服务端上有一个慢查询日志符合我们刚才在调用链上面看到的查询语句。它慢的原因在这也能定位出来，它扫描过的数据量特别大，一次扫描了37万的数据，返回了二万多条的记录，对数据库的压力非常大。刚才这个排查过程，我是用了飞速的模式去和大家讲一下。实际上运维老师脑海里有一张图，他知道系统间的调用关系是怎样的，按照自己的习惯可以快速做问题定位。这就是人在排查问题的时候怎么把心中的观测图谱变成是实体化的过程。

1.从知识到智慧的智能化建设

我们刚刚讲的是从数据到信息的过程，怎么样把人脑海中的数据孤岛、模糊语义的这些数据关联成更高质量的信息。第二部分，我们要考虑怎么样从信息到知识，从知识到智慧。这是更复杂的过程。来到大模型时代，再去重新思考这个场景的时候，我们就会发现知识过程对大模型有什么挑战呢？有大量的诊断工具、排查手册。那大模型现在看到的是什么？我们可观测的数据量特别的大、工具特别多，但是这些海量的数据，大模型的处理效率跟不上数据规模的膨胀。试想一下，一个线上的分布式系统一秒钟打出来的日志大概相当于从百上千本西游记，一个大模型读的再快，还没有足够的能力把这么多本西游记读完。他的输入的token和成本有关，token是有限的，们不可能把大量的数据都喂给他。

在知识领域，它他的问题是他的效率不够高。另外就是各种各样的信息，特别是在告警发生时，它会形成告警风暴。大量的告警涌入之后，大模型怎么理解这些告警，怎么样处理，变成把这些数据进一步降低维度，这对大模型来说也是一个挑战。还有很多的工具对大模型来说不可运用，这是另外一个人的工具怎么样变成是大模型的工具的问题。然后到智慧阶段，像消防群、老司机都是人脑海里的东西，人的经验没法外化，有时甚至是直觉。对于大模型来说，要做一个问题的定位，这样的场景其实是比较复杂的，有很多不同的故障、根因，排查时牵扯到的系统是不一样的，这特别依赖个体经验。大模型它在怎么样合理拆解这些问题也有比较大的挑战，特别是一个比较复杂的问题，要一步步的规划拆解，要合理的拆解且执行出来也很困难。而且他现在特别容易产生幻觉。

我们现在的建设思路是一步步，还是不要一步登天，还是步步为营去做。首先对于数据规模大、处理效率低这个问题，我们专门针对可观测领域做了可观测的智能体。我们通过copilot做功能的辅助增强。第二，针对复杂场景，我们也不想一步到位，就像自动驾驶一样，现在自动驾驶还在一个非常初期的阶段，我们现在做可观测也是一样的，要做自动化先把自动定速巡航、自动泊车先做了，把一些比较确定的场景先做了，编写成执行计划，大模型编写出执行计划后再去调用可观测智能体，把多个对智能体做组合定位。这是我们在做这块的思路。

然后再具体看一下。我们基于统一的存储去做可观测智能体是依赖刚刚抽象出的统一存储，每一存储都有标准的SPL，可通过标准的SPR查询语法做查询分析。而且我们内置了各种算法和函数，都能够在通用的表格数据上进行分析。

另外，我们对通译千问做了语义检索的增强，对于日志场景，我们做了日志基础模型，日志的查询处理和分析速度大概是正常通用的通义千问的六倍以上。同时也做了可以专门用来分析时间序列的指标类基础模型，同样是在分析指标的时候比一个通用的模型会有更高的效率。基于这些可观测智能体的能力，我们采用copilot产品形态集成，渗透到云监控2.0上做的可客观测应用上面。看demo的时候会看到很多小的魔法棒，用户在点击魔法棒的时候，我们就可以有一个比较明确的场景和使用意图的理解，可以获取到他当时点击这个魔法棒的上下文，同时可以对上下文数据进行优化，让大模型更容易处理问题。同时我们做完这些数据之后，能让对可观测没那么了解的客户直接就洞察分析到这些数据背后的含义。

首先是日志解读部分。比如现在日志的分析器上增加了一个copilot按钮，对异常日志，点击这个按钮会自动查找里面相关联的错误，同时也会给出错误相关的异常对战和解决方案。客户点击的是一个java JBM的GC日志，同样也可以识别，原来这是一个GC日志，它会分析，它会把它展现成一个人更容易阅读和理解的文本反馈给客户，这是我们在日志解读上做的copilot相关的工作。

在时间序列方面，指标、日志、链路都可以生成时间序列，所以时间序列的转化入口是先让客户把大盘指标的曲线图先配出来，然后我们通过点击小魔法棒直接调用到大模型，通过copilot自动分析出时间序列上有哪些异常波动，以及变化的时间点。他还可以根据曲线的含义猜测，比如他是一个社会主义或者朋友圈的话，可以猜测这是一个关于什么的曲线，给出一些相关建议。这是对时间序列相关的智能辅助。对于调用链数据，一般的同学如果不了解调用链的话，不一定能轻易的读懂这个调用链背后想描述什么。

所以在调用链上面我们也给了一个魔法棒，客户只需点击魔法棒，我们通过大模型可以分析出这个调用链当前发生异常的位置和对应的异常原因。比如这个示例是因为SQL语句写错了导致的错误。这个调用链描述了一个错误，但是这是不是错误，调用链本身不知道，但大模型可以分析出SQL语法有问题，给出修改建议。这是在链调用链解读方面的智能辅助。在告警和安全相关领域，我们都会把发告警发出的东西变成事件。一个常见的告警事件比较复杂，有很多上下文信息。对于一般的客户来说，他不一定很容易理解这个事件背后的重点信息，以及修复建议。所以在告警事件上，我们也给了魔法棒，能让客户更容易的理解。这些就是我们在不同的可观测对象、模态上提供的相关辅助能力，都是比较原子化的一些能力。

有了原子化的能力之后，我们进一步想象怎么让他拥有更高级的智慧。接下来的步骤是要在确定的一些场景，比如可观测里面比较常见的，我们要做的是更新洞察、更新定位。在更新定位场景，怎么样利用可观测智能体、可观测的数据存储、可观测图谱，还有积累的案例库的运维知识库。比如在更新定位场景，我们会生成通用的流程描述，我们在输入一个比较确定的场景，大模型会去生成一个相对来说多步的执行步骤、计划，调用我们现有的可观测智能体，也就是工具，它调用这些智能体之后，通过检索数据生成一系列的结果。通过这个循环迭代的方式，能够最终定位问题。我们接下来要介绍problem Insights的产品功能，主要是集成通义千问的大模型做更新洞察，主要特性是面向告警事件做定位和定界，同时也支持和大语言模型copilot做深入交互。

在开始这个demo之前，我先做一个简单的介绍。还是以电商的复杂微服务系统为例。这个系统里面，我们在最下游的微服务应用注入了JVM FullGC故障，导致上游一系列的告警爆出，最终会影响到最终端的客户，用的小程序会发生页面卡顿的报错。这是demo的主要背景。problem Insights的处理流程是把我们现在收到的相关告警事件通过大模型的方式，生成一些执行步骤。相当于病人去医院会先做一系列的体检、数值检查、抽血，做完相关的数据提取后生成检查报告。这份检查报告经过大模型的进一步检查。如果这个检查报告已经比较完整，会进入诊断过程。如果数据不完整，还需进一步去深入调研，还会再走流程。

当进入诊断分析的过程后，会在problem Insights里面生成根因、他现在的影响面、处理建议，这是处理的过程，最后反馈给客户不仅是一个纯文本，更是可视化的一个界面。这个过程的一个要求是需要我们接入ARMS应用监控，同时也要接入前端的用户体验监控，这才可以形成一个完整的链路的跟踪。

这是problem Insights的可视化报告。这个报告由多个告警事件聚合而成，所以它的题目名字比较长。这里定位到了两个问题，FullGC是第一个仪式的根因。第二个不是最终的根因，但它是一个副产品，所以模型识别出来，把它作为第二产物列在这里。根因定位会把整个传播的路径故障，它影响了四个应用的传播路径里关联的指标列出来。

同时，右边会列出影响面。如果接入前端监控，它会把终端用户分布的地域，有哪些用户受影响会列出来，同时它影响到哪些前端应用、前端接口，有哪些后端的服务被影响到了，错误率的变化都会在这里列出来。另外它会有一系列的聚合掉的、和故障相关联的告警。然后这边这个小的魔法棒会触发，点击之后会自动分析根因是什么，我们发现是内存消耗不足的问题，然后让它进一步分析，可以看到大模型是能识别出来线程剖析、对战的核心内存泄露的位置是在某一行具体的语句，这确实也是我们这次注入故障的具体位置。大模型也会通过profile达到对应语句所在的位置。同时它也会给出一个代码的修复建议，虽然修复建议现在还比较简单，但他定位到根因也是一个非常不错的辅助，这是我们提供的problem Insights功能。

三、未来展望

做未来展望。我们刚在一个比较确定的场景上做了根因的动察。未来会进一步把根因洞察的定位能力进一步扩充，我们不仅要做超时问题，还有各种错误，还有很多其他各种类型的问题去做扩充。同时我们也想办法寻找更多的可以开箱即用的明确场景。

比如集群水位的智能洞察，云监控1.0上非常受欢迎的智能水位洞察功能。我们会和大模型结合，做一个更加好用、更加聪明的技术水位洞察。对于很多线上运维有变更，去做变更的洞察，包括对故障的应急处理来说，整个应急处理的过程，我们也是把整个事件、告警和接手的过程记录后，通过大模型的分析给出对应的建议。这是开箱系统的场景、比较确定性的，我们在产品能力上做的事。

第二，把刚才演示用到的copilot背后可观测智能体能通过API的方式开放出来，同时我们也会进一步扩充可观测智能体的工具，让更多的客户可以通过API的方式调用，同时集成在自己的运维场景使用。第三，如果客户觉得我们在智能洞察的流程上比较好用，但他有很多企业的定制需求，需要做一些调整，他可以在我们的这个系统上添加和定制智能体，也可以定制执行计划，可以去在步骤里增加它想要的一些内容，或者调整最后输出的内容格式。

最后总结，云监控2.0是2024年我们做的一个比较复杂的产品升级。我们回顾一下，在数据层，我们为解决数据孤岛的问题，做了上面三个可观测产品的上下分层。我们把底层所有的可观测数据都统一存到了SRS上。对客户来说，这些数据都是自己的资产，都是可以处理的。有统一的一套数据处理语言可以处理、加工它们。我们有一个统一的接入中心，可以做一站式的将各种可观测对象接入。

接入后生成对应的观测对象和观测图谱，有一个更标准、统一的信息数据。我们还有统一的告警和大盘，通过这些基础的能力构建可观测的场景。在智能化方面，我们主要是通过copilot去做原子化的能力，在客户需要的地方唾手可得的使用它，辅助。然后对于一些比较复杂的场景，我们做了problem Insights做根因洞察和根因定位，可以帮助客户进一步的使用根因排查问题，更快的定位到复杂问题。

云监控 2.0：全栈智能可观测平台