关于阿里云:对比开源丨Prometheus-服务多场景存储压测全解析

作者： 智真

在 Gartner 公布的 《2023 年十大策略技术趋势》[ 1] 报告中,「利用可观测性」再次成为热门趋势。用户须要建设可观测体系来兼顾、整合企业数字化所产生的指标数据，并以此为根底进行反馈并制订决策，这对于进步组织决策有效性和及时性，将是最强有力的撑持。

新需要带来新反动，Prometheus 产品应运而生，引领新一轮可观测技术反动。得益于良好的产品设计，Prometheus 部署与轻度应用体验十分晦涩：敲两三个命令就能运行起来，配置几行 yaml 就能收集数据，编辑一个规定就能触发告警，再配合上 Grafana，写一句 PromQL 就能画出趋势图表。所有简略而美妙，好像 SRE 光明的将来正向咱们招手，这所有来的太忽然，它真的如此轻易么？

当然不是。

Prometheus 用良好的用户接口覆盖了外部简单实现。深刻其中，咱们会看到时序数据存储、大规模数据采集、工夫线高基数、数据搅动、长周期查问、历史数据归档等等。像潜藏在平静湖面下磨牙吮血的鳄鱼，静待不小心掉进坑中的 SRE 们。

主观的讲，这些问题早已存在，并不是 Prometheus 带来的。云原生的到来让这些问题变得更显著且难以回避。想解决这些问题，须要投入大量人力、物力和精力。作为国内当先的云服务提供商，阿里云提供了优良的可观测全套解决方案，阿里云 Prometheus 服务正是其中重要一环，相比于开源版本 Prometheus，阿里云的 Prometheus 服务无论是易用性、扩展性、性能均有大幅度晋升。 明天，咱们将联合企业日常运维过程中常见疑难场景，将两者存储能力进行比照。

测前概念解读

在开始前，咱们先论述测试过程中波及的问题与概念。

1. 工夫线（Time Series）

工夫线的概念在 Prometheus 中十分重要，它示意一组不雷同的 label/value 的汇合。比方 temperature{city=”BJ”,country=”CN”} 和 temperature{city=”SH”,country=”CN”}就是两条不同的工夫线。

因为其中的 city 这个 label 对应的值不同；temperature{city=”BJ”,country=”CN”}和 humidity{city=”BJ”,country=”CN”} 也是两条不雷同的工夫线，因为在 Prometheus 中，指标名称也对应一个非凡的 label __name__。工夫线中的 label 会被索引以减速查问，所以工夫线越多存储压力越大。

2. 工夫线高基数（High Cardinality）

如果指标设计不合理，label 取值范畴宽泛，如 URL，订单号，哈希值等，会造成写入的工夫线数量难以预估，会产生爆炸式增长，为采集、存储带来微小挑战。对于这种状况，咱们称之为工夫线高基数或者工夫线爆炸。工夫线基数过高带来的影响是全方位的，如采集压力大，网络和磁盘 IO 压力大，存储成本上升，查问响应缓慢等。

高基数场景常见应答思路有两种：依附时序存储自身的能力，或更优良的架构来硬抗压力；或应用预聚合 / 预计算等伎俩来被动升高基数。阿里云 Prometheus 在两方面都进行了很多优化和加强，但开源版本中并没有提供残缺预聚合 / 预计算性能，所以此次测试中不会波及到预聚合 / 预计算。

3. 高搅动率（High Churn Rate）

高搅动率是高基数的非凡场景之一，如果工夫线的“寿命”很短，常常被汰换，这种场景咱们称之为高搅动率。比方 k8s 场景下，deployment 每次创立新的 pod 时，都会产生新 pod name，即旧 pod 相干工夫线被淘汰，新 pod 相干工夫线被产生进去。如果经常性产生重启（或相似场景），那么可能从某个工夫点来看，工夫线并不多，但在较长时间范畴来看，工夫线总量可能就很宏大。换句话说，在高搅动率场景下，“沉闷”的工夫线不肯定很多，但累积工夫线总数十分宏大，所以对时间跨度较大的查问影响尤其重大。

阿里云 Prometheus 服务与开源版本 Prometheus 能力比照↓

Prometheus 官网提供 兼容性测试工具 [ 2] ，阿里云 Prometheus 服务在最次要的 PromQL 测试类别中，兼容性为 97.06% [ 3] 且无需应用 tweak，综合体现 优于 AWS 和 GCP [ 4] 。

