作者:智真

依据 Prometheus 的监控实践中,尤其是在规划较大时,时序数据的存储与查询是其间十分要害,而且问题点较多的一环。怎么应对大数据量下的长周期查询,原生的 Prometheus 体系并未能给出一个令人满意的答案。对此,ARMS Prometheus 近期上线了降采样功用,为处理这个问题做出了新的尝试。

前言

问题背景

Prometheus 与 K8s 作为云原生时代的一对黄金搭档,是现在许多企业运行环境的标准装备。然而,为了习惯事务规划和微服务的发展演进,被监控对象的数量会一路增长;为了更完整的表现系统或运用的状况细节,目标粒度区分越来越细致,目标数量越来越多;为了发现更长周期的趋势改变,目标数据的保存周期势必也要更长。所有这些改变终究都会导致监控数据量的爆破性增长,给观测产品的存储、查询、核算带来十分大的压力。

咱们能够经过一个简略的场景,来更直观的感受下这种数据爆破的成果。假设咱们需求查询近一个月中我的集群各个节点上 CPU 用量的改变状况,而我的集群是一个 30 个物理节点的小规划集群,每个节点上平均运行了 50 个需求收集目标的 POD,依照默许的 30 秒收集距离,咱们需求处理的收集 target 共有 3050 = 1500 个,而每个采样点每天会被抓取 6060*24/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。

可观测|时序数据降采样在Prometheus实践复盘

Downsampling 之后的特征值包括 sum/count/max/min/counter,写到特别的 aggrChunks 数据块里。在做查询时:

  • 原始的聚合算子和函数会转换成特别的 AggrFunc,对运用于读取 aggrChunks 数据块数据

  • 读取的 block 依照时刻排序,优先读取最大 Resolution 的 block

  • M3

可观测|时序数据降采样在Prometheus实践复盘

M3 Aggregator 担任在目标存储到 M3DB 前,流式聚合目标,而且依据 storagePolicy 指定目标存储时长和核算窗口的采样距离。

M3 支撑的数据距离更加灵敏,特征值更多,包括 histogram quantile 函数。

  • InfluxDB/Victoria Metric/Context

Victoria Metrics 现在只在商业版别上线了降采样功用,开源版别并未透出。InfluxDB 的开源版别(v2.0 之前)经过类似 Recording Rule 的方法,对现已落盘了的原始数据在存储介质外执行 continuous query 来完成降采样。Context 现在尚不支撑降采样。

咱们怎么做

市面上的降采样计划各有千秋,咱们简略总结了他们的运用本钱等用户比较重视的点,比对如下:

可观测|时序数据降采样在Prometheus实践复盘

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 天。

可观测|时序数据降采样在Prometheus实践复盘

图 1:降采样数据查询,时刻跨度十五天,查询耗时 3.12 秒

可观测|时序数据降采样在Prometheus实践复盘

图 2:原始数据查询,时刻跨度十五天,查询超时(超时时刻 30 秒)

原始数据由于数据量过大核算超时,未能回来。降采样查询在功率上至少是原始查询的十倍以上。

第二轮比对:成果准确性

查询句子:

max(irate(node_network_receive_bytes_total{}[5m])*8) by (instance)

即查询各 node 上,接纳数据量最大的网卡的流量数据。

可观测|时序数据降采样在Prometheus实践复盘

图 3:降采样查询,时刻跨度两天

可观测|时序数据降采样在Prometheus实践复盘

图 4:原始数据查询,时刻跨度两天

终究咱们将查询时刻跨度缩短到两天,原始数据查询也能较快的回来。比照降采样查询成果(上图)和原始数据查询成果(下图)可见,二者时刻线数量和整体趋势彻底一致,数据变化比较剧烈的点也能很好的契合上,彻底能够满意长时刻周期查询的需求。

结语

阿里云于 6 月 22 日正式发布阿里云可观测套件(Alibaba Cloud Observability Suite,ACOS)。阿里云可观测套件围绕 Prometheus 服务、Grafana 服务和链路追踪服务, 构成目标存储剖析、链路存储剖析、异构构数据源集成的可观测数据层,一起经过标准的 PromQL 和 SQL,供给数据大盘展现,告警和数据探索才能。为IT本钱管理、企业危险管理、智能运维、事务连续性保障等不同场景赋予数据价值,让可观测数据真实做到不止于观测。

其间,**阿里云 Prometheus 监控针对多实例、大数据量、高时刻线基数、长时刻跨度、复杂查询等极端场景,逐渐推出了全局聚合查询,流式查询,降采样,预聚合等多种针对性办法。

现在供给 15 天免费试用、Prometheus 监控容器集群基础目标费用减免等促销活动!

点击此处,注册服务~