剑指大规模 AI 可观测，阿里云 Prometheus 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 的查询延迟如下：
从测试结果可以看出，阿里云 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 服务的持续成长。我们继续努力，为您提供最为可靠的可观测基础数据服务。