测试场景

测试工具和测试数据计算

1. 测试环境

本次测试应用的 Prometheus 版本为 2.40.1，即截至 2022-12-20 的最新开源版本。阿里云 Prometheus 服务和部署开源 Prometheus 应用的 ECS 均位于阿里云张家口 Region。

2. 测试工具

咱们应用 VictoriaMetrics 提供的 prometheus-benchmark [ 5] 来执行此次测试，在应用过程中咱们也发现了此工具存在不反对 query_range 测试，churn 逻辑谬误等问题，所以咱们进行了 Bug 修复和性能加强，为了保障测试通明及可参考性，我的项目寄存在 GitHub 上 [ 6] 。测试工具的整体架构如下图：

3. 测试条件设置

默认应用 node exporter 作为指标数据源，node exporter 产生的工夫线数量和物理机器无关，比方 CPU 相干指标和机器核数有关系，FileSystem 相干指标和理论挂载的文件系统数量无关，而运行 pod 较多的机器，挂载的文件系统也会更多。在施压集群机器节点上，咱们将单个 node exporter 理论产出的工夫线数量管制在（680±5）之间，后续的测试估算中，咱们依照 680 per node exporter 的规范来估算。

agent 通过定义多个 static config 抓取同一个 node exporter，同时将 instance 字段  relabel 成 host-idx 的形式，模拟出多个数据源，并写入到 remote storage 中。config updater 组件定时更新 static config 按比率调整 relabel 字段，模拟出工夫线搅动场景。

如果将采集周期定义为 10 秒钟，target 数量为 100，那么每秒钟产生的采样点数量，约为(680 x 100) / 10 = 6800 个 / 秒；如果再将搅动率参数设置为每 10 分钟汰换 10%，那么原始工夫线数量为 100 x 680 = 68k，每小时新增的工夫线数量为 100×0.1x(60/10)x680 = 41k。

通过两个 query 组件咱们能够周期性的发动查问申请，其中 alert query 默认每次发动 33 个告警查问，持续时间根本都在 5 分钟以内；range query 默认每次发动 32 个 range 查问，时间跨度包含 1 小时、3 小时、6 小时、24 小时。

4. 测试工具应用

测试工具应用须要两个前提条件：1，所在机器能联通到 k8s 集群；2，机器上装置 helm。编辑 chart/values.yaml 文件，批改其中 remoteStorages 等配置；编辑 chart/files 中 alerts.yaml 和 range_query.yaml，作为带发动的告警查问和范畴查问；调整 Makefile 中的 namespace 等配置，应用 make install 装置部署，即可从数据源采集数据并写入到 remoteStorages 中，同时依照配置的频率发动查问。

同时在部署的 pod 上，默认减少了 Prometheus 采集的相干 annotation，如果集群中曾经装置了阿里云 Prometheus，会主动采集测试工具的相干指标数据，包含写入速率、写入采样点数量、查问速率、查问胜利数量、查问耗时等。

小型集群告警查问场景

集群预设：

• • 集群设置 100 个 target，约等于一个一般的小型 k8s 集群，每秒写入数据为 (100×680)/10 = 6.8k 个采样点，原始工夫线为 100×680 = 68k 条，每小时汰换 1% 的 target，即每小时新增 100x680x0.01=680 条工夫线，四舍五入约等于零。
  • 查问组件每 3 秒钟发动一批，共计 31 个告警查问，查问时间跨度 2～5 分钟不等。

环境部署：

• • 开源 Prometheus 部署在一套 4C32G 200G SSD 阿里云资源上。

开源 Prometheus 资源应用状况

• 内存应用（GB）

• CPU 使用率百分比

性能体现比照

• 查问 QPS（黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 查问耗时（黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 写入速率比照（KB/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

测试论断

在这种根底场景下，开源 Prometheus 在六小时的测试期间体现稳固，资源耗费较低，响应速度也能让人称心。

小型集群范畴查问场景

经验了第一场热身，单方体现半斤八两。于是咱们降级测试项目，减少范畴查问场景，尤其在 Prometheus+Grafana 中，大部分都是范畴查问。

集群预设：

• • 集群设置 100 个 target，抓取周期为 10s，每小时 1% 的汰换率。
  • 每五秒钟发动一批范畴查问，查问跨度对立为 3 小时，查问频率为每 5 秒发动一批，每批 50 条查问语句，超时工夫 30 秒钟。

