作者： 智真

在 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 服务多场景存储压测全解析

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] **。测验东西的全体架构如下图：

对比开源丨Prometheus 服务多场景存储压测全解析

3.测验条件设置

默许运用 node exporter 作为目标数据源，node exporter 发生的时刻线数量和物理机器有关，比方 CPU 相关目标和机器核数有联系，FileSystem 相关目标和实践挂载的文件系统数量有关，而运转 pod 较多的机器，挂载的文件系统也会更多。在施压集群机器节点上，咱们将单个 node exporter 实践产出的时刻线数量控制在（6805）之间，后续的测验预算中，咱们依照 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）

对比开源丨Prometheus 服务多场景存储压测全解析

  • CPU运用率百分比

对比开源丨Prometheus 服务多场景存储压测全解析

功用体现比照

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

对比开源丨Prometheus 服务多场景存储压测全解析

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

对比开源丨Prometheus 服务多场景存储压测全解析

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

对比开源丨Prometheus 服务多场景存储压测全解析

测验定论

在这种根底场景下，开源 Prometheus 在六小时的测验期间体现安稳，资源耗费较低，呼应速度也能让人满意。

小型集群规划查询场景

经历了第一场热身，双方体现势均力敌。所以咱们晋级测验项目，增加规划查询场景，尤其在 Prometheus+Grafana 中，大部分都是规划查询。

集群预设：

    • 集群设置 100 个 target，抓取周期为 10s，每小时 1% 的汰换率。
    • 每五秒钟建议一批规划查询，查询跨度共同为 3 小时，查询频率为每5秒建议一批，每批 50 条查询句子，超时时刻 30 秒钟。

环境布置：

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

开源 Prometheus 资源运用

  • 内存运用（GB）

对比开源丨Prometheus 服务多场景存储压测全解析

  • CPU 运用率百分比

对比开源丨Prometheus 服务多场景存储压测全解析

功用体现比照

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

对比开源丨Prometheus 服务多场景存储压测全解析

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

对比开源丨Prometheus 服务多场景存储压测全解析

  • 数据写入速率（KB/s，黄色为开源Prometheus数据曲线，绿色为阿里云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 服务的原因之一。

对比开源丨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)

对比开源丨Prometheus 服务多场景存储压测全解析

  • CPU运用率百分比

对比开源丨Prometheus 服务多场景存储压测全解析

功用体现比照

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

对比开源丨Prometheus 服务多场景存储压测全解析

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

对比开源丨Prometheus 服务多场景存储压测全解析

  • 数据写入速率（Byte/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 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)

对比开源丨Prometheus 服务多场景存储压测全解析

  • CPU 运用率百分比

对比开源丨Prometheus 服务多场景存储压测全解析

功用体现比照

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

对比开源丨Prometheus 服务多场景存储压测全解析

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

对比开源丨Prometheus 服务多场景存储压测全解析

  • 数据写入速率（Byte/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 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）

对比开源丨Prometheus 服务多场景存储压测全解析

  • CPU 运用率百分比

对比开源丨Prometheus 服务多场景存储压测全解析

功用体现比照

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

对比开源丨Prometheus 服务多场景存储压测全解析

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

对比开源丨Prometheus 服务多场景存储压测全解析

  • 数据写入速率（Byte/s，黄色为开源 Prometheus 数据曲线，绿色为阿里云 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) 6060247 = 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）

对比开源丨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）

对比开源丨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 服务多场景存储压测全解析

开源 Prometheus 整体耗时在 53 秒左右，由于单个恳求耗时更久，叠加并发恳求数的约束，导致整体耗时大约是阿里云 Prometheus 服务的 4 倍左右，单个恳求的耗时也都在 16 到 37s。

对比开源丨Prometheus 服务多场景存储压测全解析

测验定论

在本轮测验中，自建 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 服务高许多，大约这便是批发和零售的差距吧~ :)

在上面的本钱比较中，由于自建 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]，供咱们参阅。

对比开源丨Prometheus 服务多场景存储压测全解析

场景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。

对比开源丨Prometheus 服务多场景存储压测全解析

当时集群的初始的时刻线数量现已到达了 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 服务多场景存储压测全解析

跟着数据搜集规划的扩展，阿里云 Prometheus 服务的本钱优势愈加显着，并且免运维的特性愈加释放了 SRE 的人力投入。一同配合阿里云云原生可观测家族的其他组件，能够完好的掩盖各种可观测场景（log/trace/metrics），聚力协同，为企业系统的安稳运转保驾护航。

总结

总的来看，开源 Prometheus 在顺风局体现还是不错的，低负载时呼应和资源运用都可圈可点。但现实很严酷，理想的场景并不多见，总是会有各种层出不穷的意外应战 SRE 们紧绷的神经（题外话：处理和预防各种意外，不便是 SRE 的目标么？），关于无论是事前预防，事中告警，事后复盘，一套牢靠的可观测系统都能让你事半功倍，用详实准确的数据支撑你的行动。

事实上阿里云 Prometheus 服务东西箱里，不止有功用强悍的存储才能，还有许多其他的神兵利器，比方化繁为简的预聚合，比方高功用且主动扩展的搜集 agent，比方 xxx，后续咱们会继续为咱们介绍。用咱们的产品和服务，帮助 SRE 们愈加 Reliable！

相关链接

按量付费本钱核算请参阅

help.aliyun.com/document_de…

[1] 《2023 年十大战略技能趋势》

www.gartner.com/cn/newsroom…

[2] 兼容性测验东西

github.com/prometheus/…

[3] 兼容性为 97.06%

help.aliyun.com/document_de…

[4] 优于 AWS 和 GCP

promlabs.com/promql-comp…

[5] prometheus-benchmark

github.com/VictoriaMet…

[6] 项目存放在 GitHub 上

github.com/liushv0/pro…

[7]这儿列出

help.aliyun.com/document_de…