运维与监控

运维的日常节奏

对象存储的特点是「平时没动静，出事就是大事」。日常运维要做的事情不多，但必须固定下来：

频率	检查项	手段	判断标准
每天	节点与磁盘在线状态	mc admin info	全部 online，无 offline 盘
每天	容量水位	mc admin info / 监控面板	使用率低于 70%
每天	请求错误率	Prometheus	5xx 占比低于 1%
每周	heal 进度与残留	mc admin heal --dry-run	无待修复对象
每周	证书到期时间	openssl s_client / 监控	剩余 30 天以上
每月	备份可用性	mc diff / 试恢复	两端一致，能拉回文件
每季度	版本与安全更新	官方 release notes	评估是否升级

巡检脚本化

把这些检查写成一个 mc + jq 的脚本，输出「异常项」而不是全部信息，接到 cron 或 CI 里。天天手工跑 mc admin info 看几十行输出，人一定会麻木，最后漏看关键行。

集群巡检

mc admin info 怎么看

mc admin info 是最重要的单条命令，集群概况、节点、磁盘、容量一次性看完：

mc admin info cluster

重点看四块：

• Servers：多少 online、多少 offline。offline 的节点名会直接列出来。
• Drives：每节点的盘数与状态。16 drives online, 0 drives offline 是健康态。
• Usage：已用容量和对象数，注意它是纠删码之后的可用容量口径，不是原始盘容量。
• Uptime：有没有意外重启。uptime 很短说明进程刚崩过，去翻日志。

结构化处理更方便接监控：

# 取每个节点的在线状态
mc admin info cluster --json | jq -r '.info.servers[] | "\(.endpoint) \(.state)"'

# 取容量使用率
mc admin info cluster --json | jq -r '"\(.info.usage.size) / \(.info.usage.size + .info.usage.available)"'

字段名在不同版本间略有出入，写脚本前先 mc admin info cluster --json | jq keys 看一眼实际结构，别照抄。

其他巡检命令

# 看当前正在进行的锁与后台任务
mc admin top locks cluster
mc admin top api cluster

# 实时跟踪 S3 请求（排障时看客户端到底在调什么）
mc admin trace -v cluster
mc admin trace -v --status-code 403 cluster

# 看扫描器（scanner，负责后台校验和触发 heal）状态
mc admin scanner status cluster

# 看服务端配置项（确认存储类、认证方式等）
mc admin config get cluster

mc admin trace 输出量很大，只在排障时短时间开，别挂在后台不管——它会显著增加服务端负载。

故障修复：heal

MinIO 的修复分两条路：自动和手动。

自动修复由后台扫描器完成。磁盘重新上线后，扫描器会发现分片缺失或校验失败，用其他分片重建并回写，全程不需要人工介入。代价是慢——扫描器按周期分片扫描，几 TB 的数据可能要跑几小时到几天。

手动触发用于换盘、加盘之后催一把：

# 先干跑，看要修多少对象，不实际写
mc admin heal --dry-run --recursive cluster

# 全集群递归修复（最重，慎用）
mc admin heal --recursive cluster

# 只修某个桶 / 某个前缀
mc admin heal --recursive cluster/photos
mc admin heal --recursive cluster/photos/2024

# 深度扫描：连元数据一起校验，比默认慢很多但更彻底
mc admin heal --recursive --scan-mode deep cluster

执行过程中它会持续刷新进度（已修复对象数、失败数）。修复期间集群是可读写的，但会占用大量磁盘 I/O 和网络带宽，建议放在业务低峰期，并且一次只修一个桶，别上来就全集群递归。

heal 不是万能的

heal 只能修「还有足够分片能重建」的对象。如果某个纠删码集合坏盘数超过校验值，那些对象已经无法重建，heal 会报失败——这时候只能从备份恢复（mc mirror 回灌或站点复制重同步）。所以监控坏盘数量比监控 heal 进度更重要。

Prometheus 监控

指标端点

MinIO 内置 Prometheus 格式的指标端点，不需要额外 Exporter：

端点	内容	适用场景
/minio/v2/metrics/cluster	集群级：容量、节点、磁盘、S3 请求	主监控，必采
/minio/v2/metrics/node	单节点：进程、磁盘、网络	节点级排障
/minio/v2/metrics/bucket	桶级：用量、对象数、请求	多租户/按桶计费，注意基数
/minio/v2/metrics/resource	进程资源：CPU、内存、GC	性能分析

认证方式

默认指标端点要认证，两种做法：

# 方式一：让 mc 生成一段带 JWT 的抓取配置，直接粘到 prometheus.yml
mc admin prometheus generate cluster

# 方式二：把指标端点设为公开（仅限内网，且前面有网络隔离）
# 在 /etc/default/minio 里加：
# MINIO_PROMETHEUS_AUTH_TYPE=public

别把指标端点公开到公网

指标里包含桶名、对象数、节点地址等拓扑信息，公开等于给攻击者做侦察。要么用 JWT 认证，要么只监听内网地址、由 Prometheus 在内网抓。

抓取配置

scrape_configs:
  - job_name: minio-cluster
    metrics_path: /minio/v2/metrics/cluster
    scheme: https
    bearer_token_file: /etc/prometheus/minio-token.jwt
    static_configs:
      - targets:
          - minio1.example.net:9000
          - minio2.example.net:9000
          - minio3.example.net:9000
          - minio4.example.net:9000
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

TLS 用内部 CA 时，记得给 Prometheus 配上 ca_file，否则抓取会报证书错误。Prometheus 的抓取模型、标签体系和存储机制见 Prometheus 核心概念与架构。

关键指标与查询

指标名在不同版本间有微调，落地前先 curl 一次端点确认，下面这些是长期稳定的核心项：

