游戏服务端可观测：在线人数、延迟与卡顿根因定位

游戏服要盯的指标跟普通业务不一样

Web 服务看 QPS、延迟、错误率就够了，游戏服还得盯在线人数（CCU）、帧同步延迟、掉线率、卡顿率，以及分区分服的负载分布。这些指标和"玩家体验"直接挂钩：CCU 突然掉一截，可能是某个大区服务器崩了；帧延迟飙高，可能是某个房间的网关扛不住。

建议按三个层面建指标：基础设施层（CPU/内存/磁盘/网络）、服务层（登录、匹配、战斗、支付各模块的延迟与错误率）、体验层（在线人数、帧延迟、掉线率、卡顿上报数）。体验层最贴近玩家，也最容易被忽略。

用 trace 定位"卡顿"

玩家投诉"团战卡"，光看服务器 CPU 可能很正常。卡顿常常藏在链路里某一次调用：比如结算服务去数据库查了一笔慢 SQL，或者匹配服务调用第三方鉴权超时。用链路追踪可以做到：

1. 拿玩家的对局 ID 或 openid 搜 trace，找到那一局涉及的所有调用；
2. 按耗时排序，定位最慢的 span，点开看它调的下游和 SQL；
3. 把同类型的慢 span 聚合，看是不是集中在某个房间、某个服、某个时间段。

一个常见根因：网关对单个长连接的写缓冲没做背压，一个慢客户端拖垮整个房间。这类问题只有 trace + 日志上下文一起看才能定位。

开服高峰与封测的告警策略

游戏的特点是流量尖峰极陡：开服、版本更新、活动上线，几分钟内 CCU 从几千冲到几十万。告警策略要跟着变：

• 日常：按固定阈值告警，比如某个服 CPU > 85% 持续 5 分钟；
• 开服/活动：切换成"动态阈值 + 环比"，因为固定阈值会被峰值秒触发，误报一堆；
• 封测/压测：单独开一个静默窗口，避免测试数据污染线上告警。

另外要设"掉线率突增"这类体验告警，阈值设得很低（比如 5 分钟掉线率环比上涨 3 倍），因为掉线是玩家流失的直接信号，比 CPU 告警更该优先处理。

落地清单：先从哪几项开始

如果现在要上，建议按这个顺序：

1. 先接日志和指标，把 CCU、掉线率、分服负载三块看板做出来；
2. 再给登录、匹配、战斗、支付四个核心链路接 trace，保证用对局 ID 能查；
3. 最后配告警：日常固定阈值 + 活动动态阈值 + 掉线率突增；
4. 定期复盘：每次大版本或大活动后，用 trace 聚合看 Top 慢调用，排进下个迭代优化。

先保证"出问题能定位"，再追求"不出问题"。