剑指大规模 AI 可观测,阿里云 Prometheus 2.0 应运而生

本文涉及的产品
性能测试 PTS,5000VUM额度
应用实时监控服务-应用监控,每月50GB免费额度
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本文介绍了阿里云Prometheus 2.0方案,针对大规模AI系统的可观测性挑战进行全面升级。内容涵盖数据采集、存储、计算、查询及生态整合等维度。 Prometheus 2.0引入自研LoongCollector实现多模态数据采集,采用全新时序存储引擎提升性能,并支持RecordingRule与ScheduleSQL预聚合计算。查询阶段提供跨区域、跨账号的统一查询能力,结合PromQL与SPL语言增强分析功能。此外,该方案已成功应用于阿里云内部AI系统,如百炼、通义千问等大模型全链路监控。未来,阿里云将发布云监控2.0产品,进一步完善智能观测技术栈。


Prometheus 大家应该非常熟悉,正文开始前,让我们一起来回顾开源 Prometheus 项目的发展史。Prometheus 最初由 SoundCloud 的工程师 Björn Rabehl 和 Julius Volz 于 2012 年开发。当时,SoundCloud 需要一个更高效、灵活的监控系统来替代传统工具(如 Nagios 和 Graphite),以应对快速增长的分布式系统复杂性。2015 年,Prometheus 在 GitHub 上开源,并发布 v0.1.0。紧接着 2016 年随着云原生时代的到来,继 Kubernetes 之后Prometheus 成为 CNCF 的第二个正式项目,随后在 2018 年成为第二个正式毕业项目。2024 到 2025 年 Prometheus 开源社区发布了 3.X 版本,活力不减当年。Prometheus 项目以灵活简单的数据协议,丰富的生态工具链和云原生项目广泛地默认支持,成为云原生时代监控领域的事实规范。


作为国内最早提供 Prometheus SaaS 化服务的厂商,阿里云 Prometheus 团队一直在跟进开源 Prometheus 的开发进展。目前阿里云 Prometheus 上已经有数万客户在使用,每天写入几十 PB 的流量,广泛应用在云产品监控、Kubernetes 监控、业务监控、AI Infra 监控和 AI 推理监控等场景。形成了阿里云上最大规模的观测指标数据生态。


2024 年开始,整个开源技术社区展现出 ALL IN AI 的趋势,推动着 AI 时代的到来。那么 Prometheus 是否会成为上个时代的产物无法适配 AI 时代的业务诉求呢?我们的答案是否定的。恰恰相反我们看到随着人工智能技术的快速发展,AI 技术栈正经历从单点模型到复杂系统、从单模态到多模态、从静态推理到动态服务化的演进。在这一过程中,AI 系统的复杂性呈指数级增长:


  • 模型规模:参数量从百万级跃升至万亿级,训练和推理的资源需求激增,然而算力紧缺是国内短期内难以解决的难题;
  • 系统架构:从单机部署转向分布式集群,大模型服务通过 SGLang,VLLM,Ray 等引擎分布式部署。涉及 GPU/TPU 集群、分布式存储、流水线调度等多组件协同;
  • 数据流复杂性:基础训练需要训练数据、推理请求、特征工程、模型版本等形成多维度数据流。推理服务结合 MCP 工具链形成了远超过往的复杂分布式系统。


大规模 AI 可观测的挑战


大规模  AI Infra


AI Infra 核心关注 AI 模型训练和推理所依赖的基础算力供给。通常我们谈 AI Infra 主要会包括以下几方面:


(1)硬件设备统一监控


AI Infra 管理一些特有的设备以支撑 AI 计算,当然常规 CPU 算力同样需要,统一监控需要覆盖下述场景。


  • 异构硬件管理:GPU、TPU、CPU、FPGA 的混合部署增加了资源分配的复杂性,需要有效的全局监控来提供可靠的基础设施。
  • GPU 健康状态监控:GPU 内存泄漏、温度异常、显存不足等问题可能导致训练中断。
  • 网络与存储 IO:模型训练过程通常涉及大量的网络交换和存储数据交换,继而产生了配套的高性能网络、大规模存储等设施,网络与存储 IO 的波动直接影响训练效率。
  • 能耗与成本控制:AI 训练的高能耗需实时监控以优化资源利用率。


