对于每天产生数十亿条样本的 CDN 平台来说，指标存储的难点不只是容量，还包括写入吞吐、查询延迟和长期保留成本。Grafana Mimir 通过兼容 Prometheus remote_write 协议，让现有的 Prometheus 或 Grafana Agent 无需改动采集逻辑，就能把数据转发到支持对象存储的集群。实际落地时，需要重点处理高基数标签、块压缩策略和查询下推，否则可能写入阻塞或查询超时。
一、CDN 指标的高基数与容量问题
CDN 的监控指标往往带有大量标签，例如域名、边缘节点、运营商、缓存状态、回源地址等。一个域名若同时区分 200 个节点和 10 种缓存状态，单是 cdn_cache_status 一个指标就可能产生数千个活跃序列。Prometheus 单实例在内存中为每个序列维护索引和最近样本，当序列数超过几百万时，内存占用和查询扫描成本都会明显上升。长期保存时，本地 TSDB 会产生大量块文件，压缩和合并的效率下降，冷数据查询需要打开大量文件，很容易拖垮查询。
因此，把 CDN 指标直接交给 Prometheus 本地存储，通常只能保留 15 到 30 天。要延长到半年或一年，需要把数据转移到支持对象存储的远程时序数据库。Mimir 的设计目标之一就是兼容 Prometheus 查询语义，同时把历史数据压缩后放到 S3、GCS 或阿里云 OSS 等对象存储中。它的 ingester 先接收写入并缓冲在内存，达到一定时间或大小后刷成块，compactor 定期合并小块为大块，并做索引压缩和样本去重，从而减少对象存储中的小文件数量。
高基数仍然需要从源头控制。CDN 指标中像客户端 IP、完整 URL 这类维度不适合直接作为标签，否则序列数会失控。实践中通常只保留域名、区域、节点、状态码等聚合维度，把 URL 和 IP 转到日志系统或使用 limit 聚合。Mimir 也会对标签数量和高基数样本做限制，默认允许的 label 数量有限，能在写入端拦住部分异常。
二、Mimir 的存算分离与块存储设计
Mimir 集群由多个组件构成：distributor 负责接收 remote_write 请求并按一致性哈希分发；ingester 持有最近写入的数据，当内存达到阈值时把块上传到对象存储；compactor 拉取对象存储中的块进行合并、去重和索引优化；store-gateway 维护对象存储中块的索引，查询时只加载相关块。querier 接收 PromQL 查询，向 ingester 和 store-gateway 请求数据并合并结果。这个架构让写入和查询可以独立扩缩容，不会因为历史数据量大而拖垮写入。
长期存储的关键在于块格式。Mimir 复用了 Prometheus 的 TSDB 块格式，但通过 compactor 把分钟级的小块合并成更大的时间范围块，例如 2 小时块再合并为 12 小时块，最后可以合并为更大的块。合并过程会去掉重复样本、压缩索引，并把块上传到对象存储。对于 CDN 指标这种样本密度高、标签基数大的数据，压缩收益很明显，通常可以达到 10 倍以上的体积缩减。查询时，store-gateway 根据时间范围和标签匹配条件读取最少的块，避免全表扫描。
另外，Mimir 的 ruler 组件可以执行 Recording Rules 和 Alerting Rules。Recording Rules 把频繁使用的高基数查询预先聚合成低基数指标，例如把所有节点的请求速率聚合成按域名和区域的总速率。这样面板查询只需读取聚合后的少量序列，而不是实时扫描全部边缘节点。对于 CDN 指标，强烈建议启用 Recording Rules，因为原始序列数量大，实时聚合会消耗大量 querier 资源。
三、通过 remote_write 接入 CDN 指标
现有 Prometheus 或 Grafana Agent 的接入成本很低，只需要在配置中增加 remote_write 段，指向 Mimir 的 distributor 地址。以下是一个 Prometheus 配置片段：
remote_write:
- url: http://mimir-gateway.ipipp.com:9009/api/v1/push
queue_config:
capacity: 10000
max_shards: 30
min_shards: 1
max_samples_per_send: 2000
batch_send_deadline: 5s
min_backoff: 30ms
max_backoff: 5s
这里的 url 是 Mimir distributor 的写入入口，通常通过负载均衡或网关暴露。如果使用 Grafana Agent，只需把同样的 remote_write 配置放到 metrics 部分。queue_config 控制发送队列的容量和分片数。CDN 指标写入量高时，需要适当调大 capacity 和 max_shards，避免 Prometheus 本地堆积过多样本。若写入端堆积，Prometheus 的内存和磁盘 WAL 会增长，甚至影响抓取。
接入之后，可以用下面的 PromQL 确认 Mimir 收到了数据：
count({__name__=~"cdn_.*"})
这条查询会统计当前所有以 cdn_ 开头的指标序列数量。如果数字很大，说明高基数问题已经开始显现。可以在 Prometheus 抓取阶段通过 relabel_configs 删除不必要的标签，例如 url_path、client_ip。如果已经在 Agent 端采集，建议使用 keep 和 drop 动作提前过滤，减少写入 Mimir 的序列数。
四、查询优化与 Recording Rules
CDN 监控面板通常关注全局带宽、缓存命中率、回源比例、状态码分布和按域名或节点排序的慢请求。直接对原始指标执行 sum(rate(cdn_requests_total[5m])) by (host) 会扫描大量序列。Mimir 的 querier 需要向所有相关 ingester 和 store-gateway 发起请求，查询时间范围越长，涉及的块越多，延迟越高。对于跨越几周或几个月的趋势图，应当优先读取 Recording Rules 生成的聚合指标。
以下是一条针对 CDN 请求速率的 Recording Rule：
groups:
- name: cdn_aggregations
interval: 1m
rules:
- record: cdn:requests_rate:5m
expr: sum by (host, region) (rate(cdn_requests_total[5m]))
- record: cdn:cache_hit_ratio:5m
expr: sum by (host) (rate(cdn_cache_hit_total[5m]))
/
sum by (host) (rate(cdn_requests_total[5m]))
这些规则由 Mimir ruler 定期计算，结果作为新指标写入存储。面板查询 cdn:requests_rate:5m 时只需要读取非常少的序列，响应速度可以提升数倍。需要注意的是，Recording Rules 会消耗 ruler 的 CPU 和内存，规则数量不宜无限增加，尤其是高基数标签组合。建议只聚合到面板实际需要的维度，例如 host 和 region，不要把 status_code 等细节也加入长期聚合。
另一个优化手段是合理设置查询时间范围和步长。对于长时间窗口的趋势图，使用较大的 step，例如 10 分钟或 1 小时，Mimir 会在查询层做降采样，减少返回数据点。若需要查看单个节点的详细指标，再切换回短时间窗口和高分辨率。这样既保持面板流畅，又不会因为长时间高分辨率查询把集群资源打满。
五、容量规划与成本控制
Mimir 的存储成本主要由对象存储中的数据量决定。CDN 指标经过压缩后，每天的新增数据量可以用以下方式估算：先统计活跃序列数，再乘以每个序列每秒产生的样本数。例如 500 万个活跃序列，每个序列每 15 秒一个样本，则每秒约 33 万个样本，每天约 285 亿个样本。每个样本压缩后按 1.2 字节粗略估算，每天新增约 34GB，保留一年约 12TB 左右。实际压缩率受标签值和样本分布影响，CDN 指标通常比基础设施指标更容易压缩，因为很多标签值重复。
为了控制长期保留成本，可以分层设置保留策略。Mimir 允许将不同租户的数据配置不同的保留时间，例如最近 30 天的原始指标保留在快速查询路径，超过 30 天的数据只保留 Recording Rules 聚合结果。对于 CDN 场景，原始节点级指标可以设置 60 到 90 天，聚合指标设置一年以上。这样既能满足故障回溯需求，又能显著降低对象存储费用。
此外，需要关注 Mimir 集群的内存与 CPU 配比。ingester 内存决定能缓冲多少写入，通常按照每秒样本数乘以 3 到 6 倍来规划；store-gateway 和 querier 的数量取决于查询并发和历史数据范围。上线前建议用真实 CDN 流量做压测，观察写入延迟、WAL 增长和查询延迟，再逐步调大 max_shards 和 capacity。不要直接照搬单机 Prometheus 的限流参数，否则远程写入队列容易成为瓶颈。
综合来看，Grafana Mimir 为 CDN 指标的长期保存提供了一条兼容现有 Prometheus 技术栈的路径。关键是提前控制标签基数，善用 Recording Rules 降低长期查询压力，再根据数据量和保留周期规划对象存储容量。这样可以在不大幅改变采集和可视化习惯的前提下，把 CDN 指标保留周期从几周扩展到一年甚至更长。
Grafana MimirCDN指标时序数据库修改时间：2026-10-07 00:42:21