环境部署：

• • 开源 Prometheus 部署在一套 4C32G 200G SSD 阿里云资源上。

开源 Prometheus 资源应用

• 内存应用（GB）

• CPU 使用率百分比

性能体现比照

• 查问 QPS（黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 查问耗时（P95，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线)

• 数据写入速率（KB/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

测试论断

相比上一轮，本轮测试数据采集量并没有变动，总数据量基本一致，开源 Prometheus 内存应用同样是持平状态。但咱们减少范畴查问后，CPU 使用量产生显著变动，长时间继续在 60% 水位，依照 node exporter 默认告警规定，节点 CPU 使用率瞬时值达到 80% 即可触发告警，开源 Prometheus 节点的 CPU 使用率已迫近须要关注水位。

在测试开始后约三个小时（0:30 – 3:30），开源 Prometheus 的 CPU 使用率即达到 60%，依据测试场景预设条件咱们能够计算出此时工夫线数量和收集的采样点数量。工夫线数量约为 100×680 + 3x100x680x0.01 = 70k，采样点数量(3×3600/10)x100x680=7kw，单个采样点长度约 256B，数据压缩率 8%，所以数据文件大小约为 7kwx256Bx0.08/1024/1024=1434M，这个数据量并不大，同时工夫线变动很少。

发动的范畴查问申请 QPS=10，个别关上一个 Grafana dashboard 时同时发动的查问都在 20~50 左右（不过因为浏览器的限度，这些查问并不是真正的同时发动），再思考到大盘的定时刷新性能和同时关上多个大盘的状况，这个 QPS 在日常应用中是能够比拟容易达到的，但仍然使开源 Prometheus 的 CPU 耗费飙升。

究其原因，咱们认为开源 Prometheus 存在两个问题，一是响应工夫较长的问题，因为开源 Prometheus 默认只反对 10 个查问并发，大概率会呈现申请期待状况，缩短的响应工夫（但也拉平了 CPU 压力)；另一个 CPU 使用率较高问题，咱们查看开源版本 Prometheus CPU 应用状况（如下图），大量 CPU 耗费在用户过程上，PromQL 查问中须要对采样点进行各种切分与计算，从而产生大量数值计算，的确很容易把 CPU 打高。同时，开源 Prometheus engine 是单线程解决数据，能够视为要将每个采样点“捋一遍”，这种串行化的解决形式，也是其响应工夫远逊于阿里云 Prometheus 服务的起因之一。

小型集群高搅动率场景

在前两轮测试中，咱们预设场景都是比拟现实的稳固集群，工夫线汰换率非常低。理论场景往往没有这么现实，往往因为各种起因产生大量工夫线，比方指标设计不合理、pod 频繁重启等。这一轮测试中，咱们预设场景就是一个十分不稳固的集群，target 频繁汰换，考验下开源 Prometheus 和阿里云 Prometheus 服务在这种场景下体现如何。

集群设置：

• • 模仿 100 个 node exporter 作为 target，仍然是一个小规模 k8s 集群的量级，每十秒钟抓取一次，即写入速率仍然为 6.8k/ 秒。原始工夫线数量 680×100 = 680k，搅动率设置为十分钟汰换 99%，即每十分钟会从新产生 680×100 = 68k 工夫线，每小时会新产生约 41 万工夫线。
  • 每 10 秒钟发动一批 range query，应用测试工具中默认的 32 条 range query，查问工夫范畴从 1h～24h 不等，查问超时工夫为 30 秒。

环境部署：

• • 开源 Prometheus 部署机器配置为 4C32G 200G SSD。

开源 Prometheus 资源应用状况

• 内存应用（GB)

• CPU 使用率百分比

性能体现比照

• 查问 QPS（黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 查问耗时（P95，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 数据写入速率（Byte/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

测试论断

搅动率较高时，开源 Prometheus 体现十分勉强，内存与 CPU 使用量出现线性上涨，在保持了八个多小时之后，机器无响应，直至被 OS kill 掉。