(2)大规模容器集群


我们观察到,大模型训练集群目前基本采用 Kubernetes 架构。OpenAI 在去年底发生大规模故障,核心就是因为 Kubernetes 集群 API Server 发生雪崩问题。据公开信息,早在 2021 年,OpenAI 训练 GPT-3 的集群规模在 7500+ 个节点(远超社区 5000 节点最大规模限制),使用 Prometheus 收集大量指标数据。 本次故障的诱因就是因为节点上安装的遥测组件导致 API Server 故障继而导致雪崩。在阿里云内部,大规模集群节点超过 1w 节点,数十万的 Pod 数量。对于观测组件的挑战非常大,然而全方面的观测能力是必需。针对大规模容器集群的观测数据(指标、元数据、日志等)采集、计算和存储,特别是针对训练集群,离线任务集群等 Pod 变更非常频繁的情况,常规开源的组件都是无法支撑的。


(3)云上异构产品


云上的用户搭建用于训练或推理服务,通常使用到多种云产品。以阿里云为例,灵骏计算或 ECS 等产品提供算力,网络、存储相关产品提供高性能存储和网络,PAI 提供 AI PaaS 平台产品,百炼等提供模型服务。还有正在快速发展的 AI 网关、FC 计算等。目前阿里云已基本实现核心产品的监控数据以 Prometheus 规范统一供给,以实现异构云产品的统一监控。这种统一大大降低了用户获取和使用异构产品监控数据的门槛。


推理 App 架构快速发展


随着 2025 年 DeepSeek 的火爆,大模型推理服务持续火爆,几乎所有的互联网企业、数字化转型企业都已开始搭建企业自己的推理服务。目前我们观察到,常见的 AI 应用架构大概如下:



对于这种新型技术架构,监控指标设计非常重要。通过模型服务服务于模型应用的推理性能、成功率、准确率和成本都是需要重点关注的。对于一次推理的端到端全过程以及每个阶段的关键指标我们认为如下:



  • Time To First Token (TTFT): 首 Token 延迟,即从接收请求到生成第一个 token 的时间,通常要求控制在 2-3 秒内。该指标直接反映 Prefill 阶段的计算效率
  • Prefill 是计算密集型,GPU 的利用率较高,所以也需要观测 GPU 的使用率KV Cache 的利用率
  • Time Per Output Token (TPOT):每个输出 token 的延迟(不含首个 Token),一般需低于 50 毫秒以保证生成流畅性(约每秒 20 个 token)
  • MBU:内存带宽利用率,decode 是 IO 密集型,需要把参数和 KV cache 从显存加载到计算单元,这个过程计算能力一般不是瓶颈,显存带宽才是瓶颈,而在多卡集群的情况下,PCIe 卡带宽或者速度更快的 NVlink 带宽有可能成为瓶颈
  • throughout:吞吐量,即每秒针对所有请求生成的 token 数。这个和 batchsize 有关,与 ttot 和 tpot 都是有制衡作用,推理性能目标是,最快的首个 token 响应时间、最高的吞吐量和最快的每个输出 token 时间。
  • Token 黑洞问题,输入 Token 或输出 Token 循环重复输出,基于 AI 网关识别 Token 黑洞。


推理服务的全面监控对于 AI 应用的稳定运行至关重要。目前,黄金指标体系基本已经形成,新的稳定性问题也在持续出现,通过多模态指标、Trace 和日志数据实现对 AI 应用的观测,我们认为比历史任何时候的需求都更为重要。


MCP Tools 模式的分布式


MCP 定义了模型与工具服务之间的交互协议,这使得模型服务与海量的数字化服务产生了链接。这意味着通用模型服务将托举起一个架构负责的大规模分布式系统。通常对于用户的一个对话需求,背后需要几个甚至几十个 Tools 来完成。其中如果出现性能瓶颈或 Token 黑洞,都会导致整个推理过程不符合预期。因此对于 MCP Tools 本身和上下游的统一监控尤为重要。对于分布式系统的统一监控是 Prometheus 监控体系的核心优势。


