Agent 时代的可观测：上云托管 Prometheus 与自建方案的成本与性能解析 - 文章 - 开发者社区

点击上方 👆蓝字关注我们！

picture.image

Prometheus 作为云原生监控领域的事实标准，自发布以来已得到广泛应用。近年来，LLM 和 Agent 快速落地，根据 Gartner 预测，到 2026 年底近 40% 的企业应用将嵌入 AI Agent，而两年前这个比例还不到 5%。企业的可观测对象也相应已经从传统的基础设施和业务服务，扩展到 LLM 服务调用路径、向量检索、消息队列以及各类 Agent 应用。对应的监控指标也从 CPU、内存、QPS，变成了 Token 消耗、上下文窗口占用、队列深度等新型维度，采集量和写入压力持续加码。

对于依赖自建 Prometheus 的团队来说，这意味着更频繁的扩容与容量规划、更复杂的远端存储与多副本高可用方案 ，以及持续走高的硬件和运维成本 。

火山引擎托管 Prometheus 服务 VMP（Volcengine Managed Service for Prometheus ），针对 Agent 时代对可观测的新要求做了能力升级——除了支持与开源 Prometheus 兼容的读写协议，提供按量计费、长周期存储、多租户隔离与企业级 SLA 保障等能力，还作为统一的底层时序存储，支撑着火山方舟、ArkClaw、VeADK 等多款 AI 产品的可观测能力及服务，并将这些一线实战经验，直接沉淀为 VMP 对外提供的能力。

本文将以典型的读写压力测试为例，系统分析上云托管与自建 Prometheus 在性能与成本上的差异，为企业在 AI Agent 时代构建适配的可观测方案提供参考。

性能对比分析

我们分别在以下三个典型场景中对 VMP 与开源 Prometheus（v3.8.0 ）的性能表现进行测试：

不同采集规模下的性能表现： 模拟不同数量的 Node Exporter 持续采集写入和查询的场景。
长周期与大盘加载查询性能： 模拟在 Kubernetes（K8s ）监控中的典型 kube-state-metrics + cadvisor 指标下，Grafana 大盘的查询场景。
典型 Histogram 查询性能： 模拟对 Histogram（直方图）数据进行分位数计算的复杂查询场景。

不同采集规模（Targets ）下的性能表现

如前文所述，在 Agent 观测场景里，引入了LLM 调用、Agent 状态机、向量检索等监控指标，整体采集规模进一步增大。

在性能对比测试中，我们采用标准化的负载生成与查询流程来模拟真实场景下不同规模采集下的性能表现，整体架构如下图所示。Prometheus 开启 remote_write 开关，vmagent 双写 Prometheus 和 VMP。vm-alert 调用 /api/v1/query 接口执行即时查询，query-range 调用 /api/v1/query_range 接口执行区间查询（1h / 6h / 12h / 24h ）。alert-rules 包含了 33 个常用的告警规则。

picture.image

采集频率默认为 10s，实际测试每个节点采集的 node-exporter 相关指标序列数在 1300 左右。

100 Targets 场景

在这个场景下，我们首先模拟了 1% 的低指标动态变化率（Churn Rate ），持续写入数据超过一天。

测试环境： 开源 Prometheus 部署于 32 核 64GB 内存的服务器。
写入速率： 约 12,000 样本 / 秒 (samples / s)。
活跃序列数： 约 75 万。
日写入点数： 11.3 亿。

picture.image

图示：在 100 采集目标、

低动态变化率场景下的写入速率与活跃序列数

对于区间查询（1h / 6h / 12h / 24h ），VMP 的查询延迟略低于开源 Prometheus。

picture.image

图示：区间查询 QPS 及延迟对比

（100 Targets，低变化率）

在即时查询场景，开源 Prometheus 查询表现则更优。

picture.image

图示：即时查询 QPS 及延迟对比

（100 Targets，低变化率）

Prometheus 的 CPU 使用率不到 1%，内存使用率 20% 左右。

picture.image

图示：开源 Prometheus 资源使用率

（100 Targets，低变化率）

接下来我们使用 90% 的动态变化率，持续写入超过 1 天。对应 ECS 机型为 32C64G。每秒写入 samples 速率接近 13k samples / s。小时活跃时序数约为 150w，日写入 sampes 数为 11.3 亿。

picture.image

图示：在 100 采集目标、

高动态变化率场景下的写入速率与活跃序列数

对于区间查询（1h / 6h / 12h / 24h ），VMP 表现成功率高于 Prometheus，查询 P90 / P95 / P99 延迟也远低于 Prometheus。

picture.image

图示：区间查询延迟对比（100 Targets，高动态变化率）