依据测试场景预设，咱们能够大抵计算下工夫线总量，其中初始工夫线数量 680×100 = 68000，每小时新增工夫线数量 680x100x6x8 = 326w，总量相加一共计 333w。也就是说一台 4C32G 机器，最多只能接受 333w 工夫线，理论利用中咱们必然须要保留余量，如果依照 50% 水位作为警戒线，约只能承当 333 万 x 50% = 165 万 工夫线。此外，思考到理论利用中，数据保留工夫少则半个月，多则半年一年，长时间数据存储也会带来额定内存压力，所以一旦总工夫线数量达到 100w 时，就该当提高警惕，小心应答了。

作为比照，在咱们截图的时刻，阿里云 Prometheus 服务曾经写入了 680×100 + 680x100x6x12 = 4964000 即约 500w 工夫线，写入和查问的体现仍然稳固。

中型集群高搅动率场景

经验过后面三轮比对，咱们对开源 Prometheus 的性能体现有了肯定理解：单纯写入性能较好，查问很吃 CPU，工夫线数量对性能影响很大，内存耗费会成倍回升，CPU 开销也会暴涨。

面对性能瓶颈，最间接最简略的想法就是垂直扩容，换句话就是通知老板加机器。加机器就能解决的问题都有一个隐含的前提条件：资源增长是线性的。如果资源是指数增长，那加机器就是一个无底洞：减少十倍的硬件投入，只能晋升一倍的性能，这种状况下还走垂直扩容的路子，只能是为硬件厂商打工。

在这一轮测试中，咱们晋升了开源 Prometheus 的硬件机器规格，应用一台 16C64G 200GSSD 的机器来应答高搅动率场景。

集群设置：

• • 模仿一个中型规模的 k8s 集群，500 个 target，每 10 秒钟抓取一轮，每十分钟汰换 99% 的 target，所以初始工夫线数量为 680×500 = 34w，每小时新增工夫线数量为 680x500x0.99×6 = 2019600 即每小时新增工夫线数量为 200w。
  • 查问申请方面，仍然应用工具集中默认的 32 条范畴查问，但发动查问的距离扩充为 30s，查问超时工夫仍然设置为 30s。

环境部署：

• • 开源 Prometheus 部署机器配置为 16C64G 200GSSD。

开源 Prometheus 资源应用

• 内存应用（GB)

• CPU 使用率百分比

性能体现比照

• 查问 QPS（黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 查问耗时（P95，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 数据写入速率（Byte/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

测试论断

开源 Prometheus 在保持四个小时后终于倒下，总计写入的工夫线约为 34w + 200w x 4 = 834w。咱们将硬件资源晋升了四倍，但理论承载的工夫线总数只晋升了 834w / 333w = 2.5 倍。显然，工夫线高基数，对 Prometheus 性能的影响是非线性的，即工夫线基数越高，单位资源能承载的均匀工夫线数量越少。越大规模集群，堆硬件越不划算。

仔细的 SRE 们察看到了另一个景象：相较于小型集群的高搅动率场景，这一轮的查问 QPS 降落到了 1/s，而 CPU 资源也没有像上次一样与内存简直同步耗尽，而是在达到了 40% 的时候，因为内存耗尽导致机器无响应，也凸显了 PromQL 查问对 CPU 的耗费严重性。

开源 Prometheus 倒下后，阿里云 Prometheus 服务并没有停步，最终在测试期间，曾经吞下了 34w + 200w x 12 = 1434w 条工夫线，依靠于云服务有限扩大的个性，对于用户来说，阿里云 Prometheus 服务的承载能力也能够认为是一个“无底洞”，借助各种弹性策略及发现读 / 写瓶颈时主动程度扩大等伎俩，保障服务质量。

大型集群高搅动率场景测试

从上一轮的测试中，咱们简直能确定基数较高时，开源 Prometheus 的资源耗费是指数级回升的，所以应用硬件配置更好的机器，承载能力不可能有成倍的晋升。咱们将在这一轮测试中尝试证实或证伪这个推论。在这一轮测试中，咱们根本沿用了上一轮设置。

集群设置：

• • target 总数涨到 2000 个。初始工夫线数量 680 x 2000 = 136w，每小时新增工夫线数量为 680 x2000 x0.99 x6 = 807w。其余配置放弃不变。

环境部署：

• • 开源 Prometheus 部署机器配置为 64C 256G。

开源 Prometheus 资源应用

• 内存应用（GB）

• CPU 使用率百分比

性能体现比照

• 查问 QPS（黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 查问耗时（P95，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

• 数据写入速率（Byte/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 Prometheus 服务数据曲线）

测试论断