多模态可观测数据


Prometheus 社区目前也在与 OpenTelemetry 的融合,推动指标(Metrics)、日志(Logs)、追踪(Tracing)的统一收集与处理。在 AI 可观测场景,完整的洞察方案都是需要结合指标、调用链和日志。以实现快速的故障定位。指标通常用来统计数据、告警、发现问题,调用链负责追逐分布式系统调用,例如 MCP Server 或 Agent2Agent 以定位故障点位或代码行数,日志用以明确具体的故障原因。良好的观测系统依赖业务开发者做好指标定义、和 Trace 埋点。通常需要通过数据计算技术实现多种数据之间的转换,或通过外挂探针技术实现数据精确采集,这些都是可观测方案的核心。


阿里云 Prometheus 2.0 方案


为了应对大规模 AI 可观测的挑战,阿里云 Prometheus 团队总结 1.0 的产品技术在云原生时代大规模落地的经验,重新整合离散的技术,推出了全新的阿里云 Prometheus 2.0 方案。本方案同样全面兼容 Prometheus 社区的协议规范,提供用户全方位的使用体验提升。接下来我从数据采集、存储、计算、查询、数据生态和分析语言、业务系统集成等维度做简要介绍。


数据采集 LoongCollector


团队坚持自研指标采集服务,本次升级进行了全面的重构。将指标采集和服务发现能力全面移植到阿里云开源 LoongCollector,以实现一个支持多模态数据大规模采集的统一组件。目前 LoongCollector 已支持日志、指标、元数据、Profiling 等数据形态。从指标数据看,LoongCollector 架构上区分服务发现模块 LoongOperator 和数据采集 Pipeline Collector。以容器集群数据采集为例,LoongOperator 实现了超 10w+ 的 Target 发现规模和分布式调度,Collector 副本数根据 Target 数量和数据量自动扩容。全面兼容社区 CRD 规范,支持 ServiceMonitor, PodMonitor,Prometheus Rule,PrometheusConfig 等。Collector 部分采用 c++ 实现,在内部使用的场景中,跑出了单核 70 M/s 的性能。同时全面兼容社区 Prometheus Agent,VM Agent 对于指标采集的规范和约定。同等数据规模下,性能较 VM Agent(目前开源实现中性能较好的)内存下降 50%,CPU 下降 20%。在随后的版本计划中,LoongCollector 将发行标准 Kubernetes 集群版、SideCar 版和主机版本,以实现无处不在的数据采集。


大规模时序存储


阿里云 Prometheus 1.0 的时序存储独立建设,与日志、Trace 等数据形态互通性不佳。随着 AI 时代到来以及全栈可观测需求的发展。我们越发认为可观测数据的采集和存储需要统一,生态数据处理能力应该互通。因此在 2.0 版本中,我们将时序存储底层与阿里云日志、Trace 等数据存储形态实现统一。这种统一体现在网关统一,存储层统一,计算和查询技术栈一致。在此基础上,自研全新的时序数据引擎,在内存实时压缩、文件压缩、自适应 Block、多数据类型、支持数据更新等技术上实现突破。在查询计算引擎上,为了充分发挥 CPU 多核、指令加速能力,以及对计算、内存资源的精细化控制。相对于社区目前主流的 Go 语言实现的 Prometheus 计算引擎,我们使用 C++ 来开发新的 Prometheus 计算引擎。新的引擎对于计算流程上及实现上进行了全面改造,实现了更高的性能、稳定性和 QoS 控制。此外在 PromQL 的兼容性测试中,Prometheus C++ 计算引擎与开源的兼容度为 100%。

在线上一些典型的查询场景,目前 Prometheus 2.0 和 VictoriaMetrics 的查询延迟如下:


数据集

中等流量,中等时间线更新率

中等流量,高时间线更新率

大流量,低时间线更新率

15m

30万时间线

短查询

1d

10万时间线

短查询

5m

300万时间线

短查询