在即时查询场景，VMP 继续保持稳定，查询延迟远低于 Prometheus。

picture.image

图示：即时查询延迟对比（100 Targets，高动态变化率）

Prometheus 的 CPU 接近 70%，内存使用率不到 30%。

picture.image

图示：开源 Prometheus 资源使用率

（100 Targets，高动态变化率）

500 Targets 场景

我们把采集目标数量提升到 500，指标动态变化率为 1%，并把开源 Prometheus 的服务器规格提升至 64 核 128GB 内存，持续写入超过 1 天。

写入速率： 约 41,000 样本 / 秒 (samples / s)。
日均写入样本数： 约 38 亿。
小时活跃序列数： 约 56 万。
日写入点数： 38 亿。

picture.image

图示：在 500 采集目标场景下的写入速率与日均写入样本数

Prometheus 监控到的序列数在 560k 左右。

picture.image

图示：开源 Prometheus 活跃序列数（500 Targets ）

首先看区间查询（1h / 6h / 12h / 24h ），Prometheus 有部分请求失败，VMP 在查询成功率上持续保持稳定，延迟远低于 Prometheus。

picture.image

图示：区间查询性能对比（500 Targets ）

对于即时查询，Prometheus 表现相对稳定，没有出现失败的查询，但查询延迟远高于 VMP。

picture.image

图示：即时查询延迟对比（500 Targets ）

Prometheus 的资源使用率，CPU 和内存都在 30% 水位以下。

picture.image

图示：开源 Prometheus 资源使用率（500 Targets ）

1000 Targets 场景

当采集目标数量增加到 1000（指标动态变化率 1% ）时，开源 Prometheus 的性能瓶颈开始显现。

picture.image

图示：区间查询性能对比（1000 Targets ）

对于即时查询，Prometheus 依然在运行 6 个小时左右后达到性能上限。

picture.image

图示：即时查询性能对比（1000 Targets ）

Prometheus 的资源 CPU 接近 70%，内存不到 30%。

picture.image

图示：开源 Prometheus 资源使用率（1000 Targets ）

测试总结

场景

指标

火山引擎 VMP

开源 Prometheus

| |

100 Targets （约 1.2w samples/s ）

实例规格

—

32C / 64G

| |

即时查询

性能稳定

表现更优

| |

区间查询 (1h-24h)

延迟略低 （例如 1d 查询约 1.5s ）

延迟稍高

| |

资源使用

—

CPU < 1%, 内存约 20% （高负载下 CPU 接近 70% ）

| |

500 Targets

实例规格

—

需升配至 64C / 128G

| |

即时查询

延迟远低于 Prometheus

表现稳定，但延迟较高

| |

区间查询 (1h-24h)

持续稳定，成功率高

开始出现部分请求失败 ，延迟显著高于 VMP

| |

资源使用

—

CPU 和内存均在 30% 以下（低负载）

| |

1000 Targets

实例规格

—

64C / 128G

| |

即时查询

持续稳定

运行约 6 小时后达到性能上限 ，查询延迟急剧增加

| |

区间查询 (1h-24h)

持续稳定

失败 QPS 持续增长 ，延迟达到最大值并超时，基本不可用

| |

资源使用

—

CPU 接近 70% ，内存约 30%，已达性能瓶颈

结论： 开源 Prometheus 在 500 targets 规模下便开始暴露性能问题；在 1000 targets 规模下，即便使用 64C / 128G 的高配机型，也无法稳定支撑查询压力。相比之下，VMP 在较大规模、高 Churn Rate 场景下性能表现更优。

长周期与大盘加载查询性能

不同采集规模下的性能差异是一方面，但实际观测 AI 和 Agent 链路时，长周期大盘查询也很常见——比如回溯 Agent 一周的 Token 消耗趋势，或者排查某次 LLM 调用的上下文窗口异常。本节基于 KSM 大盘的加载测试，对比两种方案在多时间范围下的真实体验。

测试场景：

