前四篇介绍了不同场景的监控方案：

这篇最短，因为 MinIO 自带 Prometheus 端点，不需要额外 exporter，也不需要日志采集。

MinIO 内置 metrics 链接到标题

MinIO 在 API 端口（:9000）上暴露了 Prometheus 兼容的指标端点：

/minio/v2/metrics/cluster  — 集群级别指标
/minio/v2/metrics/node     — 单节点级别指标

单机部署下两个端点返回的指标基本一致，选一个即可。

默认需要认证，直接访问会返回 AccessDenied。需要在 MinIO 环境变量中开放：

MINIO_PROMETHEUS_AUTH_TYPE=public

public 仅影响 metrics 端点，不影响 MinIO Console（:9001）的管理功能和 S3 API 的访问控制。

配置步骤 链接到标题

1. 开启 metrics 链接到标题

找到 MinIO 的 docker-compose 部署目录，在 .env 文件中追加：

echo 'MINIO_PROMETHEUS_AUTH_TYPE=public' >> .env

然后重新创建容器（restart 不会重新读取环境变量）：

docker compose down && docker compose up -d

验证 metrics 已开放：

curl -s http://localhost:9000/minio/v2/metrics/cluster | head -5

# HELP minio_audit_failed_messages Total number of messages that failed to send since start
# TYPE minio_audit_failed_messages counter
minio_audit_failed_messages{server="127.0.0.1:9000",target_id="..."} 0

2. Prometheus 添加 scrape target 链接到标题

在 prometheus.yml 中新增一个 job：

- job_name: minio
  metrics_path: /minio/v2/metrics/cluster
  static_configs:
    - targets:
        - minio-host:9000
      labels:
        hostname: minio-host

注意 metrics_path 不是默认的 /metrics，需要显式指定为 /minio/v2/metrics/cluster。

重启 Prometheus 后确认 target 状态：

curl -s 'http://localhost:9090/api/v1/targets' | grep minio

关键指标 链接到标题

指标 含义 用途
minio_cluster_capacity_usable_total_bytes 可用总容量 用于计算使用率
minio_cluster_capacity_usable_free_bytes 剩余可用容量 用于计算使用率
minio_cluster_usage_total_bytes 已用容量 直接反映存储占用
minio_cluster_drive_online_total 在线磁盘数 健康检查
minio_cluster_drive_offline_total 离线磁盘数 异常检测
minio_cluster_drive_total 总磁盘数 参考基数

使用率计算公式：

(1 - minio_cluster_capacity_usable_free_bytes / minio_cluster_capacity_usable_total_bytes) * 100

告警规则 链接到标题

在 Prometheus alert rules 中新增一个 group：

- name: minio_alerts
  interval: 30s
  rules:
    - alert: MinIODiskOffline
      expr: minio_cluster_drive_offline_total > 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "MinIO 磁盘离线"
        description: "主机 {{ $labels.hostname }} MinIO 有磁盘离线"

    - alert: MinIOStorageUsage
      expr: (1 - minio_cluster_capacity_usable_free_bytes / minio_cluster_capacity_usable_total_bytes) * 100 > 85
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "MinIO 存储使用率超过 85%"
        description: "主机 {{ $labels.hostname }} 当前使用率: {{ $value | printf \"%.1f\" }}%"

    - alert: MinIOCriticalStorage
      expr: (1 - minio_cluster_capacity_usable_free_bytes / minio_cluster_capacity_usable_total_bytes) * 100 > 93
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "MinIO 存储即将耗尽"
        description: "主机 {{ $labels.hostname }} 当前使用率: {{ $value | printf \"%.1f\" }}%"

这些告警会汇入部署 Alertmanager 已有的通知链路，通过 alert-transformer 转发到飞书。

与其他监控的对比 链接到标题

服务 日志告警 指标告警 原因
CouchDB ✅ Alloy + Loki ✅ couchdb-exporter Erlang 内部错误指标不可见
Windmill ✅ Alloy + Loki ❌ 无指标 错误体现在日志里
MinIO ❌ 不需要 ✅ 内置 metrics 关键问题（容量、磁盘）指标全覆盖
其他基础设施 — ✅ node-exporter CPU、内存、磁盘等标准指标

对于对象存储来说，“磁盘满了"和"磁盘挂了"是优先级最高的问题——这两项 MinIO 的内置指标已经全覆盖。S3 API 层面的错误（如认证失败、权限不足）会由调用方（如 Windmill）直接感知，不需要单独从 MinIO 侧告警。

总结 链接到标题

MinIO 的内置 Prometheus 端点是一等公民功能：

  • 配置只需一行环境变量 + 一个 Prometheus job
  • 不需要额外的 exporter
  • 不需要日志级别的告警
  • 直接复用已有的 Alertmanager 通知链路

这篇文章是系列中最短的，因为 MinIO 本身简单。对比前面的 CouchDB 和 Windmill，可以看到不同服务适合不同的监控策略——有些需要日志、有些只需要指标，取决于服务暴露了什么、我们关心什么。