VictoriaMetrics Cluster

6631ms

5.72ms

2181ms

42.01ms

8290ms

6.64ms

Prometheus 2.0

1966ms

4.29ms

1283ms

18.49ms

1404ms

3.42ms


从测试结果可以看出,阿里云  Prometheus 2.0的查询性能对比 VictoriaMetrics 在各个场景下全面领先。


预聚合计算(RecordingRule 与 ScheduleSQL)


对于指标相关的预聚合计算的考虑,我们认为除了 Metric2Metric 以外,Log2Metric,Metric2Others 在 AI 全栈观测中应用广泛。Prometheus 社区在 2018 年就引入 RecordingRule 规范和实现。提供以 PromQL 语法框架下的 Metric2Metric 计算。这种能力在阿里云 Prometheus 1.0 版本中同样提供,服务了数千的用户,运行了数万的计算任务。 但我们认为该功能没有达到 Stable 状态。1.0 主要继承了社区的实现,从任务调度上出现较多的调度不均、失效等问题,运维成本较高。


在 2.0 版本中,我们基于在日志服务中广泛使用的调度和计算引擎,重写了 RecordingRule 实现。从调度上解决了调度不均、调度失效、调度性能不足的问题,实现更大规模的指标数据预聚合计算。计算上基于全新的时序引擎,以实现高性能的数据加载和计算。这种计算能力将广泛用于云产品监控,容器监控等场景。通过预计算来解决 PromQL 复杂,容器指标理解门槛高,查询计算成本高等问题。


只有 RecordingRule,我们认为是不够的。我们经常收到用户需求,能不能用类似 SQL 的语法来进行指标计算,因为业务开发者对于 PromQL 的掌握是有门槛的。另外,由于 Prometheus PromQL 的限制,对于涉及多值或更多算子的需求是难以满足的。由于我们将指标存储与阿里云日志存储实现统一,天然集成了日志领域的 ScheduleSQL 计算能力。这是一种类 SQL 的语法,可以实现对指标数据多样化的分析。同样 ScheduleSQL 作用于常规日志数据时,可以直接从日志计算出统计指标存入 Prometheus。全面打通了数据格式间的孤岛。


查询聚合 View


聊完采集、存储和计算,来到数据查询阶段。阿里云 Prometheus 2.0 除了提供标准的单实例 Query、RemoteRead 接口以外,针对统一监控的查询场景提供查询时聚合 View 的产品能力。在 1.0 版本中该功能已经推出并得到广泛使用,它支持跨区域、跨账号的统一查询多个 Prometheus 实例。 这里利用到算子下推、数据自动路由等技术实现数据查询加速。


在 2.0 版本中,得益于底层存储的融合,聚合计算进一步加强。查询引擎升级为通用聚合引擎,底层支持聚合指标存储、日志存储和事件存储,结合 SPL 可以实现异构数据的统一分析。另外在跨区域数据查询上优化了网络链路,性能得到显著提升。


云上指标数据生态


除了技术全面升级以外,阿里云 Prometheus 的核心竞争力是提供了全面的云产品监控数据生态。截止目前,已经超过 80% 的核心云产品底层采用 Prometheus 技术栈采集、存储和计算监控数据。我们通过 Prometheus 标准协议向用户提供最为及时、完善的云产品监控指标,一举从过去分钟级的指标数据提升到秒级。这非常有利于全面上云的用户建立全栈监控。


目前,阿里云 Prometheus 为用户提供灵骏计算、PAI、百炼、AI 网关、 FC 等 AI 全技术栈产品的完整监控数据。


智能分析语言 PromQL 与 SPL


PromQL 是 Prometheus 开源项目带来的指标查询语言。PromQL 通过标签驱动、直观语法、强大运算能力和生态集成,成为现代可观测性指标工具链的核心。它不仅简化了时间序列数据的查询与分析,还通过与 Prometheus 生态的深度整合,为系统监控、性能调优和故障排查提供了高效、灵活的解决方案。无论是开发人员调试微服务,还是运维团队管理云原生环境,PromQL 都是不可或缺的利器。