指标	含义
minio_cluster_capacity_usable_total_bytes	纠删码后可用总容量
minio_cluster_capacity_usable_free_bytes	纠删码后剩余可用容量
minio_cluster_nodes_online_total	在线节点数
minio_cluster_drive_offline_total	离线磁盘数（最重要）
minio_s3_requests_total	S3 请求总数
minio_s3_requests_errors_total	错误请求数
minio_s3_traffic_sent_bytes	出口流量
minio_bucket_usage_total_bytes	桶用量（开 bucket 端点才有）

几条日常查询：

# 容量使用率
1 - (sum(minio_cluster_capacity_usable_free_bytes) / sum(minio_cluster_capacity_usable_total_bytes))

# 离线磁盘数（大于 0 就该看告警了）
sum(minio_cluster_drive_offline_total)

# S3 错误率
sum(rate(minio_s3_requests_errors_total[5m])) / sum(rate(minio_s3_requests_total[5m]))

# 出口带宽（MB/s）
sum(rate(minio_s3_traffic_sent_bytes[5m])) / 1024 / 1024

告警建议

按「会导致数据丢失」和「会影响可用性」两个优先级来配：

• P0：minio_cluster_drive_offline_total > 0；离线磁盘数达到校验值（默认 4）时立刻升级告警，这时已经零冗余。
• P0：minio_cluster_nodes_online_total 小于预期节点数——节点掉线意味着每个集合都少了一块盘。
• P1：可用容量使用率超过 70%（预警）、超过 85%（紧急）。MinIO 在磁盘使用率接近 99% 时会拒绝写入，别等到那时候。
• P1：S3 错误率持续超过 1%，或 503 SlowDown 突增。
• P2：证书剩余有效期低于 30 天。

Grafana 面板

Grafana 官方仓库里有现成的 MinIO 面板（Dashboard ID 13502），导入后选好 Prometheus 数据源即可。面板一般分四块：集群总览、节点与磁盘状态、S3 请求与流量、容量趋势。

自建面板时注意两个坑：桶级指标基数和桶数量成正比，桶多了别全量展示；容量类指标是 Gauge，别用 rate() 去算。

容量治理

桶用量与对象数

# 各桶用量（真遍历，慢）
mc du cluster

# 只统计某个桶的前两层前缀
mc du --depth 2 cluster/photos

# 统计对象数量
mc ls --recursive --json cluster/photos | jq -s 'length'

# 看单个对象的大小与元数据
mc stat cluster/photos/2024/logo.png

对象数太多（千万级以上）时，mc du 和 mc ls --recursive 会非常慢，甚至拖慢集群。这类环境应该依赖 minio_bucket_usage_total_bytes 指标，而不是客户端遍历。

配额

给业务桶设硬上限，防止某个服务把整个集群写满：

mc quota set cluster/logs --size 500GiB
mc quota info cluster/logs
mc quota clear cluster/logs

配额是桶级的，到达上限后写入直接失败。好处是故障隔离——一个桶写爆不会拖垮全集群；坏处是业务方可能没感知，半夜报警才发现写不进去。设配额的同时要把「桶使用率」也配上告警。

清理策略

容量增长的来源通常只有三个，对症下药：

• 历史版本堆积：开了版本控制的桶，每次覆盖都留一份。用 mc ilm rule add --noncurrent-expire-days 30 定期清非当前版本。
• 临时文件和日志：按前缀配过期规则，--prefix "tmp/" --expire-days 7，别用客户端脚本删。
• 删除标记堆积：--expire-delete-marker 让服务端顺手清掉。

容量告警要提前

对象存储的删除是懒执行的，生命周期规则也是异步的，从「决定清理」到「容量真正下降」可能隔一天。所以容量告警水位不能设太高，70% 预警、85% 紧急比较稳妥，留出处置时间。

备份策略

纠删码防的是磁盘和节点故障，防不了误删、勒索软件和整个站点故障。这两类风险要靠备份：

方式	机制	适合场景	恢复粒度
桶复制	mc replicate add 实时同步到远端	同城双活、低 RPO	桶/对象
站点复制	多站点互相复制	异地容灾	站点
mc mirror	定时增量同步	低成本冷备、跨云备份	桶/对象
配置导出	mc admin cluster bucket export / iam export	元数据快照	桶策略、IAM

最朴素也最常用的方案是异地 mc mirror：

# 每天凌晨增量同步到备用集群（只增不删，防误删扩散）
mc mirror --overwrite cluster/photos backup/photos

# 低延迟场景用 --watch 常驻
mc mirror --watch --overwrite cluster/photos backup/photos

# 同步完校验两端差异，输出为空才算成功
mc diff cluster/photos backup/photos

备份必须演练恢复

没演练过的备份等于没有备份。定期从备份集群拉一个真实文件回来，确认能打开、大小对得上；配置类备份（IAM、桶策略）也要试导入一次。只跑 mirror 看它不报错，不叫验证。

小结

• 巡检固定成节奏：每天看节点/磁盘/容量/错误率，每周看 heal 与证书，每月验证备份，脚本化输出异常项。
• mc admin info 是核心命令，重点看 Servers、Drives、Usage、Uptime 四块；--json 配 jq 接监控。
• heal 自动跑在后台，换盘后可以手动催；heal 只能修还有足够分片的对象，坏盘数超过校验值就只能靠备份。
• 指标端点在 /minio/v2/metrics/，默认要 JWT 认证；核心告警是离线磁盘数和容量水位。
• 容量治理三招：配额隔离、非当前版本过期、前缀级生命周期；删除是异步的，告警水位要留余量。
• 纠删码不等于备份，异地 mirror 或桶复制才是防误删和站点级故障的手段，且必须演练恢复。

真出故障时怎么判断、怎么处置，下一篇《故障排查与最佳实践》按场景拆解。