使用 Prometheus AlertManager 为 MinIO 配置告警从部署配置到擦除集容错告警实战【免费下载链接】minioMinIO is a high-performance, S3 compatible object store, open sourced under GNU AGPLv3 license.项目地址: https://gitcode.com/GitHub_Trending/mi/minio本文围绕 MinIO 官方告警文档 docs/metrics/prometheus/alerts.md 展开完整讲解如何在 Prometheus 之上接入 AlertManager、编写针对 MinIO 集群的告警规则并用真实的 webhook 报文验证告警链路。读完本文你将掌握 AlertManager 的部署与路由/抑制配置、prometheus.yml的告警接入方式以及如何用minio_cluster_health_erasure_set_status这类指标监控分布式 MinIO 的擦除码集合Erasure Set健康状态第一时间发现集群丧失写入仲裁quorum的故障。告警链路概览为什么需要 AlertManager基于 Prometheus 的告警是一个两步流程在 Prometheus Server 中定义并计算告警规则Alerting Rules规则表达式持续求值触发条件满足后告警进入Pending/Firing状态Prometheus 把已触发的告警推送给AlertManager由它统一负责告警的分组grouping、抑制inhibition、静默silencing再按路由分发到各类接收器Receiver。AlertManager 与 Prometheus 是相对独立的组件前者只负责“把告警发出去”后者只负责“判断什么时候该告警”。这种解耦让运维人员可以在不修改抓取scrape配置的前提下灵活切换邮件、Slack、PagerDuty、Webhook 等不同通知渠道。接收器的完整类型清单可参考 Prometheus 官方 Receiver 配置说明本仓库不重复罗列。前提说明本文假设你已经按 docs/metrics/prometheus/README.md 完成了 Prometheus 对 MinIO 的指标抓取配置——MinIO 默认通过/minio/v2/metrics/cluster、/minio/v2/metrics/bucket、/minio/v2/metrics/node、/minio/v2/metrics/resource四个鉴权端点暴露 Prometheus 兼容指标其中集群级指标必须来自任意一个正常节点。第一步部署并启动 AlertManager从 Prometheus 官方下载页面获取与你平台匹配的 AlertManager 二进制包并解压。随后创建 AlertManager 的配置文件通常名为alertmanager.yml下面是一份可直接落地的样例route: group_by: [alertname] group_wait: 30s group_interval: 5m repeat_interval: 1h receiver: web.hook receivers: - name: web.hook webhook_configs: - url: http://127.0.0.1:8010/webhook inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: [alertname, dev, instance]路由route参数逐项说明告警进入 AlertManager 后按route树进行匹配根路由是每一条告警的默认入口。上述配置各字段含义如下参数示例值作用group_by[alertname]告警分组键。相同alertname的告警会被归入同一通知组避免同一类故障刷屏group_wait30s组内第一条告警出现后等待多长时间才发送首批通知用于聚合短时间窗口内同时爆发的告警group_interval5m同一告警组产生新告警时的发送间隔repeat_interval1h同一组告警已持续未恢复时的重复提醒间隔对同一告警做“再次通知”的最小间隔receiverweb.hook该路由默认使用的接收器名称需与下方receivers中定义的名字一一对应接收器receivers与 webhook本例使用一个运行在http://127.0.0.1:8010/webhook的 webhook 作为接收端。注意8010端口上的服务并不是 AlertManager 或 Prometheus 自带组件它需要你自行实现并监听例如一个接收 POST JSON 的内部通知服务。AlertManager 会以 POST 方式把告警通知推送到该 URL。启动 AlertManager默认监听9093端口./alertmanager --config.filealertmanager.yml启动后务必先确认你的 webhook 服务已经就绪并能接收告警否则通知会被静默丢弃。抑制规则inhibit_rules的作用样例中的抑制规则表达的是当同一组equal: [alertname, dev, instance]保证了标签维度一致内存在severitycritical的源告警时自动屏蔽severitywarning的目标告警。这是标准的“高等级告警已上报、低等级不再重复打扰”降噪手段——例如节点宕机已触发 critical那么由此衍生的 warning 级存储延迟告警就没有再单独通知的必要。第二步配置 Prometheus 接入 AlertManager在 Prometheus 的主配置文件prometheus.yml中加入以下两段alerting: alertmanagers: - static_configs: - targets: [localhost:9093] rule_files: - rules.ymlalerting.alertmanagers声明 AlertManager 实例地址。本例为单机localhost:9093生产环境可用static_configs.targets列出多个 AlertManager 形成高可用也可以改用服务发现。rule_files声明告警规则文件rules.yml是相对prometheus.yml的路径文件内定义所有告警规则。保存后重启或向 Prometheus 发送SIGHUP重载配置即可生效。第三步为 MinIO 部署编写告警规则MinIO 集群级指标中与数据可用性最直接相关的是擦除码集合健康类指标。下面是官方文档提供的一份告警规则样例写入rules.ymlgroups: - name: example rules: - alert: MinIOClusterTolerance expr: minio_cluster_health_erasure_set_status 1 for: 5m labels: severity: critical annotations: summary: Instance {{ $labels.server }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }} description: MinIO instance {{ $labels.server }} of job {{ $labels.job }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }} for more than 5 minutes.规则含义拆解expr表达式持续求值。minio_cluster_health_erasure_set_status为 1 表示该擦除集健康、0 表示不健康因此 1表示“至少有一个擦除集失去写仲裁”。for: 5m状态需要连续保持 5 分钟才会从Pending转为Firing并真正通知可有效过滤瞬时抖动。labels.severity: critical给告警打上严重级别标签供 AlertManager 的抑制规则与路由匹配使用。annotations模板化的告警描述$labels引用告警携带的标签如server、pool、set、job。指标背后的实现这个告警到底在探测什么要正确使用该规则需要理解它探测的对象。MinIO 以擦除码集合Erasure Set为容错单元一个 Server Pool 由若干 erasure set 组成数据写入时被拆分为数据块与校验块Data/Parity shards分布到集合内的驱动器上。当某个集合内在线驱动器数量不足以维持写入仲裁时该集合上的读写就会降级甚至失败。从源码可以印证这条指标的生成链路Prometheus 抓取的 v2 集群指标由getClusterHealthMetrics注册见 cmd/metrics-v2.go。它通过objLayer.Health(ctx, opts)获取整体健康状态并为每一个擦除集追加携带pool、set标签的 5 个指标minio_cluster_health_erasure_set_read_quorum、..._write_quorum、..._online_drives、..._healing_drives、..._status。其中status值为 1健康或 0不健康。底层数据来自erasureServerPools.Health见 cmd/erasure-server-pool.go它遍历StorageInfo返回的磁盘状态统计每个 pool/set 上处于DriveStateOk的在线盘与正在 heal 的盘再结合存储类配置STANDARD的数据盘/校验盘数量计算读写仲裁数ReadQuorum/WriteQuorum。更新的 v3 指标实现见 cmd/metrics-v3-cluster-erasure-set.go进一步把概念细化为可推导的“容错值”read_tolerance 在线盘数 - 读仲裁write_tolerance 在线盘数 修复中盘数 - 写仲裁任一容错值小于 0 即判定该集合在对应操作上不健康。这也解释了为何部分旧版示例规则写作minio_cluster_health_erasure_set_tolerance 0——两种写法探测的是同一物理事实前者用状态位0/1后者用容错余量可负。因此把该规则解读为业务语言就是某个擦除集已连续 5 分钟无法容忍更多的盘/节点故障写入可靠性已不达标需立即介入。在 4 节点分布式部署中这意味着集群可能即将或已经丧失写入能力。扩展告警思路可选在rules.yml中同一 group 下可以追加更多与健康相关的规则此处为基于上文指标的合理扩展示例请按实际部署的节点/盘数量校准表达式与阈值- alert: MinIOErasureSetDrivesOffline expr: minio_cluster_health_erasure_set_online_drives minio_cluster_health_erasure_set_write_quorum for: 2m labels: severity: warning告警规则书写的完整语法表达式、模板、for语义等请查阅 Prometheus 官方 Alerting Rules 文档。第四步验证配置与告警是否真正生效在真实分布式环境中按下面的步骤做一次端到端演练启动一个4 节点的分布式 MinIO 实例4 个节点通常对应 4 个独立 erasure set能够模拟集合容错阈值启动 Prometheus Server 与 AlertManager确保已加载上文两个配置文件依次停掉若干 MinIO 节点使对应擦除集的容错值降到 -1。用 MinIO 客户端mc现场核对指标是否如预期变化mc admin prometheus metrics ALIAS | grep minio_cluster_health_erasure_set_status其中ALIAS替换为你为集群配置的 mc 别名。你会看到目标 pool/set 的status由 1 变为 0或旧版指标tolerance变为 -1。 4. 由于规则设置了for: 5m等待 5 分钟让告警从Pending翻转为Firing随后检查两处webhook 服务是否收到 POST 通知、Prometheus 的 Alerts 页面是否出现 Firing 记录。下图是原文档配套的一张 Prometheus Alerts 界面截图仓库内路径 docs/metrics/prometheus/minio-es-tolerance-alert.png展示了该场景下MinIOClusterTolerance告警处于 FIRING 状态、指标容错值为 -1 的真实效果Webhook 通知报文解读AlertManager 推送给 webhook 的 JSON 负载包含告警的完整上下文。官方文档记录了一次真实演练中收到的报文其中server标签代表故障节点127.0.0.1:9000pool/set定位到具体擦除集{ receiver: web\\.hook, status: firing, alerts: [ { status: firing, labels: { alertname: MinIOClusterTolerance, instance: localhost:9000, job: minio-job-node, pool: 0, server: 127.0.0.1:9000, set: 0, severity: critical }, annotations: { description: MinIO instance 127.0.0.1:9000 of job minio-job has tolerance 0 for more than 5 minutes., summary: Instance 127.0.0.1:9000 unable to tolerate node failures }, startsAt: 2023-11-18T06:20:09.456Z, endsAt: 0001-01-01T00:00:00Z, generatorURL: http://fedora-minio:9090/graph?g0.exprminio_cluster_health_erasure_set_tolerance%3C%3D0g0.tab1, fingerprint: 2255608b0da28ca3 } ], groupLabels: { alertname: MinIOClusterTolerance }, commonLabels: { alertname: MinIOClusterTolerance, instance: localhost:9000, job: minio-job-node, pool: 0, server: 127.0.0.1:9000, set: 0, severity: critical }, commonAnnotations: { description: MinIO instance 127.0.0.1:9000 of job minio-job has lost quorum on pool 0 on set 0 for more than 5 minutes., summary: Instance 127.0.0.1:9000 has lost quorum on pool 0 on set 0 }, externalURL: http://fedora-minio:9093, version: 4, groupKey: {}:{alertname\MinIOClusterTolerance\}, truncatedAlerts: 0 }关键字段速查字段含义receiver处理该通知的接收器名称与规则匹配到的路由 receiver 一致statusfiring已触发或resolved已恢复alerts[].labels该条告警的全部标签含规则 labels 与指标自身标签pool、set、server等alerts[].annotations规则里模板展开后的描述文本alerts[].startsAt/endsAt告警开始时间endsAt为0001-01-01T00:00:00Z表示尚未恢复alerts[].generatorURL指向 Prometheus 表达式页面的深链可直接回看查询表达式groupLabels/commonLabels该通知分组的分组键与全部告警共有的标签groupKey通知分组的唯一标识由group_by决定收到该报文即说明“Prometheus 计算规则 → AlertManager 路由/抑制 → Receiver 通知”整条链路已打通。告警恢复后 AlertManager 会再推送一条status: resolved的通知便于闭环跟踪。常见问题与排障要点Webhook 收不到告警先确认规则在 Prometheus Alerts 页是否已FiringPending不会推送再确认 AlertManager 路由的receiver名称与receivers定义严格一致并检查 webhook 服务本身是否可达、端口是否被防火墙拦截。抓取 401/403MinIO 的指标端点默认启用jwt鉴权Prometheus 抓取需携带mc admin prometheus generate生成的bearer_token若在开发环境临时放开可设置环境变量MINIO_PROMETHEUS_AUTH_TYPEpublic后重启 MinIO。详见 docs/metrics/prometheus/README.md。反代部署下的 Host 头Prometheus 抓取请求会携带Host: domain:port头。若 MinIO 位于 HAProxy、nginx 等反向代理/负载均衡之后需确保代理能把对该头域的请求正确路由到 MinIO 部署。关于server、pool、set标签annotations 模板中的可用标签取决于实际发出的指标标签与 Prometheus 追加的job/instance标签。示例报文中的标签来自真实分布式演练输出当前版本中擦除集健康指标按 cmd/metrics-v2.go 携带pool与set标签编写模板前建议先curl或mc admin prometheus metrics实测确认。进一步阅读告警规则文档本文主体docs/metrics/prometheus/alerts.mdPrometheus 抓取配置与鉴权方式docs/metrics/prometheus/README.mdMinIO 暴露的全部指标定义含本文涉及的 health 族指标docs/metrics/prometheus/list.md官方 Grafana 仪表盘其面板同样引用minio_cluster_health_erasure_set_status等指标docs/metrics/prometheus/grafana/minio-dashboard.json健康指标底层实现cmd/erasure-server-pool.goHealthResult与Health、cmd/metrics-v3-cluster-erasure-set.go容错值推导结合上述告警规则与仓库内的指标文档你可以在故障发生时就通过 Webhook/IM 收到精确到 pool/set 的定位信息从而在集群真正失去写入仲裁前完成扩容、换盘或网络修复。【免费下载链接】minioMinIO is a high-performance, S3 compatible object store, open sourced under GNU AGPLv3 license.项目地址: https://gitcode.com/GitHub_Trending/mi/minio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Prometheus AlertManager 为 MinIO 配置告警：从部署配置到擦除集容错告警实战
使用 Prometheus AlertManager 为 MinIO 配置告警从部署配置到擦除集容错告警实战【免费下载链接】minioMinIO is a high-performance, S3 compatible object store, open sourced under GNU AGPLv3 license.项目地址: https://gitcode.com/GitHub_Trending/mi/minio本文围绕 MinIO 官方告警文档 docs/metrics/prometheus/alerts.md 展开完整讲解如何在 Prometheus 之上接入 AlertManager、编写针对 MinIO 集群的告警规则并用真实的 webhook 报文验证告警链路。读完本文你将掌握 AlertManager 的部署与路由/抑制配置、prometheus.yml的告警接入方式以及如何用minio_cluster_health_erasure_set_status这类指标监控分布式 MinIO 的擦除码集合Erasure Set健康状态第一时间发现集群丧失写入仲裁quorum的故障。告警链路概览为什么需要 AlertManager基于 Prometheus 的告警是一个两步流程在 Prometheus Server 中定义并计算告警规则Alerting Rules规则表达式持续求值触发条件满足后告警进入Pending/Firing状态Prometheus 把已触发的告警推送给AlertManager由它统一负责告警的分组grouping、抑制inhibition、静默silencing再按路由分发到各类接收器Receiver。AlertManager 与 Prometheus 是相对独立的组件前者只负责“把告警发出去”后者只负责“判断什么时候该告警”。这种解耦让运维人员可以在不修改抓取scrape配置的前提下灵活切换邮件、Slack、PagerDuty、Webhook 等不同通知渠道。接收器的完整类型清单可参考 Prometheus 官方 Receiver 配置说明本仓库不重复罗列。前提说明本文假设你已经按 docs/metrics/prometheus/README.md 完成了 Prometheus 对 MinIO 的指标抓取配置——MinIO 默认通过/minio/v2/metrics/cluster、/minio/v2/metrics/bucket、/minio/v2/metrics/node、/minio/v2/metrics/resource四个鉴权端点暴露 Prometheus 兼容指标其中集群级指标必须来自任意一个正常节点。第一步部署并启动 AlertManager从 Prometheus 官方下载页面获取与你平台匹配的 AlertManager 二进制包并解压。随后创建 AlertManager 的配置文件通常名为alertmanager.yml下面是一份可直接落地的样例route: group_by: [alertname] group_wait: 30s group_interval: 5m repeat_interval: 1h receiver: web.hook receivers: - name: web.hook webhook_configs: - url: http://127.0.0.1:8010/webhook inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: [alertname, dev, instance]路由route参数逐项说明告警进入 AlertManager 后按route树进行匹配根路由是每一条告警的默认入口。上述配置各字段含义如下参数示例值作用group_by[alertname]告警分组键。相同alertname的告警会被归入同一通知组避免同一类故障刷屏group_wait30s组内第一条告警出现后等待多长时间才发送首批通知用于聚合短时间窗口内同时爆发的告警group_interval5m同一告警组产生新告警时的发送间隔repeat_interval1h同一组告警已持续未恢复时的重复提醒间隔对同一告警做“再次通知”的最小间隔receiverweb.hook该路由默认使用的接收器名称需与下方receivers中定义的名字一一对应接收器receivers与 webhook本例使用一个运行在http://127.0.0.1:8010/webhook的 webhook 作为接收端。注意8010端口上的服务并不是 AlertManager 或 Prometheus 自带组件它需要你自行实现并监听例如一个接收 POST JSON 的内部通知服务。AlertManager 会以 POST 方式把告警通知推送到该 URL。启动 AlertManager默认监听9093端口./alertmanager --config.filealertmanager.yml启动后务必先确认你的 webhook 服务已经就绪并能接收告警否则通知会被静默丢弃。抑制规则inhibit_rules的作用样例中的抑制规则表达的是当同一组equal: [alertname, dev, instance]保证了标签维度一致内存在severitycritical的源告警时自动屏蔽severitywarning的目标告警。这是标准的“高等级告警已上报、低等级不再重复打扰”降噪手段——例如节点宕机已触发 critical那么由此衍生的 warning 级存储延迟告警就没有再单独通知的必要。第二步配置 Prometheus 接入 AlertManager在 Prometheus 的主配置文件prometheus.yml中加入以下两段alerting: alertmanagers: - static_configs: - targets: [localhost:9093] rule_files: - rules.ymlalerting.alertmanagers声明 AlertManager 实例地址。本例为单机localhost:9093生产环境可用static_configs.targets列出多个 AlertManager 形成高可用也可以改用服务发现。rule_files声明告警规则文件rules.yml是相对prometheus.yml的路径文件内定义所有告警规则。保存后重启或向 Prometheus 发送SIGHUP重载配置即可生效。第三步为 MinIO 部署编写告警规则MinIO 集群级指标中与数据可用性最直接相关的是擦除码集合健康类指标。下面是官方文档提供的一份告警规则样例写入rules.ymlgroups: - name: example rules: - alert: MinIOClusterTolerance expr: minio_cluster_health_erasure_set_status 1 for: 5m labels: severity: critical annotations: summary: Instance {{ $labels.server }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }} description: MinIO instance {{ $labels.server }} of job {{ $labels.job }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }} for more than 5 minutes.规则含义拆解expr表达式持续求值。minio_cluster_health_erasure_set_status为 1 表示该擦除集健康、0 表示不健康因此 1表示“至少有一个擦除集失去写仲裁”。for: 5m状态需要连续保持 5 分钟才会从Pending转为Firing并真正通知可有效过滤瞬时抖动。labels.severity: critical给告警打上严重级别标签供 AlertManager 的抑制规则与路由匹配使用。annotations模板化的告警描述$labels引用告警携带的标签如server、pool、set、job。指标背后的实现这个告警到底在探测什么要正确使用该规则需要理解它探测的对象。MinIO 以擦除码集合Erasure Set为容错单元一个 Server Pool 由若干 erasure set 组成数据写入时被拆分为数据块与校验块Data/Parity shards分布到集合内的驱动器上。当某个集合内在线驱动器数量不足以维持写入仲裁时该集合上的读写就会降级甚至失败。从源码可以印证这条指标的生成链路Prometheus 抓取的 v2 集群指标由getClusterHealthMetrics注册见 cmd/metrics-v2.go。它通过objLayer.Health(ctx, opts)获取整体健康状态并为每一个擦除集追加携带pool、set标签的 5 个指标minio_cluster_health_erasure_set_read_quorum、..._write_quorum、..._online_drives、..._healing_drives、..._status。其中status值为 1健康或 0不健康。底层数据来自erasureServerPools.Health见 cmd/erasure-server-pool.go它遍历StorageInfo返回的磁盘状态统计每个 pool/set 上处于DriveStateOk的在线盘与正在 heal 的盘再结合存储类配置STANDARD的数据盘/校验盘数量计算读写仲裁数ReadQuorum/WriteQuorum。更新的 v3 指标实现见 cmd/metrics-v3-cluster-erasure-set.go进一步把概念细化为可推导的“容错值”read_tolerance 在线盘数 - 读仲裁write_tolerance 在线盘数 修复中盘数 - 写仲裁任一容错值小于 0 即判定该集合在对应操作上不健康。这也解释了为何部分旧版示例规则写作minio_cluster_health_erasure_set_tolerance 0——两种写法探测的是同一物理事实前者用状态位0/1后者用容错余量可负。因此把该规则解读为业务语言就是某个擦除集已连续 5 分钟无法容忍更多的盘/节点故障写入可靠性已不达标需立即介入。在 4 节点分布式部署中这意味着集群可能即将或已经丧失写入能力。扩展告警思路可选在rules.yml中同一 group 下可以追加更多与健康相关的规则此处为基于上文指标的合理扩展示例请按实际部署的节点/盘数量校准表达式与阈值- alert: MinIOErasureSetDrivesOffline expr: minio_cluster_health_erasure_set_online_drives minio_cluster_health_erasure_set_write_quorum for: 2m labels: severity: warning告警规则书写的完整语法表达式、模板、for语义等请查阅 Prometheus 官方 Alerting Rules 文档。第四步验证配置与告警是否真正生效在真实分布式环境中按下面的步骤做一次端到端演练启动一个4 节点的分布式 MinIO 实例4 个节点通常对应 4 个独立 erasure set能够模拟集合容错阈值启动 Prometheus Server 与 AlertManager确保已加载上文两个配置文件依次停掉若干 MinIO 节点使对应擦除集的容错值降到 -1。用 MinIO 客户端mc现场核对指标是否如预期变化mc admin prometheus metrics ALIAS | grep minio_cluster_health_erasure_set_status其中ALIAS替换为你为集群配置的 mc 别名。你会看到目标 pool/set 的status由 1 变为 0或旧版指标tolerance变为 -1。 4. 由于规则设置了for: 5m等待 5 分钟让告警从Pending翻转为Firing随后检查两处webhook 服务是否收到 POST 通知、Prometheus 的 Alerts 页面是否出现 Firing 记录。下图是原文档配套的一张 Prometheus Alerts 界面截图仓库内路径 docs/metrics/prometheus/minio-es-tolerance-alert.png展示了该场景下MinIOClusterTolerance告警处于 FIRING 状态、指标容错值为 -1 的真实效果Webhook 通知报文解读AlertManager 推送给 webhook 的 JSON 负载包含告警的完整上下文。官方文档记录了一次真实演练中收到的报文其中server标签代表故障节点127.0.0.1:9000pool/set定位到具体擦除集{ receiver: web\\.hook, status: firing, alerts: [ { status: firing, labels: { alertname: MinIOClusterTolerance, instance: localhost:9000, job: minio-job-node, pool: 0, server: 127.0.0.1:9000, set: 0, severity: critical }, annotations: { description: MinIO instance 127.0.0.1:9000 of job minio-job has tolerance 0 for more than 5 minutes., summary: Instance 127.0.0.1:9000 unable to tolerate node failures }, startsAt: 2023-11-18T06:20:09.456Z, endsAt: 0001-01-01T00:00:00Z, generatorURL: http://fedora-minio:9090/graph?g0.exprminio_cluster_health_erasure_set_tolerance%3C%3D0g0.tab1, fingerprint: 2255608b0da28ca3 } ], groupLabels: { alertname: MinIOClusterTolerance }, commonLabels: { alertname: MinIOClusterTolerance, instance: localhost:9000, job: minio-job-node, pool: 0, server: 127.0.0.1:9000, set: 0, severity: critical }, commonAnnotations: { description: MinIO instance 127.0.0.1:9000 of job minio-job has lost quorum on pool 0 on set 0 for more than 5 minutes., summary: Instance 127.0.0.1:9000 has lost quorum on pool 0 on set 0 }, externalURL: http://fedora-minio:9093, version: 4, groupKey: {}:{alertname\MinIOClusterTolerance\}, truncatedAlerts: 0 }关键字段速查字段含义receiver处理该通知的接收器名称与规则匹配到的路由 receiver 一致statusfiring已触发或resolved已恢复alerts[].labels该条告警的全部标签含规则 labels 与指标自身标签pool、set、server等alerts[].annotations规则里模板展开后的描述文本alerts[].startsAt/endsAt告警开始时间endsAt为0001-01-01T00:00:00Z表示尚未恢复alerts[].generatorURL指向 Prometheus 表达式页面的深链可直接回看查询表达式groupLabels/commonLabels该通知分组的分组键与全部告警共有的标签groupKey通知分组的唯一标识由group_by决定收到该报文即说明“Prometheus 计算规则 → AlertManager 路由/抑制 → Receiver 通知”整条链路已打通。告警恢复后 AlertManager 会再推送一条status: resolved的通知便于闭环跟踪。常见问题与排障要点Webhook 收不到告警先确认规则在 Prometheus Alerts 页是否已FiringPending不会推送再确认 AlertManager 路由的receiver名称与receivers定义严格一致并检查 webhook 服务本身是否可达、端口是否被防火墙拦截。抓取 401/403MinIO 的指标端点默认启用jwt鉴权Prometheus 抓取需携带mc admin prometheus generate生成的bearer_token若在开发环境临时放开可设置环境变量MINIO_PROMETHEUS_AUTH_TYPEpublic后重启 MinIO。详见 docs/metrics/prometheus/README.md。反代部署下的 Host 头Prometheus 抓取请求会携带Host: domain:port头。若 MinIO 位于 HAProxy、nginx 等反向代理/负载均衡之后需确保代理能把对该头域的请求正确路由到 MinIO 部署。关于server、pool、set标签annotations 模板中的可用标签取决于实际发出的指标标签与 Prometheus 追加的job/instance标签。示例报文中的标签来自真实分布式演练输出当前版本中擦除集健康指标按 cmd/metrics-v2.go 携带pool与set标签编写模板前建议先curl或mc admin prometheus metrics实测确认。进一步阅读告警规则文档本文主体docs/metrics/prometheus/alerts.mdPrometheus 抓取配置与鉴权方式docs/metrics/prometheus/README.mdMinIO 暴露的全部指标定义含本文涉及的 health 族指标docs/metrics/prometheus/list.md官方 Grafana 仪表盘其面板同样引用minio_cluster_health_erasure_set_status等指标docs/metrics/prometheus/grafana/minio-dashboard.json健康指标底层实现cmd/erasure-server-pool.goHealthResult与Health、cmd/metrics-v3-cluster-erasure-set.go容错值推导结合上述告警规则与仓库内的指标文档你可以在故障发生时就通过 Webhook/IM 收到精确到 pool/set 的定位信息从而在集群真正失去写入仲裁前完成扩容、换盘或网络修复。【免费下载链接】minioMinIO is a high-performance, S3 compatible object store, open sourced under GNU AGPLv3 license.项目地址: https://gitcode.com/GitHub_Trending/mi/minio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考