总结：Grafana Mimir调研

小魏的博客

已于 2024-07-10 15:23:05 修改

阅读量1.6k

点赞数

分类专栏： K8S 数据库文章标签： grafana mimir OSS 云原生

于 2023-04-23 11:17:00 首次发布

本文链接：https://blog.csdn.net/w2009211777/article/details/130317505

版权

一、背景

Prometheus单实例，可用性低，可靠性低，不能存储更多数据。

解决业务问题
- 如：当前QKE是一个集群+一个项目一个prometheus实例，那么当我一个应用分多个集群部署的时候，查询数据时就得从三个prometheus去查，然后聚合，比较麻烦。用mimir就不存在这个问题

Prometheus 集群方案之 Remote Read 实战_Go中国的博客-CSDN博客

有些业务无法拆分，数据量还是特别大。
数据收集和查询做的事情是完全独立的，但两者时常相互竞争占用资源。

二、Grafana Mimir 核心优势

1、易维护性

Grafana Mimir 的核心优势之一便是易于“安装和维护”。该项目的大量文档、教程和部署工具使其入门起来既快速又简单。Grafana Mimir 的整体模式允许只使用一个二进制文件，不需要额外的依赖项。此外，与 Grafana Mimir 一起打包的最佳实践仪表板、警报和运行手册可以轻松监控系统的健康状况并保持其平稳运行。

2、可扩展性

同时，Grafana Mimir 的水平可扩展架构使其能够处理大量时间序列数据。内部测试表明，该系统可以处理多达 10 亿个活动时间序列，从而实现大规模的可扩展性。这意味着 Grafana Mimir 可以跨多台机器运行，从而能够处理比单个 Prometheus 实例多几个数量级的时间序列。

3、全局视图

除此之外，Grafana Mimir 的另一个关键优势是它能够提供全局的指标视图。该系统使用户能够运行聚合来自多个 Prometheus 实例的系列的查询，从而提供所有系统的全面视图。查询引擎还广泛并行化查询执行，即使是最高基数的查询也能以极快的速度执行。

4、数据持久性

Grafana Mimir 使用对象存储来进行长期数据存储，利用了这种无处不在的、高性价比、高耐久性的技术。该系统与多个对象存储实现兼容，包括 AWS S3、谷歌云存储、Azure Blob 存储、OpenStack Swift 以及任何与 S3 兼容的对象存储。这为用户提供了一种廉价、耐用的方式来存储用于长期分析的指标。

5、通过复制实现高可用性

高可用性是 Grafana Mimir 的另一个关键特性。系统复制传入的指标，确保在机器发生故障时不会丢失任何数据。其水平可扩展架构还意味着它可以在零停机的情况下重启、升级或降级，确保指标摄取或查询不会中断。

6、原生多租户‍‍

最后，Grafana Mimir 的原生多租户允许独立团队或业务部门的数据和查询隔离，使这些组可以共享同一个集群。高级限制和服务质量控制确保容量在租户之间公平共享，使其成为拥有多个团队和部门的大型组织的绝佳选择。

二、Prometheus为什么是单实例？

Prometheus一直强调，只做核心功能。

另外，Prometheus 结合 Go 语言的特性和优势，使得 Prometheus 能够以更小的代价抓取并存储更多数据，而 Elasticsearch 或 Cassandra 等 Java 实现的大数据项目处理同样的数据量会消耗更多的资源。也就是说，单实例、不可扩展的 Prometheus 已强大到可以满足大部分用户的需求。

看下：
1.grafana查mimir这个promerheus数据源，看下配置的查询地址是什么，我想知道是不是查的query组件，端口是什么。另外可以f12看看是否有调用请求
* 数据持久化到硬盘的方案里，VictoriaMetrics 是更好的选择
* 数据持久化到对象存储的方案中，Thanos 更受欢迎，Grafana Mimir 更有潜力。

对象存储与本地盘存储

Mimir需要etcd吗？

三、Grafana Mimir 分布式架构‍

Grafana Mimir 的分布式架构可参考如下示意图：

从上图可以看出 Mimir 有 7 个不同的组件，给人的第一印象是一个复杂的系统。值得庆幸的是，helm chart 使事情变得更容易，而且还有根据有效负载提供了资源分配建议。

针对架构中的不同组件功能解析，可以参考如下文件以及源码进行探究，具体如下：

serviceMonitor:
  enabled: true
 
# disabled, external ruler is used
ruler:
  enabled: false
 
# disabled, external alertmanager is used
alertmanager:
  enabled: false
 
# disabled, blocks_storage is used
minio:
  enabled: false
 
compactor:
  nodeSelector:
    app: mimir
  tolerations:
    - key: app
      value: compactor
      operator: Equal
      effect: NoSchedule
  persistentVolume:
    storageClass: standard-rwo
    size: 50Gi
  resources:
    limits:
      cpu: 1200m
      memory: 2Gi
    requests:
      cpu: 1200m
      memory: 2Gi
 
distributor:
  extraArgs:
    distributor.ingestion-rate-limit: "10000000000000"
  replicas: 5
  nodeSelector:
    app: mimir
  tolerations:
    - key: app
      value: distributor
      operator: Equal
      effect: NoSchedule
  resources:
    limits:
      memory: 4Gi
      cpu: 2
    requests:
      memory: 4Gi
      cpu: 2
 