本轮中开源 Prometheus 一共保持了约两小时四十分钟，写入工夫线总数为 136w + 800w x 2.67 = 2300w，比照上一轮，在硬件扩容四倍的状况下，理论撑持能力扩充了 2300w /834w = 2.75 倍。进一步印证了其性能耗费非线性增长的论断。

长周期查问场景测试

后面几轮的测试中，咱们着重比拟了高搅动率 / 工夫线爆炸场景下，开源 Prometheus 和阿里云 Prometheus 服务的性能体现，阿里云 Prometheus 服务对工夫线的承载能力远高于开源版本。在日常应用中，另一个常常遇到的，容易涉及 Prometheus 性能边界的场景就是长周期查问。较大的查问时间跨度，一方面须要加载更多的工夫线和采样点数据，另一方面计算量也会跟着翻倍，间接把 IO/ 内存 /CPU 三大项全都考验了一遍。

因为开源 Prometheus 不承受数据乱序写入，所以这一轮的测试中，咱们提前进行了一周工夫的数据筹备，咱们应用 ksm（kube state metrics）作为数据源，模仿了 120 个 ksm，因为测试集群规模较小，单个 ksm 裸露的工夫线数量约为 2500，所以总工夫线数量为 2500 120 = 30w。采集距离为 30s，所以每月产生的指标总量约为(30w/30) 60602430 = 260 亿，每周产生的指标总量约为(30w/30) 606024*7 = 60 亿。

测试集群持续沿用了之前的 64C 256G 高配机器。

五天数据查问

查问语句：sum(kube_pod_container_resource_requests_memory_bytes) by (node, namespace)

查问时间跨度：now – 5d  ~ now

查问 step：10m（页面默认）

查问耗时：2.71s（阿里云 Prometheus 服务）16.3s（开源 Prometheus）

查问语句：(sum(kube_pod_container_resource_requests{resource=~”cpu”})by (node) / sum(kube_node_status_allocatable{resource=~”cpu”})by (node) ) * 100 > 30

查问时间跨度：now -6d ~ now - 1d

查问 step：10m（页面默认）

查问耗时：3.59s（阿里云 Prometheus 服务）14.0s（开源 Prometheus）

七天跨度批量查问

更多的时候，咱们会是在 Grafana dashboard 上发动 Prometheus 查问，一个 dashboard 上会同时发动 20 到 30 个查问。多个查问同时解决时，开源 Prometheus 和阿里云 Prometheus 服务的体现又将如何呢？

咱们在 exporter 中同时发动 10 个查问（事实上因为 Chrome 浏览器并发连接数限度，实际上同时收回的申请数无奈达到 10 个），来模仿同时发动多个查问的场景。查问时间跨度设置为七天。查问语句如下：

count(kube_pod_container_info{}) by (namespace, node)
sum by (node, namespace) (kube_pod_container_resource_requests_memory_bytes)
sum by (node, namespace) (kube_pod_container_resource_requests_cpu_cores) 
sum by (namesapce) (rate(kube_pod_container_status_restarts_total{}[2m]))
sum(kube_pod_container_resource_requests{resource="cpu", unit="core"})by (node) / sum(kube_node_status_allocatable{resource="cpu", unit="core"})by (node)
sum(kube_pod_container_resource_limits{resource="memory", unit="byte"})by (node) / sum(kube_node_status_allocatable{resource="memory", unit="byte"})by (node)
sum by (node, namespace) (kube_pod_container_resource_limits_cpu_cores)
sum by (node, namespace) (kube_pod_container_resource_limits_memory_bytes)
sum(kube_pod_container_resource_limits{resource="cpu", unit="core"})by (node) / sum(kube_node_status_allocatable{resource="cpu", unit="core"})by (node)
sum(kube_pod_container_resource_limits{resource="memory", unit="byte"})by (node) / sum(kube_node_status_allocatable{resource="memory", unit="byte"})by (node)

阿里云 Prometheus 服务总体耗时在 13 秒左右，因为浏览器并发申请数的限度，查问申请不是同时收回的，每个申请的响应工夫在 5 到 6 秒左右。

开源 Prometheus 总体耗时在 53 秒左右，因为单个申请耗时更久，叠加并发申请数的限度，导致总体耗时大概是阿里云 Prometheus 服务的 4 倍左右，单个申请的耗时也都在 16 到 37s。

测试论断

