作者：蓟北

构建面向 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：

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

  2. 它对咱们的系统一无所知，不知道咱们的目标名，当然它对别的公司供给的监控系统也不知道。

  3. 它其实不大了解用户问这个问题真实的目的，由于它在这儿的布景常识太少了。

也便是说，看起来 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/实例。

核算器：armsnext.console.aliyun.com/price-gb#/o…

老用户如何根据新计费形式进行成本预估

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 才能！