共计 6037 个字符，预计需要花费 16 分钟才能阅读完成。
简介：基于 Prometheus 的监控实际中，尤其是在规模较大时，时序数据的存储与查问是其中十分要害，而且问题点较多的一环。如何应答大数据量下的长周期查问，原生的 Prometheus 体系并未能给出一个令人满意的答案。对此，ARMS Prometheus 近期上线了降采样性能，为解决这个问题做出了新的尝试。
作者：智真
基于 Prometheus 的监控实际中，尤其是在规模较大时，时序数据的存储与查问是其中十分要害，而且问题点较多的一环。如何应答大数据量下的长周期查问，原生的 Prometheus 体系并未能给出一个令人满意的答案。对此，ARMS Prometheus 近期上线了降采样性能，为解决这个问题做出了新的尝试。
前言
问题背景
Prometheus 与 K8s 作为云原生时代的一对黄金搭档，是目前许多企业运行环境的标准配置。然而，为了适应业务规模和微服务的倒退演进，被监控对象的数量会一路增长；为了更残缺的体现零碎或利用的状态细节，指标粒度划分越来越粗疏，指标数量越来越多；为了发现更长周期的趋势变动，指标数据的保留周期势必也要更长。所有这些变动最终都会导致监控数据量的爆炸性增长，给观测产品的存储、查问、计算带来十分大的压力。
咱们能够通过一个简略的场景，来更直观的感触下这种数据爆炸的结果。如果咱们须要查问近一个月中我的集群各个节点上 CPU 用量的变动状况，而我的集群是一个 30 个物理节点的小规模集群，每个节点上均匀运行了 50 个须要采集指标的 POD，依照默认的 30 秒采集距离，咱们须要解决的采集 target 共有 3050 = 1500 个，而每个采样点每天会被抓取 606024/30 = 2880 次，在一个月的周期里，共有 1500 2880 30 = 1.3 亿次指标抓取，以 Node exporter 为例，一台裸机一次抓取吐出的 sample 数量约为 500，那么一个月内这个集群产生的采样点约有 1.3 亿 500 = 650 亿个！而在事实的业务零碎中，状况往往不会这么现实，理论的采样点数量往往会超过千亿。
面对这种状况，咱们必须要有一些技术手段，在尽可能保证数据准确性的前提下，对存储 / 查问 / 计算的老本和效率做优化晋升。降采样（DownSampling）就是其中一种代表性的思路。
什么是降采样
降采样基于这样一个前提：数据的解决合乎结合律，多个采样点的值的合并，并不会影响最终计算结果，刚巧 Prometheus 的时序数据就合乎这样的特点。降采样换句话说就是升高数据的分辨率，其思路十分间接，如果将肯定工夫距离内的数据点，基于肯定规定，聚合为一个或一组值，从而达到升高采样点数，缩小数据量，加重存储查问计算的压力。所以咱们须要两个输出项：工夫距离，聚合规定。
对于降采样的工夫距离，基于教训剖析，咱们划定了两种不同的降采样工夫距离：五分钟和一小时，再加上原始数据，会失去三种不同 resolution 的数据，依据查问条件主动将查问申请路由到不同 resolution 的数据。随着后续 ARMS Prometheus 提供更长的存储时长抉择，咱们可能还会减少新的工夫距离选项。
对于聚合规定，通过对 Prometheus 的算子函数的剖析，各种算子函数最终都能够归纳到六种类型的数值计算上：
max，用于计算 vector 内最大值，典型算子如 max_over_time；
min，用于计算 vector 内的最小值，典型算子如 min_over_time；
sum，用于计算 vector 内的和值，典型算子如 sum_over_time；
count，用于统计 ventor 内的点数，典型算子如 count_over_time；
counter，用于计算变化率，典型算子如 rate，increase 等；
avg，取工夫距离内的各个点的平均值；
由此可见，对于工夫区间内的一系列采样点，咱们只须要计算出如上六种类型的聚合特征值，在查问时返回相应工夫区间聚合值即可。如果默认的 scrape interval 为 30 秒，五分钟的降采样会将十个点聚合成一个点；一小时的降采样，会将 120 个点聚合成一个点，同样查问波及到的采样点数，会有数量级的降落，如果 scrape interval 更小，那么采样点缩减的成果会更显著。采样点数的缩减一方面加重了 TSDB 读取压力，另一方面查问引擎的计算压力也将同步减小，进而无效缩小查问耗时。
如何实现降采样
他山之石
其余开源 / 商业的时序数据存储实现上，有一些也通过降采样性能，对长时间跨度查问做了优化晋升，咱们也一起理解一下。
Prometheus
开源 Prometheus 的存储能力，始终是比拟让人诟病的一点，开源的 Prometheus 自身并未间接提供降采样的能力，但提供了 Recording Rule 能力，用户能够应用 Recording Rule 来自行实现 DownSampling，但这样会产生新的工夫线，在高基数场景下，反而进一步加剧了存储压力。
Thanos
作为出名的 Prometheus 高可用存储计划，Thanos 提供了较为欠缺的降采样计划。Thanos 中执行 downsmpling 性能的组件是 compactor，他会：
定期从 ojbect storage 中拉取 block（原始的 Prometheus Block，2 小时时间跨度），进行 compaction 和 downsampling，downsampling 的状态会记录到 block metadata。
压缩和降采样的后果，生成新的 block，写入到 object storage。
1.png
Downsampling 之后的特征值包含 sum/count/max/min/counter，写到非凡的 aggrChunks 数据块里。在做查问时：
原始的聚合算子和函数会转换成非凡的 AggrFunc，对应用于读取 aggrChunks 数据块数据
读取的 block 依照工夫排序，优先读取最大 Resolution 的 block
M3
2.png
M3 Aggregator 负责在指标存储到 M3DB 前，流式聚合指标，并且依据 storagePolicy 指定指标存储时长和计算窗口的采样距离。
M3 反对的数据距离更加灵便，特征值更多，包含 histogram quantile 函数。
InfluxDB/Victoria Metric/Context
Victoria Metrics 目前只在商业版本上线了降采样性能，开源版本并未透出。InfluxDB 的开源版本（v2.0 之前）通过相似 Recording Rule 的形式，对曾经落盘了的原始数据在存储介质外执行 continuous query 来实现降采样。Context 目前尚不反对降采样。
咱们怎么做
市面上的降采样计划各有千秋，咱们简略总结了他们的应用老本等用户比拟关注的点，比对如下：
3.jpeg
ARMS Prometheus 采纳了解决 TSDB 存储块的形式，由后盾主动将原始数据块解决为降采样数据块，一方面能获得一个较好的解决性能，另一方面对于终端用户来说，不须要关怀参数配置规定保护等等，尽可能的加重用户运维累赘。
此性能曾经在阿里云局部 region 上线，并开始定向邀请体验。在行将推出的 ARMS Prometheus 高级版中，将默认集成并提供此性能。
降采样对查问的影响
在咱们实现了采样点层面的降采样之后，长时间跨度的查问问题就迎刃而解了么？显然不是的，TSDB 中保留的只是最原始的物料，而用户看到的曲线，还须要通过查问引擎的计算解决，而在计算解决的过程中，咱们至多面临这么两个问题：
Q1：什么状况下读取降采样数据？是不是降采样后就无奈应用原始数据了？
Q2：降采样后数据点密度更小，数据更“稠密”，其查问体现会和原始数据统一么？须要用户调整 PromQL 么？
对于第一个问题，ARMS Prometheus 会依据用户的查问语句及过滤条件，智能抉择适宜的工夫颗粒度，在数据细节和查问性能之间做出失当的平衡。
对于第二个问题，首先能够说论断：采集点的密度对后果计算有很大影响，但 ARMS Prometheus 在查问引擎层面屏蔽了差别，用户无需调整 PromQL。这个影响次要体现在三个方面：与查问语句 duration 间的影响，与查问申请的 step 间的影响，以及对算子自身的影响，上面咱们将具体阐明这三方面的影响，以及 ARMS Prometheus 在这三方面做的工作。
duration 与降采样计算结果
咱们晓得，PromQL 中区间向量（Range Vector）查问时，都会带上一个工夫区间参数（time duration），用于框定一个工夫范畴，用于计算结果。比方查问语句 http_requests_total{job=”prometheus”}[2m]中，指定的 duration 即为两分钟，计算结果时，会将查问到的 time series 以两分钟为单位，宰割成若干个 vector，传递给 function 做计算，并别离返回后果。duration 间接决定了 function 计算时能拿到的入参长度，对后果的影响不言而喻。
个别状况下，采集点的距离是 30s 或者更短，只有 time duration 大于这个值，咱们就能够确定每个宰割进去的 vector 中，都会有若干 samples，用于计算结果。当降采样解决之后，数据点距离会变大（五分钟甚至一小时），这时候可能就会呈现 vector 中没有值的情景，这就导致 function 计算结果呈现断断续续的状况。对于这种状况 ARMS Prometheus 会主动调整算子的 time duration 参数来应答，保障 duration 不小于降采样的 resolution，即保障每个 ventor 中都会有采样点，保障计算结果的准确性。
step 与降采样计算结果
duration 参数决定了 PromQL 计算时的 vector 的”长度“，而 step 参数决定了 vector 的”步进“。如果用户是在 grafana 上查问，step 参数实际上是由 grafana 依据页面宽度和查问时间跨度来计算的，以我个人电脑为例，时间跨度 15 地利默认的 step 是 10 分钟。对于某些算子，因为采样点密度降落，step 也可能引起计算结果的跳变，上面以 increase 为例简略剖析一下。
失常状况下（采样点平均，无 counter 重置），increase 的计算公式能够简化为（尾值 – 首值）x duration /（尾工夫戳 – 首工夫戳），对于个别的场景来说，首 / 尾点与起 / 止工夫的距离，不会超过 scrape interval，如果 duration 比 scrape interval 大很多，后果约等于（尾值 – 首值）。假如有一组降采样后的 counter 数据点，如下：
sample1: t = 00:00:01 v=1
sample2: t = 00:59:31 v=1
sample3: t = 01:00:01 v=30
sample4: t = 01:59:31 v=31
sample5: t = 02:00:01 v=31
sample6: t = 02:59:31 v=32
…
假如查问 duration 为两小时，step 为 10 分钟，那么咱们将会失去宰割后的 vector，如下：
slice 1: 起止工夫 00:00:00 / 02:00:00 [sample1 … sample4]
slice 2: 起止工夫 00:10:00 / 02:10:00 [sample2 … sample5]
slice 3: 起止工夫 00:20:00 / 02:20:00 [sample2 … sample5]
…
原始数据中，首尾点与起止工夫的距离，不会超过 scrape interval，而降采样之后的数据，首尾点与起止工夫的距离最大能够达到（duration – step）。如果采样点值变动比拟平缓，那么降采样后的计算结果与原始数据计算结果不会有较大差异，然而如果某个 slice 区间中值的变动比拟激烈，那么依照上述计算公式（尾值 – 首值）x duration /（尾工夫戳 – 首工夫戳），会将这种变动等比放大，让最终展现的曲线起伏更激烈。这种后果咱们认为是失常状况，同时在指标变动激烈（fast-moving counter）的场景下，irate 会更实用一些，这也和官网文档的倡议是统一的。
算子与降采样计算结果
有些算子的计算结果与 samples 数量间接相干，最典型的是 count_over_time，统计工夫区间内 samples 数量，而降采样自身就是要缩减工夫区间内的点数，所以这种状况须要在 Prometheus engine 中做非凡解决，当发现取用的是降采样数据时，走新的计算逻辑来保障后果的正确。
降采样成果比照
对于用户来说，最终感触到的就是查问速度的晋升，但这个晋升幅度有多大，咱们也通过两个查问实地验证比照下。
测试集群有 55 个 node，共有 pod 6000+，每天上报采样点总数约 100 亿，数据存储周期 15 天。
第一轮比对：查问效率
查问语句：
sum(irate(node_network_receive_bytes_total{}[5m])*8) by (instance)
即查问集群内各个 node 接管到的网络流量状况，查问周期为 15 天。
4.png
图 1：降采样数据查问，时间跨度十五天，查问耗时 3.12 秒
5.png
图 2：原始数据查问，时间跨度十五天，查问超时（超时工夫 30 秒）
原始数据因为数据量过大计算超时，未能返回。降采样查问在效率上至多是原始查问的十倍以上。
第二轮比对：后果准确性
查问语句：
max(irate(node_network_receive_bytes_total{}[5m])*8) by (instance)
即查问各 node 上，接收数据量最大的网卡的流量数据。
6.png
图 3：降采样查问，时间跨度两天
7.png
图 4：原始数据查问，时间跨度两天
最终咱们将查问时间跨度缩短到两天，原始数据查问也能较快的返回。对比降采样查问后果（上图）和原始数据查问后果（下图）可见，二者工夫线数量和总体趋势完全一致，数据变动比拟激烈的点也能很好的符合上，齐全可能满足长时间周期查问的需要。
结语
阿里云于 6 月 22 日正式公布阿里云可观测套件（Alibaba Cloud Observability Suite，ACOS）。阿里云可观测套件围绕 Prometheus 服务、Grafana 服务和链路追踪服务，造成指标存储剖析、链路存储剖析、异构构数据源集成的可观测数据层，同时通过规范的 PromQL 和 SQL，提供数据大盘展现，告警和数据摸索能力。为 IT 老本治理、企业危险治理、智能运维、业务连续性保障等不同场景赋予数据价值，让可观测数据真正做到不止于观测。
其中，阿里云 Prometheus 监控针对多实例、大数据量、高工夫线基数、长时间跨度、简单查问等极其场景，逐渐推出了全局聚合查问，流式查问，降采样，预聚合等多种针对性措施。
目前提供 15 天收费试用、Prometheus 监控容器集群根底指标费用减免等促销流动！
点击此处，开明服务~
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。
