面向智算服务，构建可观测体系最佳实践

作者：蓟北

构建面向 AI、大数据、容器的可观测体系

（一）智算服务可观测概况

对于越来越火爆的人工智能领域来说，MLOps 是解决这一领域的系统工程，它结合了所有与机器学习相关的任务和流程，从数据管理、建模、持续部署的到运行时计算和资源管理。下图是开源 ML-Ops 平台 MLReef 在 2021 年发布的 ML 市场相关工具和平台玩家。时至今日，相关工具与平台玩家数量保持着持续高速增长。当前，随着大语言模型（LLM）从新兴技术发展为主流技术，以大模型为核心技术的产品将迎来全新迭代。

近期，阿里云战略进行了一定调整，确立“AI 驱动，公有云优先”核心战略。在 AI 领域有哪些产品布局呢？

基础设施及服务 IaaS 层

在计算、存储、网络、安全产品中提供以“灵骏”智算服务为特色的软硬件一体化的算力集群服务；

容器即服务 CaaS 层

laaS 层之上以 Kubernetes 为代表的容器技术，已成为云计算的新界面， “ACK 灵骏托管集群”+“云原生 AI 套件” 产品组合可以高效管理异构资源，提供 AI、HPC 等高性能计算场景下的云原生增强能力；

平台即服务 PaaS 层

CaaS 之上的平台即服务 PaaS 层构建了以 “人工智能平台 PAI” 为核心，提供一站式机器学习解决方案；

模型即服务 MaaS 层

提供 “灵机模型服务 DashScope” 、通义大模型和各行业生态大模型、企业专属定制大模型及 ModelScope 魔搭社区供业内交流，围绕 AI 各领域模型，通过标准化 API 提供模型推理、模型微调训练在内的多种服务。

AI 时代下有新技术栈，包括新技术、新数据类型及新工作流。目前可观测领域产品更多服务于应用开发者，针对 ML 开发者也需要配套的工具来更好地进行调试、运维及发布模型服务。为了更好的帮助大家理解，我们先讲讲可观测行业头部企业 DataDog 如何做 AI 可观测。所谓的 AI 端到端可观测即从 Infrastructure，Vector Database 再到 Model 和 orchestration framework。DataDog 早已推出了 OpenAI 即 model 这一层的可观测能力，包括 api 费用、接口响应及 prompt，收获了非常多小客户。

本次 2023 Dash 大会将模型从 OpenAI GPT 模型延伸到了更多模型，基本上实现上面所有模型的可观测能力。随着各种大模型不断丰富，每一次请求涉及到的链路会非常复杂，对于使用方来说都是黑盒。因此 DataDog 推出 LLM Model Catalog，方便开发者去观测链路上各个节点的异常，界面非常类似 APM 服务列表和链路查询功能。基于 Catalog，不仅可以按照模型提供方维度，服务维度，环境维度等进行浏览，清晰看到不同模型性能、请求延迟、请求量以及费用。还可以针对 prompt 进行监控，增加了统一的反馈功能，来对 prompt 结果统一分析。接下来，我们看看国内厂商针对 AI 场景在做进行哪些探索。

（二）Prometheus 云产品可观测监控生态

既然围绕 AI 的可观测要有一套标准体系，谁来做 AI 可观测更为合适呢？我们的回答是 Prometheus，因为他天生契合了云原生架构，在开源领域 Prometheus 处于 Metrics 事实规范的市场地位。

当今多种行业都在做云原生化改造背景下，Prometheus 在架构、功能维度与 Kubernetes 天然集成。它具有自动服务发现、多层次采集能力、生态强大、通用多模指标模型及强大的 PromQL 查询语法等特点。下图是阿里云所提供的全栈可观测能力，里面囊括了上百款阿里云产品的监控，覆盖基础设施、容器、中间件、应用等各个层面，而这些产品监控都由 Prometheus 支撑。

