监控系统的后端每天都在产生海量时序数据，从主机CPU到业务接口耗时，每个指标通常以数秒一次的频率上报。当集群规模扩大，原始数据如果不加处理，存储成本会迅速失控，查询延迟也会高到无法接受。监控数据降采样就是一种主动性的数据压缩手段，它按照预设的时间粒度对原始数据点进行聚合计算，用更少的数据行表达同一时间段内的整体状态。降采样并不是简单地删除数据，而是用统计特征替代个体样本，从而在可控精度损失下显著降低系统负担。
降采样的核心原理与常见聚合函数
降采样的底层逻辑是时间分桶，也就是把连续的时间轴切分成固定长度的区间，例如一分钟或五分钟为一个桶。每个桶内的多个原始样本会通过聚合函数计算出一个或几个代表值。最常用的聚合函数包括平均值、最大值、最小值、求和值以及分位数。平均值适合观察整体水位，最大值能保留区间内可能出现的峰值，对于告警来说尤为重要，因为很多故障表现为短时冲高。最小值则常用于观察低谷资源占用。
在实现层面，降采样可以分为预聚合和查询时聚合两类。预聚合是在数据写入存储后就由后台任务生成低精度表，查询直接读低精度表，性能最好。查询时聚合则不落盘，每次查询由引擎动态计算，灵活但消耗算力。对于监控场景，通常推荐预聚合配合多级保留策略。比如原始数据保留三天，一分钟粒度保留三十天，一小时粒度保留一年，这样既能排查近期问题，也能看长期容量趋势。
需要注意，聚合函数的选择直接影响降采样后数据的语义。如果只用平均值做降采样，那么秒级发生的瞬时超时可能会被平均掉，造成告警遗漏。因此在关键延迟指标上，建议同时保留最大值和分位数，或者使用水位线降采样，即记录桶内超过阈值的样本数。下面是一段用Python模拟降采样聚合的示例代码，展示如何对一个窗口内的数据点取最大值和平均值：
# 模拟原始监控点，每10秒一个，窗口为1分钟
raw_points = [0.2, 0.3, 0.9, 0.4, 0.5, 0.8]
window_size = 60
def down_sample(points):
avg_val = sum(points) / len(points)
max_val = max(points)
return avg_val, max_val
avg, mx = down_sample(raw_points)
print("平均值:", avg, "最大值:", mx)
滚动窗口与滑动窗口的方案对比
在落地降采样时，工程师常面临滚动窗口和滑动窗口的取舍。滚动窗口指相邻桶之间不重叠，例如零点到一分、一分到两分，这种方案计算简单，存储规整， most时序数据库原生支持。它的缺点是边界处可能割裂突发曲线，比如一个持续四十秒的抖动被切在两个滚动窗口中间，各自的最大值都看起来正常。
滑动窗口则是以步长小于窗口宽度的形式移动，例如窗口五分钟、步长一分钟，这样相邻结果有重叠，能更平滑地反映变化，但计算和存储成本更高，因为同一原始点会参与多次聚合。在监控降采样中，滚动窗口已经能满足绝大多数趋势分析，只有在做细粒度异常检测时才考虑滑动窗口。可以通过下表快速判断选用哪种方式：
| 维度 | 滚动窗口 | 滑动窗口 |
|---|---|---|
| 计算开销 | 低 | 高 |
| 边界割裂风险 | 有 | 无 |
| 适用场景 | 长期趋势、成本敏感 | 短时异常、精度敏感 |
实际部署中也可以组合使用，用滚动窗口做天级存储，用滑动窗口在近期数据上做实时检测。下面的配置片段展示如何在InfluxDB中通过连续查询实现滚动降采样，将十秒精度数据聚合成一分钟精度：
CREATE CONTINUOUS QUERY "cq_1m" ON "metrics"
BEGIN
SELECT MEAN("value") AS "mean_value", MAX("value") AS "max_value"
INTO "metrics"."autogen"."cpu_1m"
FROM "metrics"."autogen"."cpu_raw"
GROUP BY time(1m), *
END
基于Prometheus的降采样与保留实战
Prometheus本身不提供自动降采样，但它通过本地TSDB的压缩和chunk机制减少存储放大，同时配合远程存储或Recording Rules实现降采样。Recording Rules是最常用的手段，它定时执行查询并将结果写回新的时间序列，相当于用户态预聚合。比如我们可以定义规则，把每秒采集的node_cpu_seconds_total计算成一分钟平均使用率，从而让面板查询更快。
在配置Recording Rules时，要关注评估间隔与降采样粒度的匹配。如果原始抓取间隔是十五秒，规则评估设为一分钟，那么每个规则点会聚合四个样本，是合理的。若评估间隔远大于原始间隔，则会丢弃中间样本，造成信息损失。此外，Prometheus的本地数据保留期建议设短一些，长期数据下沉到Thanos或Mimir，这些系统支持基于块的降采样，自动生成五分钟和一小时分辨率块，查询时按区间智能选择。
下面给出一个简单的Recording Rules示例，将请求延迟原始数据降采样为一分钟内的p99和平均值，方便后续告警和看板直接使用低精度指标：
groups:
- name: latency_down_sample
rules:
- record: http_request_latency_p99_1m
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1m])) by (le))
- record: http_request_latency_avg_1m
expr: avg_over_time(http_request_duration_seconds_sum[1m]) / avg_over_time(http_request_duration_seconds_count[1m])
降采样策略制定时还要结合业务SLA。交易类接口要求秒级感知故障，原始数据至少要保留一天，降采样后的高粒度数据用于周报。离线分析类指标则可以直接从五分钟粒度起步。只有把保留周期、聚合函数、窗口大小三者联动设计，才能既压住成本又保住观测能力。
monitoring_datadown_samplingtime_series修改时间：2026-08-18 09:00:38