规划 Grafana Mimir 容量
以下信息概述了 Grafana Mimir 在大规模运行时所需的 CPU、内存和磁盘空间。您可以大致了解所需的资源，而不是获得关于 CPU、内存和磁盘空间确切数量的规范性建议。
资源利用率是基于一般的生产工作负载估算的，并假设 Grafana Mimir 以单租户和默认配置运行。您的实际资源利用率可能有所不同，因为它取决于实际数据、配置设置和流量模式。例如，实际资源利用率可能会因时序标签的实际数量或长度，或到达 store-gateway 的查询百分比而异。
资源利用率是最低要求。为了优雅地处理流量高峰，建议为 Grafana Mimir 的内存和磁盘额外预留 50% 的容量。
单体模式
当 Grafana Mimir 以单体模式运行时，您可以通过汇总每个 Grafana Mimir 组件的需求来估算所需资源。有关每个组件需求的更多信息，请参阅微服务模式。
微服务模式
当 Grafana Mimir 以微服务模式运行时，您可以单独估算每个组件所需的资源。
Distributor
Distributor 组件的资源利用率由每秒接收的样本数量决定。
预估所需的 CPU 和内存
- CPU: 每秒 25,000 个样本需要 1 个核心。
- 内存: 每秒 25,000 个样本需要 1GB。
如何估算每秒样本率
- 查询所有 Prometheus 服务器上的活跃时序数量
sum(prometheus_tsdb_head_series) - 检查您在 Prometheus 中配置的 scrape_interval。
- 使用以下公式估算每秒样本率
estimated rate = (<active series> * (60 / <scrape interval in seconds>)) / 60
Ingester
Ingester 组件的资源利用率由内存中的时序数量决定。
预估所需的 CPU、内存和磁盘空间
- CPU: 内存中每 30 万时序需要 1 个核心
- 内存: 内存中每 30 万时序需要 2.5GB
- 磁盘空间: 内存中每 30 万时序需要 5GB
如何估算内存中的时序数量
- 查询所有 Prometheus 服务器上的活跃时序数量
sum(prometheus_tsdb_head_series) - 检查配置的
-ingester.ring.replication-factor（默认为3） - 使用以下公式估算所有 Ingester 中内存中的总时序数量
total number of in-memory series = <active series> * <replication factor>
Query-frontend
Query-frontend 组件的资源利用率由每秒查询数量决定。
预估所需的 CPU 和内存
- CPU: 每秒 250 个查询需要 1 个核心
- 内存: 每秒 250 个查询需要 1GB
(可选) Query-scheduler
Query-scheduler 组件的资源利用率由每秒查询数量决定。
预估所需的 CPU 和内存
- CPU: 每秒 500 个查询需要 1 个核心
- 内存: 每秒 500 个查询需要 100MB
Querier
Querier 组件的资源利用率由每秒查询数量决定。
预估所需的 CPU 和内存
- CPU: 每秒 10 个查询需要 1 个核心
- 内存: 每秒 10 个查询需要 1GB
注意
预估为每个查询需要 1 个 CPU 核心和 1GB 内存，平均查询延迟为 100 毫秒。
Store-gateway
Store-gateway 组件的资源利用率由每秒查询数量以及 Ingester 复制前的活跃时序数量决定。
预估所需的 CPU、内存和磁盘空间
- CPU: 每秒 10 个查询需要 1 个核心
- 内存: 每秒 10 个查询需要 1GB
- 磁盘: 每 100 万活跃时序需要 13GB
注意
CPU 和内存需求是根据以下估算计算得出的：每个查询需要 1 个 CPU 核心和 1GB 内存，到达 store-gateway 时平均查询延迟为 1 秒，并且只有 10% 的查询会到达 store-gateway。
注意
磁盘需求是基于以下假设估算的：压缩块（索引和 Chunk）每个样本 2 字节，索引头占块大小的 0.10%，采集间隔 15 秒，保留期 1 年，并且 store-gateways 复制因子配置为 3。因此，单个时序预估所需的 store-gateway 磁盘空间为 13KB。
如何估算 Ingester 复制前的活跃时序数量
- 查询所有 Prometheus 服务器上的活跃时序数量
sum(prometheus_tsdb_head_series)
(可选) Ruler
Ruler 组件的资源利用率由每秒评估的规则数量决定。
使用内部模式（默认）时，规则评估的计算量与查询执行相当，因此 Querier 的资源建议也适用于 Ruler。
使用远程操作模式时，大部分计算负载会转移到 Query-frontend 和 Querier 组件。因此，应相应地调整它们的规模，以处理查询和规则评估工作负载。
Compactor
Compactor 组件的资源利用率由活跃时序数量决定。
Compactor 在单租户和多租户的 Grafana Mimir 集群中都可以横向扩容。我们建议每 2000 万总摄取的活跃时序（在 Ingester 复制之前计算）至少运行一个 Compactor 实例。
假设您每 2000 万活跃时序运行一个 Compactor 实例，则每个 Compactor 实例预估所需的 CPU、内存和磁盘为
- CPU: 1 个核心
- 内存: 4GB
- 磁盘: 300GB
有关磁盘需求的更多信息，请参阅Compactor 磁盘利用率。
要估算 Ingester 复制前的活跃时序数量，请查询所有 Prometheus 服务器上的活跃时序数量
sum(prometheus_tsdb_head_series)(可选) Alertmanager
Alertmanager 组件的资源利用率由同时触发的告警数量决定。
预估所需的 CPU 和内存
- CPU: 每秒 100 个触发的告警通知需要 1 个 CPU 核心
- 内存: 每 5000 个触发的告警需要 1GB
要估算过去 24 小时内每秒触发的峰值告警通知数量，请在所有 Prometheus 服务器上运行以下查询
sum(max_over_time(rate(alertmanager_alerts_received_total[5m])[24h:5m]))要估算过去 24 小时内触发的最大告警数量，请在所有 Prometheus 服务器上运行以下查询
sum(max_over_time(alertmanager_alerts[24h]))(可选) 缓存
Grafana Mimir 在读取路径的各个阶段支持缓存
- 结果缓存，用于缓存部分查询结果
- Chunk 缓存，用于缓存对象存储中的时序 Chunk
- 索引缓存，用于加速时序和标签查找
- 元数据缓存，用于加速查找单个时序块
扩展这些缓存的 memcached 部署的经验法则是查看逐出（evictions）速率。如果在稳定负载期间为 0，仅偶尔出现峰值，则 memcached 扩展充足。如果始终大于 0，则需要横向扩展 memcached。
您可以执行以下查询来查找逐出速率
sum by(instance) (rate(memcached_items_evicted_total{}[5m]))此页面有帮助吗？
来自 Grafana Labs 的相关资源