阿里云 Prometheus 集成的众多云产品业务指标，针对云产品多租需求提供了一整套完整的解决方案。每个阿里云云产品除对产品自身指标监控外，同时需要对产品售卖租户指标进行监控。云产品针对租户资源划分主要分为租户独占资源、租户共享资源两种模式，可以给资源打租户标签或云产品自行添加租户信息方式来区分租户。

阿里云Prometheus 监控相对开源 Prometheus 采用采集、存储查询分离架构，采集端具备多租识别和分发能力，存储端内置多租能力，租户之间资源是完全隔离的。阿里云 Prometheus 会每个阿里云用户创建一个 Prometheus 云服务实例来存储用户对应的阿里云产品指标，真正解决了以往监控系统数据分散形成数据孤岛的问题，同时为每个云产品提供了深度定制、开箱即用的大盘和告警能力。

下图是阿里云 Prometheus 接入云产品监控的完整架构，包含以 Pull 模式为主、Push 模式为辅的全场景覆盖。Pull 模式支持云产品以 Kubernetes 或 ECS 部署模式，通过指标暴露、日志或云监控方式来对接；Push 模式支持以 Prometheus 标准的 Pushgateway、Remote Write 协议将指标推送过来，所有接入模式均支持云产品面向自身和租户的两层监控能力。我后面讲到的阿里云 AI 产品可观测就是综合运用了多种接入模式完成相关产品可观测监控接入的。

（三）阿里云 AI 可观测最佳实践

下面我详细讲下阿里云 AI 产品体系如何做端到端可观测体系建设。

最底层 IaaS 层，阿里云以 “灵骏” 智算服务为特色的软硬件一体化设计的算力集群服务，灵骏底层硬件核心由磐久服务器以及高性能 RDMA 网络两部分组成，这里面就包括提供 NAVIDIA A100 高性能 GPU 服务器。灵骏本身是以节点交付的，灵骏集群内可以划分多个分组，分组内包含计算节点。

节点上的计算资源 GPU、RDMA、Nimitz 等组件监控数据自身以 Pushgateway 协议上报的 Prometheus，指标中携带租户标来实现多个租户的隔离。内置的监控大盘支持集群级、节点级 GPU、RDMA 等资源的监控能力，涵盖 IaaS 层常规 CPU、Mem、Disk、Net 以及算力方面的一千余个指标。

高性能算力之上 CaaS 层，ACK 灵骏托管集群提供全托管和高可用的控制面的标准 Kubernetes 集群服务，它作为支持机器学习平台 PAI 的云原生底座。ACK 灵骏集群会默认启用云原生 AI 套件，向下封装对各类异构资源的统一管理，向上提供标准 K8s 集群环境，提供高效、灵活的一站式 AI 平台。

ACK 灵骏托管集群支持对灵骏节点管理，纳入到灵骏节点池。AI 套件增强对异构资源调度，通过 GPU 共享调度和 GPU 拓扑感知调度可以高效地管理 GPU 程序以及 GPU 隔离。GPU 监控 2.0 基于 NVIDIA DCGM 来构建。ACK 灵骏集群内置 Prometheus 监控集成，可以一键获取整个 K8s 集群全部资源、组件的监控采集。节点上安装了 ACK 团队增强的 gpu-exporter 将 DCGM 服务以指标暴露出来，并内置了集群、节点、Pod 维度 GPU 大盘。

这里有一点需要说明，常规 GPU 利用率指标采用 nvidia-smi 查询到整张卡的 GPU 利用率。但 GPU 利用率目前存在一些局限性，如不能告知用户有多少 SM 在使用，用户写的代码到底是真忙还是假忙，代码到底在做单双精度浮点运算（FP32/64）还是在拷贝数据？此时就需要做一些 Profiling 指标，去查看更细粒度的指标信息。

在 PaaS 层，阿里云人工智能平台 PAI，提供了一站式机器学习解决方案。他包含基础设施，计算引擎和容器，计算框架，ML 从数据准备、模型开发与训练及模型部署阶段的全流程产品，应用于金融、医疗、教育等各领域。

