关于云原生:面向智算服务构建可观测体系最佳实践

01 构建面向 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 端到端全栈可观测任重而道远。

02 实现本身数据的深刻洞察

（一）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 版上线，欢送开发者体验。

03 每月 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 元
• 旧计费（按量付费）

1. 阶梯一部分：50000000 条 0.0000008（元 / 条） 30（天）= 1200 元
2. 阶梯二局部：100000000 条 0.00000065（元 / 条） 30（天）= 1950 元
3. 总计老本：1200 + 1950 = 3150 元

比照两种计费形式，新计费节俭 70% 以上。

作者：蓟北

原文链接

本文为阿里云原创内容，未经容许不得转载。