确认 13 个 Group 的 client ID、主机、Supervisor program 和期望在线数；补批量会话查询只读权限。
MQTT GOVERNANCE REVIEW · 2026-08-05
共享 MQTT 实例监控范围与配置审查建议
结论先行：实例属于全部智慧食堂项目共享；6 条金斯瑞业务规则保持不变，共享实例监控已通过 CLI 调整为 4 条平台规则并完成回读验收。
一页结论
第一阶段纠正已完成。 共享规则现已改为 7×24 平台告警；连接低阈值调整为 Warn 95 / Critical 80，并补齐连接、订阅和最大 QPS 的 70% / 85% 容量告警。
13共享 Group / Topic
6金斯瑞 Topic 规则
4全项目平台规则
0自动恢复 Webhook
保持不变
金斯瑞供餐时段无流量监控
早餐、午餐、晚餐窗口来自真实订单高峰，6 条规则仍只归金斯瑞项目层。
已实施
共享实例平台规则
已采用平台命名、平台联系人和 7×24 生效；仍需 client 台账、跌幅告警和 worker 探测补齐闭环。
CLI 生产变更与回读
| 规则 | 指标 | Warn | Critical | 结果 |
|---|---|---|---|---|
共享实例连接数过低 | 连接数 | <95 × 3 | <80 × 2 | 启用 / OK |
订阅容量过高 | 订阅数 | ≥105,000 × 3 | ≥127,500 × 2 | 启用 / OK |
连接容量过高 | 连接数 | ≥3,500 × 3 | ≥4,250 × 2 | 启用 / OK |
最大QPS容量过高 | 最大 QPS | ≥3,500 × 3 | ≥4,250 × 2 | 启用 / OK |
- 4 条平台规则均绑定共享实例
mqtt-cn-kd54j95ip01，生效时间为00:00–23:59，通知ZHCT-MQTT-PLATFORM-P0。 - 共同参数：60 秒统计/检测、600 秒沉默、无数据状态
INSUFFICIENT_DATA。 - CLI 回读为 10 条：6 条金斯瑞 Topic 规则未变，4 条平台实例规则全部启用且状态 OK。
- 两个历史规则保留旧
jsr-mqtt-*Rule ID，仅修正规则名、作用域和通知路由，以避免删除重建风险。
规则到底属于谁
| 规则层级 | 数量 | 真实资源维度 | 覆盖范围 | 审查结论 |
|---|---|---|---|---|
| 项目 Topic | 6 | topic=zhct_jsrGID_zhct_jsr@@@consume_work_0 | 金斯瑞 | 部分正确 需要核验是否覆盖双机全部 worker |
| 共享实例 | 4 | 仅实例 ID | 实例内全部项目 | 已纠正 平台命名、平台联系人、7×24 生效 |
控制台“规则数量 0”是 RocketMQ/Kafka 数据转发规则，不是监控报警。CLI 回读的云监控正式规则目前为 10 条且均已启用。
故障回放：为什么变更前阈值会漏报
| 指标 | 故障前 | 故障期 | 恢复后 | 当前条件 |
|---|---|---|---|---|
| 连接数 | 约 105 | 长期约 47–56 | 约 119–123 | Warn <50；Critical <30；仅 05:30–22:00 |
| 订阅数 | 约 210 | 84、121 后快速回到 300+ | 约 518–527 | Warn <180；Critical <100；连续 3 点 |
- 22:28 的故障处于当前通知窗口之外。
- 连接 55 代表大量 worker 已停，但仍高于 Warn 50。
- 订阅关系保留 1 天，client 离线后仍可能保留，不能充当实时在线数。
容量审查
| 容量项 | 上限 | 当前/24h 峰值 | 占用 | 结论 |
|---|---|---|---|---|
| 客户端连接 | 5,000 | 约 123 | 约 2.5% | 余量充足 |
| 订阅关系 | 150,000 | 约 527 | 约 0.35% | 余量充足，观察 1 天后回落 |
| 平均 QPS | 5,000 | 约 859 | 约 17.2% | 余量充足 |
| 最大 QPS | 5,000 | 约 1,341 | 约 26.8% | 余量充足 |
当前不需要扩容。更重要的是监控真实 worker 在线数、消息方向和自愈闭环。
已实施与后续顺序
DONE
纠正共享规则作用域。 已改为
ZHCT-MQTT-PLATFORM-*、平台联系人、7×24 生效；金斯瑞 6 条规则继续留在项目层。DONE
重做连接绝对阈值。 已落 Warn <95 连续 3 分钟、Critical <80 连续 2 分钟；最终仍需以 client 台账持续校准。
P1
补相对跌幅。 增加 5 分钟下降 15% / 2 分钟下降 25% 的跌幅或智能阈值规则，降低共享实例局部大面积掉线漏报风险。
P0
补 worker 级探测。 每分钟同时核对 Supervisor/真实进程数与云端 client 在线状态，连续 2 次异常生成同一事件。
P1
重定义订阅数。 订阅数主要做容量和漂移监控，70%/85% 告警；低订阅只作为配置丢失辅助证据。
P1
事件订阅负责升级。 10 分钟沉默期只是抑制重复通知，不是 5 分钟升级。初次 Critical 立即通知主值班，5 分钟未恢复扩大到三人，15 分钟升级负责人并创建工单。
P2
治理补齐。 增加 env/owner/service/criticality 标签、30/15/7 天续费复核、开发与生产隔离评估，以及 70%/85% 容量告警。
推荐三层模型
平台实例层
服务状态、总连接、QPS、容量、证书和到期。7×24 通知平台值班。
项目业务层
每项目 Topic 的请求进入和 worker 投递，按真实营业窗口通知项目负责人。
worker 执行层
Supervisor、真实进程、client 在线和重连次数；定向自愈，禁止 restart all。
升级控制层
事件订阅做合并、降噪、5/15 分钟升级；Webhook/函数计算做受限自愈。
人工评审清单
批准定向自愈的白名单、幂等、重试、冷却、审计和停止条件。
确认各项目营业时段、Topic 消息方向、无流量容忍时间和联系人组。
停止规则：在 client 台账和项目责任人未确认前，不批量复制 Topic 规则，不声称全部项目业务监控或自动恢复已经闭环。