PAI 的可观测也是最复杂的，我们需要囊括 PAI 各自产品、容器、节点等相应层面的监控覆盖，每一层的架构、部署方式都有极大差异，接入方式也各不相同。但 Prometheus 存储、查询侧我们做到了一致的解决方案，以各子产品为隔离粒度的面向租户的存储，垂直形成一个租户逻辑实例，单实例支持 100w/s 写入，每个产品可以根据业务情况切分实例单独扩容，逻辑实例可以付费升级成租户独享实例支持用户定义更长存储周期和更高的隔离粒度确保稳定性。如果用户想要所有 PAI 产品的监控数据还可以定义全局聚合实例会返回所有产品监控信息而不占用存储空间。

我们实现了 PAI 产品的全栈可观测能力，支持 EAS 在线推理指标，DLC 训练作业级、节点级、LRN 级资源指标的透出，以及容器组件、节点、Pod 等集群所有资源指标，还有底层基础设施算力节点的全部监控数据采集、存储、展示等全方位能力。

最上层 MaaS 层，模型服务灵机 DashScope 围绕 AI 各领域模型，通过标准化 API 提供模型推理、模型微调训练在内的多种模型服务。内置包括通义千问、白川开源大语言模型在内的 20+ LLM，支持模型推理、定制，并结合 ModelScope 魔搭社区打造下一代模型及服务共享平台。

灵积的监控是通过日志中转方式实现的，灵机将各种 LLM 大模型以及业务网关监控数据写到日志系统，Prometheus 通过内部的流式 ETL 工具实时将日志转成指标数据分发到各租户名下，形成了灵机模型 API 层面的监控覆盖。

正如前面讲到的 AI 时代下有新技术栈，目前的可观测领域产品更多服务于应用开发。当前的 AI 可观测虽然做到了 IaaS、CaaS、PaaS、MaaS 不同层面核心产品覆盖，但整套 AI 体系还有更多可观测需要挖掘和覆盖的场景，真正做到 AI 端到端全栈可观测任重而道远。

可观测借助 AI 实现自身数据的深入洞察

（一）Smart Metrics

可观测离不开告警，告警里有两个核心痛点。一是无效告警太多，AIOps 对告警数据做了统计之后发现真实意图的告警比例仅为 3.05%，典型无效告警配置包括用固定阈值遍历所有应用/接口，敞口告警可能最初配置没问题，运行一段时候后业务变化了告警就失效了。二是告警难配，典型的告警页面仅支持配静态阈值，而真实的指标（比如 QPS）往往是随着业务周期变化的，基于静态阈值的告警配置难、维护难。

Smart Metrics 为了解决上述告警痛点而生，基于历史数据中学习 Metrics 特征，并对未来一段时间内 Metrics 正常变化范围做出预测，生成上下基线。他具有开箱即用免运维、效果可视、准确率高，支持 Grafana 原生告警能力等特征。

事实上用单一模型是难以满足多种曲线类型的，我们采用自研分类算法 + 多模型融合方式，用户可以自定义灵敏度事件等，多模型可以为每种曲线寻找最合适的算法，让我们的产品足够“Smart”。

这里简单介绍两个使用场景。

场景 1： 针对 QPS 波动性明显指标，静态阈值是没法配置的，智能算法可以一键产生上下边界，超出边界的值我们才认为是可以报警的，这样就帮用户解决了如 QPS 等起伏不定指标的告警难配问题。

场景 2： CPU 使用率等一般平稳型指标，会随着新应用上线发生较大变化。传统做法需要对发布后更新阈值，Smart Metrics 可以每天自动更新模型，自动学习新环境，自动生成上下边界，有效减少“敞口告警”问题产生。

（二）Text2PromQL 问答机器人

如果说用算法预测监控曲线基本上成为每款监控产品的必备能力，那 Text2PromQL 则是使用 LLM 解决可观测提效问题的利器。

