应使用 mimir 而非 prometheus 直连 minio，因 prometheus 仅输出 wal 和内存快照，不支持对象存储直写；mimir 才负责长期存储、查询聚合与多租户隔离，并提供水平扩展、多副本读取等高可用能力。
为什么不用 Prometheus 直连 MinIO，而要走 Mimir
直接把 Prometheus 的 remote_write 指向 MinIO 是常见误解。Prometheus 本身不支持对象存储直写，它只输出 WAL 和内存快照；真正做长期存储、查询聚合、多租户隔离的，是 Mimir —— 它才是那个“把指标存进 MinIO 并对外提供查询服务”的组件。跳过 Mimir 直连，等于放弃水平扩展、多副本读取、跨集群查询、租户配额等高可用能力。
Mimir 配置必须启用 ingester + storage 分离部署
在微服务集群里混部 Mimir 组件极易引发资源争抢：ingester 吞吐高、内存敏感，storage（如 blocks 或 tsdb）读写重、磁盘 IO 密集。生产环境必须拆开：
-
ingester部署在计算密集型节点，绑定 CPU 亲和性，配置-ingester.lifecycle.period=30s控制 flush 频率 -
storage（含querier、store-gateway）部署在大内存+SSD 节点，MinIO endpoint 必须用http://minio:9000（不能是https，除非显式配 TLS 证书） -
ring依赖 Consul 或 etcd：Mimir 默认用memberlist做 ring 自发现，但跨 AZ 不稳定，建议强制指定-ring.store=consul -ring.consul.hostname=consul:8500
Go 服务暴露指标时，remote_write 地址不是 Mimir 的 HTTP 端口
很多团队把 Prometheus 的 remote_write.url 设成 http://mimir:9009/api/v1/push，这是错的 —— 这个端口只收 push 请求（如 OpenTelemetry Collector），而 Prometheus 自身走的是 /api/v1/write，且必须带 X-Scope-OrgID header。
正确配置片段：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
remote_write:
- url: http://mimir:9009/api/v1/write
headers:
X-Scope-OrgID: "default"
注意：X-Scope-OrgID 是租户隔离关键，不能省；若用多租户，每个微服务应配不同 OrgID（如 "order-service"），避免指标混杂。
冷热分离靠 retention + compaction 配置，不是靠手动删 MinIO bucket
所谓“冷热分离”，本质是让新写入指标走高频写路径（ingester → 内存 → WAL → 对象存储），旧数据走低频读路径（store-gateway → MinIO → querier）。Mimir 不靠目录划分，靠时间窗口控制：
-
-blocks-storage.tsdb.retention-period=720h（30 天）：超过此时间的 block 自动标记为可删除 -
-blocks-storage.tsdb.compaction.interval=2h：每 2 小时合并小 block 成大 block，降低查询压力 -
-blocks-storage.bucket-store.sync-interval=15m：store-gateway 每 15 分钟同步一次 MinIO 中的新 block 列表
真正“冷”的数据（比如 90 天前）需配合 MinIO 的生命周期策略（Lifecycle Rule）自动转归档或删除，Mimir 本身不管理对象存储底层生命周期。
最易被忽略的是 ingester 的 WAL 清理 —— 如果没配 -ingester.wal-dir 或磁盘满，ingester 会拒绝写入并静默失败，整个链路就断了。务必监控 mimir_ingester_wal_samples_dropped_total 指标。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