在本轮测试中，自建 Prometheus 即便在资源充分的状况下，长跨度查问速度也远逊于阿里云  Prometheus 服务。这是因为阿里云 Prometheus 服务并不是简略的开源托管，咱们在查问方面做了十分多的技术优化，包含算子下推、降采样、函数计算优化等技术手段，综合晋升大查问 / 长时间跨度查问的性能体现。

实际上随着查问时间跨度的持续加长，阿里云 Prometheus 服务的查问性能劣势相较于开源 Prometheus 会更加显著。同时开源 Prometheus 默认反对的并发查问只有 20（并发查问 20，并发 remote read 10），而阿里云 Prometheus 服务依靠弱小的云化计算资源，并发查问能力轻松上千。对于 SRE 而言，从长周期数据中察看零碎异样变化规律十分重要，对于 IT 体系管理人员而言，从长周期数据中察看零碎的演进趋势也是必不可少的工作，在这种场景下，开源 Prometheus 并不是一个牢靠的搭档。

测试总结

通过了六轮不同角度不同强度的测试，咱们也能够失去一些初步的论断：

• 写入性能个别不会成为 Prometheus 的瓶颈。在大型集群高搅动率场景测试中，咱们的写入速率最高，每分钟写入采样点数达到了 816w（136wx60/10 = 816w），但无论是开源 Prometheus 还是阿里云 Prometheus 服务均能很好的承接这种量级的写入。这也合乎时序数据库写多读少的设计思路。
• 查问对 CPU 的耗费远多于写入。在小型集群范畴查问场景测试中体现最为显著，仅仅是查问测试期间几个小时的数据，就能轻易将 CPU 使用率拉升到 60% 的高位。因为 Prometheus 的所谓查问，并不是将数据从存储中读出来就完事，更多的是各种 PromQL 的解决，其中蕴含大量的数据切分、判断、计算，所以如果有大查问 / 简单查问 / 长周期查问 / 高工夫线基数查问时，很容易将 CPU 打满。
• 工夫线数量对 Prometheus 的内存耗费影响很大，且不是线性增长。
• • 在小型集群高搅动率场景、中型集群高搅动率场景、大型集群高搅动率场景下，面对工夫线爆炸的状况下，三个集群都没能保持太久就挂掉，挂掉的起因也都是内存耗尽导致 OOMKill。
  • 工夫线增多同样导致查问变慢，在三个场景的查问耗时 P95 中，随着工夫线的增多，阿里云 Prometheus 服务的查问响应工夫也会相应变长。因为在 promQL 逻辑中，尤其是很多函数计算逻辑中，每条工夫线是须要独自计算的，100w 工夫线就要计算 100w 轮，所以响应工夫天然也要变长。
  • 资源耗费的增长是非线性的。相比小型集群，中型集群的资源扩了四倍，理论承载的工夫线数量增长了 2.5 倍；相比中型集群，大型集群的资源也扩了四倍，理论承载的工夫线数量增长了 2.75 倍。即如果集群吐出的工夫线数量就是很多，加机器硬抗并不是一个理智的抉择。
  • 阿里云 Prometheus 服务针对高基数存储 / 查问做了不少无效的优化，所以在高基数的承载能力、高基数的查问响应上都能将开源 Prometheus 拉开肯定间隔。
• 长时间跨度查问除了要耗费大量 CPU 工夫，还因为要加载数天的数据，带来更多的 IO 耗费，两相叠加导致查问响应会比较慢。阿里云 Prometheus 服务在这方面做了很多技术优化，包含 TSDB 数据文件优化、文件加载优化、降采样、算子下推、函数计算优化等等，最终的查问效率较开源 Prometheus 高出数倍。

阿里云 Prometheus 服务 VS 开源

老本永远是企业用户说不腻的话题。IT 上云对于升高 / 拉平企业数字化老本的作用毋庸置疑，而具体到 Prometheus 组件上，云服务的老本体现，相比于自建模式会怎么呢，咱们在这里一起做一个简略的比拟。以下的自建成本计算中，咱们对立应用张家口 region 的 ECS 价格。

场景 1：小规模线上集群

线上这个词在 IT 语境中有着神奇的魔力，任何名词只有后面加上“生产 / 线上”的前缀，聊天室的氛围都会霎时庄重起来。不信你在公司群里，发一句“老板咱们线上环境挂了”试试 :)