为什么我们需要自然语言转 PromQL 的智能机器人？PromQL 是 Prometheus 专属查询语言，和传统 SQL 有本质的不同。PromQL 是几乎所有 K8s 应用的运维工程师最经常使用的查询语句，没有之一。写 PromQL 不是一件简单的事，用三个 C 来形容它的复杂性。第一个”C”是”Complex”，PromQL 语法其实是比较复杂的；第二个”C”是”Confusing”， PromQL 是由指标名、算子和 label 组成，指标名有时候会非常难懂。

每个公司都有自己的命名方式，甚至有一些指标是用户自定义的。监控领域关注的指标又多又杂，有时候看文档都看不明白那些指标到底什么意思；第三个”C”是”Commenly”，PromQL 是一个非常常用的查询语言。它不仅能提供运维相关的指标，也可以统计点击率、转换率、SLA 等业务指标，运维、开发、产品、运营都可以用它。综上，PromQL 语法不好学、指标名又复杂，日常工作中用得又多，为了减轻 SRE 工作、降低服务工单，也为了 Promethues、K8s 的推广，我们需要一款自然语言转 PromQL 的机器人。

我们第一步要做的事情是，先看看 ChatGPT 是不是就可以完成自然语言到 PromQL 的翻译了。如果大模型本身就可以很好地完成这个任务，那我们不用开发了。就等着通义千问做大做强，我们直接调用他们的 API 就行。我们做了一些实验，发现 ChatGPT 和通义千问，都不能很好地完成这个工作。以 ChatGPT 为例，我问他“给我写个 PromQL，帮我查一下过去 5min，平均响应时间最长的 10 个应用是啥”。

它给我的回答是：topk(10,avg_over_time(application_response_time_seconds[5m]))

我们看下它哪里错了，首先是指标名的事情，在我们的系统中，根本没有一个叫”application_response_time_seconds”的指标。其次，对平均响应时间的理解也是不对的，正确的例子：

topk(10,sum by (service)(sum_over_time(arms_http_requests_seconds{}[5m]))/sum by (service)(sum_over_time(arms_http_requests_count{}[5m])))

总的来说，通用的 LLM：

它给的 PromQL 语法上是正确的。

它对我们的系统一无所知，不知道我们的指标名，当然它对别的公司提供的监控系统也不知道。

它其实不大了解用户问这个问题真正的意图，因为它在这里的背景知识太少了。

也就是说，看起来 LLM 需要更多的知识……

为了给 LLM 灌知识，我们也做了一些调研。总的来说，有 2 种方案：

第一种是 Fine-tuning： 就是你用足够的语料，对大模型进行微调，这里的微调指的是，你已经改了模型本身的一些参数，或者你在大模型外接了一个小模型，总之除了 LLM 本身自带的参数之外，已经有了你自己任务相关的神经网络和参数了。

第二种方案是 Prompt Engineering，提示词工程：就是我们不会增加或修改大模型本身任意一个参数，我们做的只是在用户问问题的时候，给它带一点上下文，作为额外的知识，来提升回答的准确性。

这两种方案本身没有优劣之分，我们画了一颗决策树，希望能给想要做 LLM-based 应用的同行们一些我们的经验。

既然选择了 Prompt Engineering 提示词工程，下一个问题就是，什么样的提示词是有用的。

我们花了好几个月的时间，尝试了 5 种的提示词，终于，把 Text2PromQL 准确率从 5% 以下，提升到了百分之 70-80%。我们的探索过程使用过 PromQL 官方文档、Stack Overflow 社区问答、阿里云 ARMS 内部客户 QA 问答（这里包含了我们自己系统的指标名信息）、ARMS 内部 PromQL 问答示例 + ChatGPT 生成的 PromQL 解释等手段准确率可以到 20% 左右。

直到引入 Chain-of-Thought 格式 PromQL 问答示例，准确率一下子提升到 60-70%，终于迎来了第一个拐点。最后我们基于 Chain-of-Thought 格式 PromQL 问答+通义千问，准确率原地涨了 10%，达到 80% 左右。即使不完全对的场景，也给了指标名、该用的算子等非常有用的信息，而且语法基本不会错了。通义千问确实很厉害！