阿里云 Prometheus 2.0 查询引擎实现了 PromQL 的 100% 社区兼容性,并提供了额外的扩展算子。这使得用户可以无缝转移社区成果到阿里云 Prometheus 服务,没有迁移成本。


对于更高级的数据计算,例如数据富化(增加标签),多模数据联合计算等需求,数据关联查询等需求,我们即将提供一种新的计算形式 SPL。它是一种 Pipeline 模式的数据计算编排,SPL 提供了大量的算子和多路数据提取能力,可以直接作用于数据流处理。用户可以基于 SPL 实现指标数据的实时加工处理。也可以用于与 AI 系统的集成来实现标准的数据提取。指标数据不是可观测的唯一,与日志、Trace、Entity 等数据实现关联分析是故障洞察最为有效的手段。 SPL 为实现该能力提供支撑。


业务分析-大数据生态集成


指标数据除了用于稳定性监控,服务运维人员以外,已经有大量的用户将 Prometheus 技术栈用于业务分析服务于业务和运营。用户通过在业务代码中植入 SDK 来埋点业务指标,通过阿里云 Prometheus 服务提供的可靠采集、存储服务管理数据,最后通过 Grafana 来可视化分析。除此之外,我们还有其他手段来与业务数据打通吗?通常业务系统的离线业务分析会采用大数据技术栈,例如 Flink、Kafka 等。对此,阿里云 Prometheus 服务借助底层统一能力,支持用户通过 Kafka 或 Flink RemoteWrite Sink 等模式,将时序数据从其他数据分析平台写入阿里云 Prometheus。也可以通过数据订阅消费、数据投递等渠道将数据写入大数据分析体系,实现了良好的数据互通性。


新版本的实现从去年开始在阿里云内部投产,截止目前 Prometheus 2.0 已在内部 AI 系统的可观测中全面落地:


  • 单集群规模:常规模式下支持 5K+ 集群节点(10w+ Targets)的采集规模、提供 1 GB/s 的数据采集能力;针对部分超大规模集群,仅需禁用部分通用功能后实现可靠的数据采集。
  • 成本优势:某超大规模推荐系统客户将监控成本降低 40%,同时查询性能提升 2 倍;
  • AI 专用场景:为百炼、通义千问等大模型提供从训练资源利用率到推理 SLA 的全链路监控。


阿里云 Prometheus 2.0 服务正在整合到阿里云云监控平台,通过阿里云云监控控制台对客提供服务。存量 v1 Prometheus 实例我们会逐步后台迁移到新版本。


为了为你提供更为标准的云上服务, 阿里云 Prometheus 2.0 服务的 OpenAPI 体系进行了升级迁移,后续你可以从云监控 2.0 的 API 体系(cms-20240330)中获取到。需要基于 OpenAPI 进行集成的用户需要做出对应的 API 变更,我们在此表达歉意。如果您对本文介绍到的某些特性有兴趣,欢迎通过用户群、工单等形式与我们交流。


结语: AI 观测的未来已来


阿里云 Prometheus 2.0 通过存储、计算、智能分析、生态的全面升级,重新定义了面对超大规模 AI 系统的商业化 Prometheus 方案。其核心价值不仅在于技术指标的突破,更在于实现了可观测数据生态从云上“基础设施层”延伸到“业务模型层”的全覆盖,为 AI 工程化落地提供了不可或缺的观测工具。随着 AI 技术向实时性、大规模化演进,阿里云 Prometheus 2.0 或将成为企业构建下一代 AI 系统的基础设施基石。阿里云 Prometheus 2.0 是阿里云可观测产品族的一员,在不久的将来我们将全面发布云监控 2.0 产品,以提供更为全面的智能观测技术和产品栈。


在此,谨代表阿里云 Prometheus 团队全体开发者,感谢多年以来数万用户的支持和需求反馈,是你们推动了阿里云 Prometheus 服务的持续成长。我们继续努力,为您提供最为可靠的可观测基础数据服务。