模拟 255 个 K8s 节点、7800+ Pods 的集群，持续采集 KSM 指标超过 7 天，对比加载 Grafana 大盘的查询延迟，使用 kube-state-metrics-v2 (https://grafana.com/grafana/dashboards/21742-object-s-health-kube-state-metrics-v2) 大盘进行加载测试，共计加载 42 个请求。

24 小时查询对比，VMP 在 3s 左右，Prometheus 在 11s 左右：

picture.image

图示：加载 24 小时 KSM 大盘的查询延迟对比

*（*左：VMP，右：开源 Prometheus ）

48 小时查询对比，VMP 在 5.7s 左右，Prometheus 在 16s 左右：

picture.image

图示：加载 48 小时 KSM 大盘的查询延迟对比

（左：VMP，右：开源 Prometheus ）

7d 查询对比，VMP 在 13s 左右，Prometheus 在 28s 左右：

picture.image

图示：加载 7 天 KSM 大盘的查询延迟对比

（左：VMP，右：开源 Prometheus ）

测试总结

查询范围

火山引擎 VMP 平均延迟

开源 Prometheus 平均延迟

性能对比

| |

24 小时

约 3s

约 11s

VMP 快约 3.7 倍

| |

48 小时

约 5.7s

约 16s

VMP 快约 2.8 倍

| |

7 天

约 13s

约 28s

VMP 快约 2.2 倍

结论： 对于长周期查询，VMP 的查询延迟整体更低。

典型 Histogram 查询性能

Histogram 分位数计算一直是监控里的复杂查询。到了 Agent 观测时代，LLM 调用延迟、上下文窗口占用分布分位数计算变得频繁，对 Prometheus 的性能挑战也更突出。

测试场景：

通过 histogram_quantile 函数对不同规模的原始序列进行聚合计算。

指标名称：

mock_metrics_http_request_duration_seconds

维度：

account_id（1000 个）
bucket（16 个）
path（2 个，/query 和 /query_range ）

value： 随机取值

总共启动 100 个 Pod 进行打点测试。

  
# ~3.2w原始序列  
histogram_quantile(0.99,sum(rate(mock_metrics_http_request_duration_seconds_bucket{pod="mock-metrics-57459cc9df-68rb2"}[30s])) by (le))  
# ~10w原始序列  
histogram_quantile(0.99,sum(rate(mock_metrics_http_request_duration_seconds_bucket{pod=~"mock-metrics-57459cc9df-mzkpq|mock-metrics-57459cc9df-kvwgw|mock-metrics-57459cc9df-q55st"}[30s])) by (le))  
# ~160w原始序列  
histogram_quantile(0.99,sum(rate(mock_metrics_http_request_duration_seconds_bucket{path="/v1/query"}[30s])) by (le))  
# ~320w原始序列  
histogram_quantile(0.99,sum(rate(mock_metrics_http_request_duration_seconds_bucket[30s])) by (le))

测试结果对比如下：

原始序列数

查询范围

火山引擎 VMP

开源 Prometheus

| |

~3.2w

~680ms

~1.48s

| |

~1.4s

~8.45s

| |

12h

~2.2s

~11.04s

| |

~10w

~1.5s

~4.25s

| |

~4.7s

查询失败

| |

12h

~7.0s

查询失败

| |

~160w

即时查询

~10.7s

~6.3s

| |

5m 区间查询

~12s

| |

~320w+

即时查询

~24s

查询失败

| |

5m 区间查询

~27s

查询失败

成本对比分析

在明确性能边界之后，实际选型还需要权衡资源投入、运维人力和风险成本。本节以一个中等规模 Kubernetes 集群为例，对比托管 Prometheus 与自建方案在总体拥有成本上的差异。

假设集群中部署了 node-exporter、cadvisor 和 kube-state-metrics 及其他业务 pod 总计约 300 个 Pod，基础指标的活跃序列数约为 6 万（未包含其他业务指标），采集频率为 15 秒，每天写入 3.5 亿数据点,一个月写入 100 亿 + 数据点。

node-exporter：1300 序列数每节点 * 10 = 13000
cadvisor：120 序列/pod * 300 = 36000
ksm: ~10000

pod: 40 * 300 = ~1200
node: ~6 * 10 = ~60
deployment / sts等: ~5000

成本类型：硬件/资源成本

火山引擎 VMP 成本

按需付费，弹性伸缩，无资源闲置。
无需为峰值预留大量冗余资源。

按月写入基础指标 200 亿，自定义指标 100 亿，存储 30d，购买资源包规格 vmp_month_small_30d，总成本约为 1999 元/月 。

开源 Prometheus 自建方案成本

需要采购或预留高规格物理机 / 虚拟机
为保证高可用，至少需要双倍或更多的资源。
资源利用率难以优化，存在浪费。

按照 prometheus+alertmanager 组件+EBS 自建维护方案

计算节点：按 8c/32GB，2 个实例做高可用，预估费用为 ecs.g3i.2xlarge *2=2027元/月

EBS: 1000GB * 2 * 0.5元/月 = 1000元/月

Alertmanager：ecs.g3i.large * 1 = 253.38 元/月

总成本约为 3280 元/月 。

成本类型：运维人力成本

火山引擎 VMP 成本

非常低
服务由火山引擎专家团队维护，用户无需关心部署、扩容、备份、故障恢复。

开源 Prometheus 自建方案成本

需要约 2 人天/月的 SRE/DevOps 工程师人力投入。
工作内容包括：

部署与配置 Prometheus Server。
搭建和维护远端存储（Thanos/Cortex 等），架构复杂。
设计和实现高可用（HA ）与灾备方案。
监控 Prometheus 自身状态，处理性能瓶颈。
手动进行容量规划与扩缩容操作。

成本类型：风险与隐形成本

火山引擎 VMP 成本

企业级 SLA 保障 ，服务可用性和数据可靠性高。
安全合规 由平台负责。

开源 Prometheus 自建方案成本

数据丢失风险： 单点故障、存储损坏等都可能导致监控数据永久丢失。
服务中断风险： 性能问题、配置错误等都可能导致监控系统不可用，影响业务故障排查。
技术债： 自建方案维护复杂，容易成为团队的技术负担。

功能与运维能力

除了性能与成本之外，监控系统在高可用性、弹性伸缩、多租户隔离等能力上的差异，同样会直接影响长期运维负担和团队效率。本节从功能与运维视角，对托管服务与自建方案进行对比。

功能/运维维度

火山引擎 VMP

开源 Prometheus 自建方案

| |

兼容性

基本兼容 PromQL、Remote Write/Pushgateway/Query 等，可平滑迁移。

业界标准。

| |

长周期存储

内置支持 ，开箱即用，支持多年数据存储与高效查询。

需自行搭建 远端存储（如 Thanos、Cortex ），架构复杂，维护成本高。

| |

高可用性 (HA)

默认提供 ，服务自带跨可用区容灾能力。

需手动实现 ，例如部署多副本、配置 Federation 等，方案复杂且易出错。

| |

弹性伸缩

自动伸缩 ，根据业务负载自动调整资源，无需人工干预。

手动扩容 ，过程复杂，可能需要停机或数据迁移。

| |

流控

精细化流控 ，保障整体可用性

支持多个子账号查询鉴权限流能力
慢查询分析与自定义封禁能力

原生不支持 ，需要借助第三方方案或者自行开发实现。

| |

多租户隔离

内置支持 ，提供 Workspace 级别的资源隔离与权限管理。

原生不支持 ，需要借助第三方方案或自行开发，实现不完善。

| |

查询加速

内置查询加速与降采样 ，优化长周期查询性能。

需自行实现 ，例如配置 Recording Rules，但灵活性和效果有限。

| |

统一监控工作空间

提供统一视图 ，聚合管理多个集群/环境的监控数据。

需借助 Global View 等方案 ，配置和维护有一定成本。

| |

集成与支持

与火山引擎其他云产品（如 VKE、ECS ）深度集成。
提供专业的技术支持和 SLA 保障 。

社区活跃，配套工具和方案丰富。
无商业级支持，问题排查依赖社区和内部专家。

总结

目前，托管 Prometheus（VMP ）已经在火山引擎内部大规模落地，全栈可观测平台将 Agent 运行时指标、大模型调用行为、Token 成本等数据，与集群和业务指标统一接入 VMP，通过同一套 Prometheus 采集和查询体系进行管理。这使得基础设施、业务服务、智能体运行过程能够实现端到端观测与联动排障。

基于内部实践与本次测试，我们总结出以下结论：

性能更优： 在不同采集规模以及长周期、大盘加载、Histogram 等典型查询场景下，VMP 的整体查询延迟通常比自建方案快 2 倍以上 。
成本更低： VMP 的总体拥有成本约为自建方案的 50% – 60%。 按量付费与自动伸缩能力有效减少了资源冗余和运维人力投入。
稳定性更强： VMP 内置跨可用区多副本容灾、精细化流控、多租户隔离、查询加速等能力，并附带专业技术支持与企业级 SLA，可显著降低大规模监控系统的稳定风险和运维复杂度。
选型建议： 对于规模较小、变化不频繁且有明确资源与运维预算的场景，自建方案仍可满足基础监控需求；但在跨环境、多租户或长周期分析等需求下，建议优先评估托管方案。

综合来看，对于大部分 AI、Agent 及传统的可观测场景，上云托管 Prometheus 相比自建方案在性能、成本、稳定性上均有一定的优势，是企业上云监控选型更务实的一种选择。

VMP 现已支持 MCP Server，可以帮助运维人员在故障排查、数据分析等场景中实现基于自然语言驱动的指标查询与分析，提升运维观测效率。具体可以参考《对话即运维：基于 MCP 服务管理 VMP》最佳实践：

https://www.volcengine.com/docs/6731/2095997?lang=zh