cerebro仅实时拉取并可视化_cluster/health结果，不主动监控；集群status为green/yellow/red由该api的status字段决定，直接显示在概览页顶部，yellow常见于单节点或磁盘超85%。
Cerebro 本身不主动“监控”健康状态，它只是实时拉取并可视化 _cluster/health API 的结果；真正的监控需靠外部告警系统或定时轮询，Cerebro 只负责“看”和“点”。
怎么看集群 status 字段是否为 green/yellow/red
Cerebro 启动后默认进入集群概览页（/overview），顶部大号字体直接显示当前集群的 status 值，颜色与 favicon 一致：绿色背景表示 green，黄色背景是 yellow，红色背景即 red。这个值来自 Elasticsearch 的 _cluster/health?level=cluster 接口响应中的 status 字段。
注意：yellow 不代表故障，而是副本分片未分配完——常见于单节点集群（没地方放副本）、磁盘使用率超 85%（ES 自动禁用分片分配）、或刚创建索引时副本还在初始化。不要一见 yellow 就 panic。
- 单节点部署必 yellow：副本无法分配，改配置
index.number_of_replicas: 0或加节点 - 磁盘 >85% 会触发
unassigned_shards暴增，Cerebro 里能看到“未分配分片”数字跳红 -
relocating_shards长时间非 0，说明分片正在迁移，可能拖慢查询，Cerebro 的分片分布图能直观看到迁移箭头
为什么 Cerebro 显示 green 但实际写入失败
因为 Cerebro 只查 _cluster/health，不检查索引级可用性或写入权限。常见脱节场景：
- 集群 green，但某个索引被
close了 → 写入该索引会返回400 Bad Request，Cerebro 的索引列表页里该索引状态显示为 “closed” - 集群 green，但设置了只读块（
blocks.read_only_allow_delete）→ 写入报403 Forbidden，Cerebro 的“集群设置”页能查到blocks.相关配置项 - 集群 green，但某个节点 JVM 内存使用率 98% → Cerebro 节点列表页的堆内存条会变红，但
_cluster/health仍可能 green
所以不能只盯 status，要配合看“节点统计”里的 jvm.mem.heap_used_percent 和“磁盘使用率”，这两项在 Cerebro 概览页的节点表格里都直接显示数字和色块。
如何让 Cerebro 自动刷新健康状态而不手动点刷新
Cerebro 默认不自动轮询，必须手动点击右上角的 Refresh 按钮（或按 R 键）。没有内置的 auto-refresh 开关，这是设计使然——避免对 ES 造成无谓压力。
如果真需要近实时刷新，有且仅有两个办法：
- 浏览器插件：装一个支持页面自动重载的扩展（如 “Auto Refresh Plus”），设 10–30 秒间隔，但会强制整页刷新，体验割裂
- 改源码：修改
public/overview.html中的 JS，加setInterval(() => location.reload(), 15000)，但每次升级 Cerebro 都得重打补丁
更合理的做法是：把 Cerebro 当作“诊断界面”，真正做监控告警请用 Prometheus + Elasticsearch Exporter + Alertmanager，Cerebro 只用来点进去查原因。
从 Cerebro 界面快速定位 unassigned_shards 根本原因
当 Cerebro 显示 unassigned_shards > 0 时，别急着点“重新路由”，先看三处：
- 顶部状态栏右侧的
unassigned_shards数字，点击它会跳转到分片页，筛选出所有UNASSIGNED状态分片 - 分片页中每行末尾的
reason列，常见值有：ALLOCATION_FAILED、CLUSTER_RECOVERED、INDEX_CREATED、NO_VALID_SHARD_COPY - 对应节点的磁盘使用率是否 ≥85%？在节点列表页一眼可见；若是，去 ES 配置里调高
cluster.routing.allocation.disk.watermark.flood_stage或清理磁盘
特别注意 NO_VALID_SHARD_COPY：说明该分片所有副本（包括主分片）都丢失了，Cerebro 无法恢复，只能删索引重建或从快照还原——而快照状态得去 /snapshots 页确认。