线上环境里，可观测能力不再是可选项，而是必选项，平时要可用，预警问题要管用，排查问题时更得中用。这就对咱们的可观测工具提出了更高的要求，既要有优良的 SLA，又要好用易用，关键时刻能力成为排查问题的神兵利器，而不只是一个简略花哨的数据展板。

自建一个这样的 Prometheus 工具套件，与应用阿里云 Prometheus 服务的老本又能差多少呢？

假如咱们当初面对的，是一个小型线上集群，五台物理机上运行了 50 个业务 pod，各种依赖的基础设施如 DB，redis 等有 10 个 pod，另外还有 10 个 k8s 的根底组件  pod，共计 70 个 pod 的小集群。这样一个集群里，次要的指标起源有：

• node exporter，1200 series per exporter x 5 exporter = 6000 series
• kube state metrics，15000 series per exporter = 15000 series
• cadvisor，7000 series per exporter x 5 exporter = 35000 series
• infra pod，1500 series x 10 pod = 15000 series
• 其余 pod 指标（JVM 等）10000

依照 30 秒抓取一次，每月抓取 86400 次（2x60x24x30），根底指标（node exporter/kube state metrics/cadvisor）指标量约 48.4 亿，自定义指标（infra pod，其余 pod）指标量约 21.6 亿，日均自定义指标量 72M。咱们将采集到的数据通过 remote write 的形式再写一份到备节点，以保证数据的可用，数据保留时长设定为一个月。

自建的老本每一项都不高，零零碎碎加起来却比阿里云 Prometheus 服务高很多，大概这就是零售和批发的差距吧~ :)

在下面的老本比拟中，因为自建 Prometheus 的人力老本会绝对简单，所以咱们这里依照 8000 元 / 月的中高级运维工程师工资计算。实际上，搭建一套残缺的可观测零碎，人力的投入并不是敲几个命令即将 Prometheus 跑起来那么简略。

在实在的业务利用中，简直肯定会依赖到各种各样的基础设施，包含但不限于 DB、gateway、MQ、redis 等等，这些组件衰弱与否间接关系整个零碎的稳固运行。而对于 SRE 来说，就意味着必须要为这些组件配套 exporter、绘制大盘、配置告警等等，也意味着须要长期继续的优化大盘优化告警，这些细碎而必要的工作带来的额定人力扩散在每时每刻，咋一看不起眼，汇总起来却是不小的企业老本。对此，阿里云 Prometheus 服务提供了集成核心性能，其中集成了监控常见的基础设施组件的快捷入口，一键实现 exporter 部署装置、dashboard 绘制、告警规定配置的能力，让客户的精力从这些琐碎的事件中释放出来，聚焦于更有价值的局部。

同时，零碎出现异常时，也是可观测零碎大显神通的时候，如果咱们能有一个优良的  dashboard，将散落各处的观测数据归集到一起，对于问题解决会有事倍功半的成果。但这方面开源社区并没有太多可供借鉴的货色，开源社区中更多关注大盘的通用性而非易用性。

针对 SRE 的事实需要，阿里云 Prometheus 服务依赖本身在可观测畛域的多年积淀，以及对咱们用户应用场景的总结提炼，针对 POD/NODE/K8s/ingress/Deployment 等场景，在包年包月版本中，特地提供了 Pro 版本大盘，将罕用的指标监控和日志、过程、网络、事件、利用性能等分项监控融为一炉，一张大盘通观全局，让角落里的异样也无处遁形。以 Pod Pro 大盘为例，在一张盘中整合了日志、事件、网络、利用性能等多个维度的数据，SRE 们无需慌手慌脚的在各种零碎 / 工具 / 大盘中切换奔走，便捷高效的定位异样，尽早扼杀问题苗头。更多其余的 Pro 版本大盘，也都在 这里 列出 [ 7]，供大家参考。

场景 2：随着业务发展壮大

随着业务发展壮大，集群规模也更大了，SRE 肩上的担子有重了许多，咱们须要更多资源来应答挑战。

咱们预设这是一个中等规格的容器集群，有十台物理机，其中运行了 200 个业务 pod，配套的各种 infrastructure 如 MySQL、redis、MQ、gateway、注册核心、配置核心等共计 50 个 Pod，另外有 k8s 自带的各种 Pod 如网络插件，存储插件等约 30 个。持续沿用主从模式保障可用性。同时咱们将数据存储时长缩短到六个月，以便长期趋势察看和异样追溯。

