Sentinel 规则生效而控制台实时监控为空，不一定是规则下发失败。限流在应用侧执行，指标展示还依赖控制台访问应用的监控 API；两条路径可以独立出问题。

当时发现了不可达的本地实例

2019 年应用部署在 Kubernetes 后，限流有效，指标却不显示。控制台 MetricFetcher 拉取 /metric 出现网络超时。实例列表中还有使用相同应用名注册的本地开发进程，而集群控制台无法访问本机地址。

当时停止本地进程，待不可达实例退出列表并重新产生请求后，监控恢复。这是该环境的处理结果，不等于任何版本中“一台坏实例必然拖空所有应用”。

注册成功不代表反向访问成功

应用 → Dashboard：注册、心跳
Dashboard → 应用监控 API：指标拉取、管理请求

应用能访问 Dashboard 只证明第一条方向可达。控制台使用的是实例登记的地址和监控端口，未必是业务接口暴露的 Service 地址。

客户端监控 API 默认从 8719 使用端口，具体以实例登记值为准。首次资源访问会触发初始化，没有流量不一定立即产生可观察指标。Sentinel 控制台

按具体实例核对链路

先确认应用名、实例 IP、监控端口及存活状态，再从控制台所在网络检查可达性。Kubernetes 中继续核对 Pod 网络、路由、NetworkPolicy，以及是否误登记了本机网卡、容器内部或旧实例地址。

监控 API 属于管理面，不应为了出图直接开放到公网；业务 Service 可达也不意味着管理面应同样公开。

最后用少量可控业务请求产生访问，对照同一实例的拉取日志。若仍为空，再查适配依赖、统计资源、时间窗口与版本。规则持久化、限流和监控是三件事，不能互相代替验收。