目录
打赏
0
7
9
0
12729
分享
相关文章
如何用大模型+RAG 给宠物做一个 AI 健康助手?——阿里云 AI 搜索开放平台
本文分享了如何利用阿里云 AI 搜索开放平台,基于 LLM+RAG 的系统框架,构建“宠物医院AI助手”的实践过程。
142 12
面向 MoE 和推理模型时代:阿里云大数据 AI 产品升级发布
2025 AI 势能大会上,阿里云大数据 AI 平台持续创新,贴合 MoE 架构、Reasoning Model 、 Agentic RAG、MCP 等新趋势,带来计算范式变革。多款大数据及 AI 产品重磅升级,助力企业客户高效地构建 AI 模型并落地 AI 应用。
AI 驱动下的阿里云基础设施:技术创新与产品演进
本文整理自阿里云智能集团副总裁、阿里云弹性计算产品线与存储产品线负责人吴结生在“2025 AI势能大会”上的演讲,重点介绍了阿里云在AI基础设施领域的技术创新与产品演进。内容涵盖CIPU架构、盘古存储系统、高性能网络HPN等关键技术,以及第九代英特尔企业实例、ESSD同城冗余云盘等新产品发布。同时,文章详细阐述了灵骏集群的优化措施和可观测能力的提升,展示阿里云如何通过持续创新为AI负载提供强大支持,助力企业在AI时代实现智能化转型。
AI 驱动下的阿里云基础设施:技术创新与产品演进
阿里云 AI 搜索开放平台新功能发布:大模型联网能力上线
阿里云 AI 搜索开放平台此次新增了大模型联网能力,通过集成大语言模型(LLM)和联网搜索技术,为用户提供更智能、更全面的搜索体验。
271 25
又双叒叕获认可!阿里云AI Stack一体机首批通过国家评测认证
近日,阿里云AI Stack一体机通过了中国电子技术标准研究院的“云上部署DeepSeek验证测试”,成为首批通过该评测的AI大模型一体机。
49 10
阿里云双项入选首批智算一体化权威评估 以AI Stack加速政企智能化升级 ——万卡智算集群服务推进方阵(ICCPA)第三期沙龙在京举办
2024年4月9日,中国信通院主办的智算集群服务沙龙第三期在京召开。阿里云凭借领先的AI技术能力,成为首批通过《面向大模型的智算一体化解决方案》评估的云厂商,并入选行业应用案例。会上,阿里云AI Stack赋能政企大模型高效落地,提供软硬一体推理优化框架,支持主流开源模型快速适配,助力企业构建高性能私有化AI服务,已在政务、金融等领域广泛应用。
从大规模恶意攻击 DeepSeek 事件看 AI 创新隐忧:安全可观测体系建设刻不容缓
本文探讨了中国大模型DeepSeek在全球范围内的成功及其面临的网络安全挑战。DeepSeek以低成本、高性能的特点迅速走红,甚至超越ChatGPT,但同时也遭受了大规模恶意攻击,如DDoS和密码暴力破解。文章分析了这些攻击对AI行业的影响,并提出通过阿里云构建安全可观测体系的解决方案,包括流量监控、日志审计与异常检测等,为AI技术的安全发展提供保障。
阿里云AI Stack全量适配Qwen3模型,企业级部署效率全面升级
2025年4月29日的凌晨5点,阿里全新一代模型通义千问Qwen3正式发布并全部开源8款「混合推理模型」,包含: 6款Dense模型:0.6B、1.7B、4B、8B、14B、32B。 2款MoE模型:Qwen3-30B-A3B和旗舰版Qwen3-235B-A22B。 阿里云AI Stack已适配全量Qwen3模型,可快速部署实现Qwen3模型的开箱即用!
Kubernetes监控:Prometheus与AlertManager结合,配置邮件告警。
完成这些步骤之后,您就拥有了一个可以用邮件通知你的Kubernetes监控解决方案了。当然,所有的这些配置都需要相互照应,还要对你的Kubernetes集群状况有深入的了解。希望这份指南能帮助你创建出适合自己场景的监控系统,让你在首次发现问题时就能做出响应。
89 22

云原生

+关注

相关产品

  • 可观测监控 Prometheus 版