ingester:
  extraArgs:
    ingester.max-global-series-per-user: "0"
    ingester.max-global-series-per-metric: "0"
  nodeSelector:
    app: mimir
  tolerations:
    - key: app
      value: ingester
      operator: Equal
      effect: NoSchedule
  persistentVolume:
    size: 150Gi
    storageClass: standard-rwo
  replicas: 5
  resources:
    limits:
      memory: 25Gi
      cpu: 4
    requests:
      memory: 25Gi
      cpu: 4
 
chunks-cache:
  nodeSelector:
    app: mimir
  enabled: true
  replicas: 2
 
index-cache:
  nodeSelector:
    app: mimir
  enabled: true
  replicas: 3
 
metadata-cache:
  nodeSelector:
    app: mimir
  enabled: true
 
results-cache:
  nodeSelector:
    app: mimir
  enabled: true
 
overrides_exporter:
  nodeSelector:
    app: mimir
  replicas: 1
  resources:
    limits:
      memory: 256Mi
    requests:
      cpu: 100m
      memory: 128Mi
 
querier:
  extraArgs:
    querier.max-fetched-chunks-per-query: "8000000"
  replicas: 4
  nodeSelector:
    app: mimir
  tolerations:
    - key: app
      operator: Equal
      value: querier
      effect: NoSchedule
  resources:
    limits:
      memory: 24Gi
      cpu: 2
    requests:
      memory: 24Gi
      cpu: 2
 
query_frontend:
  replicas: 1
  nodeSelector:
    app: mimir
  tolerations:
    - key: app
      operator: Equal
      value: query-frontend
      effect: NoSchedule
  resources:
    limits:
      memory: 6Gi
      cpu: 2
    requests:
      memory: 6Gi
      cpu: 2
 
store_gateway:
  persistentVolume:
    size: 50Gi
  replicas: 1
  nodeSelector:
    app: mimir
  tolerations:
    - key: app
      operator: Equal
      value: store-gateway
      effect: NoSchedule
  resources:
    limits:
      cpu: 1
      memory: 6Gi
    requests:
      cpu: 1
      memory: 6Gi
 
mimir:
  structuredConfig:
    limits:
      out_of_order_time_window: 1h
    blocks_storage:
      backend: gcs
      gcs:
        bucket_name: <bucket_name>
        service_account: |
          {<secret>}
metaMonitoring:
  serviceMonitor:
    enabled: true

再来一张：

这张更能直观的看出来memberlist的作用：

四、数据抓取的高可靠：HATracker

参考：Mimir 速体验 (Part 4)：数据抓取的高可靠：Mimir 速体验 (Part 4)：数据抓取的高可靠_Grafana_Grafana 爱好者_InfoQ写作社区

在 Prometheus 生态中，不仅要实现数据存储的高可靠，还要实现数据抓取（Agent/Collector）的高可靠，通常大家也是采用相似的策略，即针对相同配置起多个 Prometheus 实例，然后再将每个实例抓取的结果通过 remote write 推送到同一存储后端。

这样做虽然带来了抓取的高可靠，但如果数据不去重（在一个抓取周期内，distributor 只需转发一个 Prometheus 抓取的数据），每个 Prometheus 示例抓取的指标最终都要转发给 ingester，这会导致 ingester 数据写入量和 compactor block 压缩量翻倍，这将带来资源的浪费。

那该如何去重呢？在 Mimir/Cortex 中主要使用到 distributor 的 HATracker 功能。

HATracker 的基本逻辑：

大致流程如下：

启动两个 Prometheus Agent 针对同一 APP 进行指标抓取。
两个 Prometheus Agent 通过 global external_labels 注入 {cluster: team1, replica: replica1/replica2} 的复制组标示，所有的指标都会带上该信息。
Mimir 开启 HATracker 功能后，distributor 会根据指标的 cluster,replica 分组情况进行 Prometheus Agent 选主，假如这里选择了 replica1 ，并将结果写到 KV （目前只支持 consul 和 etcd）中。
以后 distributor 所有节点接收到 Agent 转发的数据，会判断是否来自 replica1，如果是进行转发（转发数据会删除 replica 标签），如果不是则丢弃。

当 replica1 agent 故障后，超过 HATracker 配置的 ha_tracker_failover_timeout 时间，将触发 agent 重新选主，即变为 replica2，并存储到 KV 中，以后所有 replica2 agent 的数据会被转发，而待 replica1 恢复后，它上报的数据也只会被丢弃。

可以看到，有了 HATracker ，同一 cluster 的数据，在 distributor 实现了去重，从而只有一个 agent 的数据写到了 ingester。

如何配置

修改 prometheus.yaml，添加 external_labels，内容如下：

global:  external_labels:    cluster: team1    __replica__: replica1和

global:  external_labels:    cluster: team1    __replica__: replica2

注：我们可以只使用 Prometheus Agent 模式启动实例，而且可以通过环境变量方式注入 replica 信息。

修改 mimir/cortex distributor 配置，开启 ha_tracker，并配置对应 kvstore。

limits:  accept_ha_samples: true
distributor:  ha_tracker:

最低0.47元/天解锁文章

小魏的博客

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
总结：Grafana Mimir调研

Mimir
复制链接

扫一扫

专栏目录