🔵 WebSocket 画布协作：神经系统

场景 1 · 用户反馈“画布协作不同步，我画了他看不见”

典型的“广播失明”投诉。别急着重启，三步定位：先确认是不是广播线断了，再确认是单机问题还是 Redis 整体不稳，最后查广播池有没有被打满。

# 第 1 步：先看是不是“广播失明”（跨机器协作断）
sum(rate(siliang_ws_errors_total{error_type="redis_pubsub"}[5m]))
  # > 0 即实锤：Redis pubsub 广播线出问题，两台机器各自为政

# 第 2 步：按 instance 拆——单机失明还是 Redis 整体抖？
sum(rate(siliang_ws_errors_total{error_type="redis_pubsub"}[5m])) by (instance)
  # 只有一台机器报 = 那台的 pubsub 订阅断了
  # 两台都报 = Redis 本身在抖，去查 Redis 健康

# 第 3 步：看广播专用池是不是被打满（内存盘）
max_over_time(siliang_redis_pool_connections{state="in_use", pool="broadcaster_pubsub"}[1m])
  # 贴着 capacity = 广播借不到连接，消息发不出（对照 m117 使用率卡）

判读：redis_pubsub 回到 0 且发送 QPS（c25）恢复与接收同步起伏，才算修好。

场景 2 · 深夜告警：WS 活跃连接数爬升不回落（怀疑僵尸）

连接数只涨不跌有两种可能：真热闹，或全是尸体。用“僵尸三联证”分辨：心跳、时长 P99、teardown 错误。

# 1) 确认形态：曲线是不是只涨不跌
sum(siliang_ws_connections_active{job="siliang_backend_worker"})

# 2) 三联证之一：心跳还有没有（活人才发心跳）
sum(rate(siliang_ws_heartbeat_messages_total[5m]))
  # 连接在涨而心跳平平 = 新连接是真、旧连接是尸

# 3) 三联证之二：时长 P99 是不是异常长
histogram_quantile(0.99, sum(rate(siliang_ws_connection_duration_seconds_bucket[5m])) by (le))
  # P99 拉长 = teardown 清理没触发，“该死的没死”

# 4) 幽灵旁证：teardown_step 错误速率
sum(rate(siliang_ws_errors_total{error_type="teardown_step"}[5m]))
  # > 0 = Redis 故障正在制造幽灵 session（人走了登记还在）

场景 3 · 一堆用户突然连不上画布（握手被拒）

“连不上”不是一种病，是四种。按 outcome 拆开，每种拒绝指向完全不同的病灶和负责人。

# 按 outcome 拆开看是哪道门在拦人
sum(rate(siliang_ws_connections_total[5m])) by (outcome)
  # 鉴权失败高 = token 过期/签发问题（前端或网关侧）
  # 超限高   = 撞连接数上限：先看 c20 是不是泄漏把名额占满
  # Origin 高 = 跨域配置问题（多半伴随发布/域名变更）

# 怀疑“超限”时的快速验证：对照活跃连接数绝对值
sum(siliang_ws_connections_active{job="siliang_backend_worker"})
  # 若同时贴高位 → 大概率是泄漏占满名额，而不是真有那么多人
  # 再用心跳 QPS 验水分：心跳没涨 = 名额被尸体占着

场景 4 · 发布后确认 WS 平滑切换

滚动发布时每个旧 worker 要把连接干净地交出去。逐 instance 看连接排空，发布后才算真正收工。

# 滚动发布时逐 worker 看：旧 instance 连接应依次排空归零
sum(siliang_ws_connections_active{job="siliang_backend_worker"}) by (instance)
  # 每个旧 instance 依次跌到 0 = 干净退场
  # 卡在半空不归零 = 排空卡住（对照 HTTP 并发 c18 的 ops 排空口径）

# 发布后协作功能回归：收发两条线应恢复同起伏
sum(rate(siliang_ws_messages_received_total[5m])) by (type)
sum(rate(siliang_ws_messages_sent_total[5m])) by (type)
  # 有进有出 = 广播链路健康；发送归零 = pubsub 没接好

场景 5 · 给 WS 僵尸连接加一条防回退告警

僵尸连接靠人盯图发现不了早期形态。用“连接爬升 + 心跳不涨”的组合条件做告警，让它在堆积早期就叫。

# 告警：连接斜率向上 且 心跳没有同步增长 = 疑似僵尸堆积
#（示例规则，阈值按业务节奏校准后启用）
- alert: SiliangWSZombieSuspicion
  expr: |
    deriv(sum(siliang_ws_connections_active{job="siliang_backend_worker"})[1h:5m]) > 0
    and
    sum(rate(siliang_ws_heartbeat_messages_total[5m]))
      < sum(rate(siliang_ws_heartbeat_messages_total[5m] offset 1h))
  for: 15m
  labels:
    severity: warning
  annotations:
    summary: "WS 连接爬升但心跳未同步：疑似僵尸连接堆积，查 c23 P99 与 teardown_step"

判读：告警触发后先看 c23 的 P99——它拉长就是清理逻辑没跑，再看 c22 teardown_step 找 Redis 故障的痕迹。