Chain-of-Thought 是 Google Brain 实验室提出来算法，本来用来增强 LLM 推理能力的，它的提示词是带有推理步骤的知识。推理过程很像解小学数学题。

普通提示词：

Q：Roger 有 5 个羽毛球，他又买了 2 桶，每桶有 3 个，那他现在有几个。

A：答案是 11。

理论上，LLM 应该能照葫芦画瓢回答出来，但是他的答案是错误的。

Google 给的 Chain-of-Thought 提示词：

Q：Roger 有 5 个羽毛球，他又买了 2 桶，每桶有 3 个，那他现在有几个。

A：Roger 本来有 5 个球，买了 2 桶，每桶 3 个的球，也就是 6 个球。5+6=11。所以答案是 11。

这里就是给了例子中的推导过程。

然后，奇迹发生了，GPT 居然就会了，给了正确的答案。

下面我们来介绍 CoT 算法，在 Text2PromQL 场景下是怎么使用的。

这是我们的架构图，我们拥有一个离线系统和一个在线系统。在离线系统中，我们将 ARMS 多年沉淀的，大量用户关于 Text2PromQL 的问答示例，通过 Chain-of-Chain Prompting 算法，转换成 Chain-of-thought 格式 Q&A 示例，然后进行文本切割，得到 Q&A 示例。然后通过 embedding，将文字转换为数字组成的向量。再把这些向量存到数据库中；在线系统中，当一个用户提问，比如写一个 PromQL，查平均响应时间最长的 10 个应用，我们会把这些文字通过 embedding 转换成数字组成的向量。

现在我们拥有了用户问题转换出来的向量以及离线系统中数据库中一系列向量。那么，我们就可以在数据库中检索和当前用户问题最相似的 topk 个向量，把这个 k+1个数字组成的向量还原为文字，然后把用户的问题以及 k 个最相似的历史 Q&A 作为提示词输入到大模型中，从而可以得到最终 PromQL。可以看到，我们这个系统初始的输入是用户的 PromQL 问答示例，所以当用户问得越多，我们能覆盖的场景也越多，准确率也会越高，总的来说，我们的机器人会越问越聪明。

我们当前覆盖了 20+ 场景，准确率 76.9%。即使在没有覆盖的场景下，也能给出非常多有用的信息。更重要的是，因为我们是 Prompt Engineering，通过给提示词增加模型的准确率，所以覆盖新场景非常快，只要给它生成 CoT 格式的提示词就好。目前 Smart Metrics 和 Text2PromQL 已经在阿里云可观测可视化 Grafana 版上线，欢迎开发者体验。

每月 50GB 免费额度让 Prometheus 成本更低、更可控

近期，可观测监控 Prometheus 版发布新计费模式，屏蔽原有上报指标采样点数量、存储时长等计费项，以实际写入数据量（GB）进行计费。

新计费模式单价 & 免费额度：

Prometheus 包含基础指标、自定义指标。其中，基础指标以容器服务产生的基础指标举例，默认存储 7 天且免费，不占用 50GB 免费额度。自定义指标以云服务器 ECS 实例举例，每日上报指标量 24.5 万/实例，每日数据写入量约 0.093GB/实例。

计算器：https://armsnext.console.aliyun.com/price-gb#/overview

老用户如何基于新计费模式进行成本预估

1）基本条件

1 条上报指标约 0.5KB；

🔔 注：不同使用模式下存在一定数据量差异，实际使用时请关注。

2）新老对比

以中小企业通常每日上报自定义指标 15000 万条 ，数据保存 30 天举例。

新计费（按量付费）

每月成本：150000000（条） * 0.00000048 （GB/条） * 0.4（元/GB）* 30（天）= 864 元

旧计费（按量付费）

阶梯一部分：50000000 条 * 0.0000008（元/条）* 30（天）= 1200元
阶梯二部分：100000000 条 * 0.00000065（元/条）* 30（天）= 1950元
总计成本：1200 + 1950 = 3150元

对比两种计费方式，新计费节省 70% 以上。

点击此处，了解更多 Prometheus 能力！