健康检查与监控
用三个地址判断进程是否存活、节点能否接流量，以及问题发生在哪里。
判断 WuKongIM 是否正常时，先检查 /readyz，再看监控。不要只看“进程还在不在”。
先运行这三个命令
curl -sS -i http://127.0.0.1:5001/healthz
curl -sS -i http://127.0.0.1:5001/readyz
curl -sS http://127.0.0.1:5001/metrics把 127.0.0.1:5001 换成节点真实的 API 地址。如果没有开启 Prometheus 指标，第三个地址可能不可用。
| 地址 | 它回答的问题 | 正确用法 |
|---|---|---|
/healthz | WuKongIM 进程还活着吗？ | 用于进程存活检查和自动重启 |
/readyz | 这个节点现在能接收业务流量吗？ | 用于负载均衡、发布和恢复流量 |
/metrics | 最近的错误、延迟、队列和资源有什么变化？ | 由 Prometheus 采集，用于图表和告警 |
最容易记住的规则是：/healthz 成功只代表进程活着；只有 /readyz 成功才代表节点可以接业务流量。 /readyz 失败时会返回 HTTP 503，并在响应中说明原因，请把完整响应保存下来。
维护期间进程可能存活，但业务仍不可用
数据恢复等维护操作期间，/healthz、监控和诊断接口仍可能正常，/readyz 则会保持失败。不要因为进程存活就提前恢复业务流量。
最少需要监控什么
刚开始可以先覆盖下面四组，不必一次做出很复杂的仪表盘。
| 监控组 | 关注内容 | 常见问题 |
|---|---|---|
| 流量与连接 | 连接数、发送错误、请求量、延迟、重连 | 用户连不上或消息变慢 |
| 队列与投递 | 队列长度、拒绝、丢弃、重试、Webhook/插件失败 | 消息积压或下游收不到 |
| 集群状态 | Controller、Slot Leader、副本、ISR 和任务 | 节点就绪但集群状态异常 |
| 机器资源 | CPU、内存、Goroutine、文件句柄、磁盘和网络 | 资源耗尽导致服务不稳定 |
Manager 的“实时监控”和 Top 适合快速查看当前节点；Prometheus 适合看一段时间内的趋势。它们互相补充，不能替代 /readyz。
先设置这些告警
/readyz持续返回 503，或者状态频繁变化；- 发送错误或延迟持续上升；
- 队列持续增长，出现拒绝、丢弃或投递失败；
- 磁盘剩余空间不足，或内存、文件句柄、Goroutine 持续增长；
- Controller、Slot Leader、副本或 ISR 状态异常；
- 监控采集中断，导致无法判断集群状态。
不要直接照搬别人的告警数值。先观察当前版本在真实业务高峰时的正常范围，再设置阈值。大群、高消息率和大量连接容易产生单节点或单频道热点，因此还要看最大值和高分位延迟，不能只看平均值。
告警出现后怎么做
- 记录开始时间、影响范围和
/readyz完整响应。 - 对齐同一时间段的指标、Manager 状态和错误日志。
- 如果仍无法解释，再按故障排查逐步使用 Top、诊断或 pprof。
监控开关与日志配置见日志与可观测性。不要让告警自动执行 Leader 迁移、删除节点或其他拓扑变更。