集群的工夫线数量预估如下：

• node exporter，1500 series per exporter x 10 = 15000 series
• cadvisor，10000 series per node x 10 = 100000 series
• ksm，20000 series = 20000 series
• infra pod，1500 series * 50 = 75000 series
• 其余自定义指标（如 JVM）20000 series

一个月约产生根底指标 116 亿，自定义指标（infrastructure 产生的指标）82 亿。

共计约 200 亿采样点，单个采样点体积均匀约 256B，压缩率 8%，数据文件体积 200 亿 x 256B x 8%，即约 410G。六个月数据的总体积约 410G x 6 = 2460G。

以后集群的初始的工夫线数量曾经达到了 20w+，即便只思考失常业务更新带来的 pod 启停（pod 启停会带来大量新的工夫线，pod 频繁重启则肯定会带来工夫线爆炸），六个月工夫内累计的工夫线也能轻松冲破 100w，所以咱们选用了 ecs.g6e.4xlarge 规格的机器来保证系统裕度。

要保护这样的一套 Prometheus 环境，加上各种周边设施（exporter，Grafana，alert 等），至多须要投入 0.2 个人力，也就意味着每月数千元的人力老本投入。

场景 3：多集群对立监控

对于规模较大的企业，生产集群往往会有多个，一来更加凑近客户，提供更快的响应速度，二来也能够提供一些容灾能力，防止整个线上环境被一锅端。但对于 SRE 而言，这样的架构形式就须要将数据做汇总，开源 Prometheus 提供了联邦集群的形式，阿里云 Prometheus 服务提供了 GlobalView 性能，都能够做到一次查多个集群，针对这两种形式，咱们再次来估算下监控老本。

假如咱们的利用部署在三个不同 region，集群规模参考上场景 2 中的集群。咱们有三种部署计划：

• 分层联邦模式，三个开源 Prometheus 集群散布在三个不同 region（worker）+ 一个高级别的 federate 集群（master），其中 master 集群配置和 worker 保持一致，但不应用备节点。
• remote write 模式，将三个 region 的数据 remote write 到一个核心节点，所以核心节点的资源需要也会更高。
• 应用 ARMS Prometheus 的 GlobalView，三个 ARMS Prometheus 集群散布在三个不同 region（worker）+ 一个 GlobalView 集群（master）
• remote write 模式，将是哪个 region 的数据 remote write 到同一个 ARMS Prometheus 实例中，应用大规格 Prometheus 实例（250 亿采样点 / 月）。

随着数据采集规模的扩充，阿里云 Prometheus 服务的老本劣势更加显著，而且免运维的个性更加开释了 SRE 的人力投入。同时配合阿里云云原生可观测家族的其余组件，可能残缺的笼罩各种可观测场景（log/trace/metrics），聚力协同，为企业零碎的稳固运行保驾护航。

总结

总的来看，开源 Prometheus 在逆风局体现还是不错的，低负载时响应和资源应用都可圈可点。但事实很残暴，现实的场景并不多见，总是会有各种层出不穷的意外挑战 SRE 们紧绷的神经（题外话：解决和预防各种意外，不就是 SRE 的指标么？），对于无论是事先预防，事中告警，预先复盘，一套牢靠的可观测体系都能让你事倍功半，用详实精确的数据撑持你的口头。

事实上阿里云 Prometheus 服务工具箱里，不止有性能强悍的存储能力，还有很多其余的神兵利器，比方化繁为简的预聚合，比方高性能且主动扩大的采集 agent，比方  xxx，后续咱们会继续为大家介绍。用咱们的产品和服务，帮忙 SRE 们更加 Reliable！

相干链接

按量付费成本计算请参考

https://help.aliyun.com/docum…

[1]《2023 年十大策略技术趋势》

https://www.gartner.com/cn/newsroom/press-releases/2023-top-10-strategic-tech-trends

[2] 兼容性测试工具

https://github.com/prometheus…

[3] 兼容性为 97.06%

https://help.aliyun.com/document_detail/408652.html

[4] 优于 AWS 和 GCP

https://promlabs.com/promql-c…

[5] prometheus-benchmark

https://github.com/VictoriaMetrics/prometheus-benchmark

[6] 我的项目寄存在 GitHub 上

https://github.com/liushv0/prometheus-benchmark

[7] 这里列出

https://help.aliyun.com/docum…