雷火UX | GDC2022演讲实录：多人在线游戏中的实时异常监测

GDC 2022

今年3月21日至3月25日，全球游戏行业最具规模、最有权威、最有影响力的专业峰会GDC2022在旧金山莫斯康中心盛大召开。本届GDC中，雷火UX共获邀17场演讲，分布在9个核心演讲以及8个峰会演讲，再度刷新中国游戏行业纪录，领跑全球。

接下来雷火UX公众号将陆续为大家进行介绍。本篇为大家介绍的是来自雷火UX数据业务负责人Chalet的演讲——“多人在线游戏中的实时异常监测”，以下是演讲实录。

实时异常监控的概念和意义

在网络游戏中，当游戏出现异常后，同时又没有及时被监控和排查出来，意味着将面临玩家流失的风险和经济收益的损失。为了理解实时异常监控，首先我们需要科学的定义“异常”，所谓“异常”，通常被理解为对罕见事件或观察结果的识别，这些事件或观察结果明显偏离大多数数据，并且不符合正常行为的明确定义。在所有的异常监测中，时序数据的异常监测是最具有普遍意义的，是因为时序数据往往存在一定的规律性，偏离基线的行为很容易被检测出来。

但是，如果对于时序数据，我们监测到异常的时间距离发生的时间滞后很久，那么此时游戏已经产生了巨大的损失，实时的异常监控变得十分必要。在和《永劫无间》的开发团队合作时，为了解决产品方对于游戏内帧率变化（尤其是版本更新之后）的异常监控需求，我们开发了一个实时的游戏内战斗场景下的帧率变化对比，可以及时监测到游戏内玩家的帧率波动，为线上及时排查和调整性能问题提供了决策支持。

实时异常监控的开发实践

在数据开发中，为了监测异常发生的环节，首先需要理解整个的数据链路，从游戏服务器到消息队列，经过实时数据处理后，最终在报表层面显示出来。当进行异常监测的时候，我们需要把整个链路调转过来，从报表的结果出发，反向推理发生问题的环节，在整条链路里面，消息队列这个节点尤为重要，它连接了上游的数据生产和下游的数据处理和数据显示。因此，通过监测消息队列这个节点，能够分析出整个异常的节点是发生在上游还是下游节点。

消息队列连接了数据生产和数据消费。如果把生产和消费拆开，一共存在4种情况（生产消费和正常异常），组合成一个四象限图。其中，生产正常和消费正常的曲线图可以作为判定下游异常的指标，这个曲线图的特点则是生产保持平稳，而消费曲线骤降，两者在趋势上有明显的差异。

作为对比，生产异常和消费正常的曲线图则可以作为判定上游异常的指标，这个曲线图的特点是生产和消费的曲线基本同步，而且最终均趋向于零这条水平线。但是，在实践中还会遇到一个棘手的问题，在当前的语境中，上游异常是无法区分出是游戏服务本身的异常，还是游戏数据传输到消息队列中发生了异常。

因此，为了区分出是游戏服务的异常还是数据系统的异常，整个监控的流程图最终设计成如下所示。首先从报表系统上面发现了数字上的异常，然后去排查消息队列的数据生产一测，是否在数据生产曲线上有明显的异样。如果没有，则接着去排查下游任务。反之，则重点搜索游戏服务异常的证据，无论是从游戏官方的公告或者游戏运维团队提供的心跳机制，亦或者通过社区内容的监控，来确认游戏是否出现服务异常。如果没有任何证据表明游戏服务出现异常，则是数据系统的异常。

当排查数据系统异常时，如果遇到消息队列的生产和消费都是正常的情况，此时消息队列的监控就显得比较粗糙了，无法提供精确的信息来支持决策，需要使用更精细的分析手段，比如OLAP数据库（如Apache Kudu）。当在业务系统中引入OLAP数据库，前面的数据链路也要重新调整。数据从游戏服务器传输到消息队列后，不再进入数据处理系统和报表系统，而是直接写入OLAP数据库，后续的分析工作完全基于实时的OLAP数据库进行。在实践中，我们曾使用这套系统排查一次异常的玩家在线曲线波动，在分析消息队列的生产消费曲线时，发现生产消费曲线完全正常，无法提供任何有价值的信息。为了解决这个问题，我们将登录和在线曲线数据实时写入OLAP数据库，最后发现玩家的登录数据完全无法支持在线曲线的异常波动，判定为一次异常的数据记录。

总结

本次分享从基础架构的角度剖析异常发生的各个环节，如何从现象分析背后的原因，以及为此设计相应的数据实时链路，可以为数据开发者和技术研发人员提供一种问题排查的思路。但是，我们后续的工作将不止于此，要利用我们多年的游戏大数据开发的经验，针对不同类型的游戏，设计合理的实时业务指标，对游戏进行实时的异常监控，可以尽早发现游戏中的异常现象，可以在问题发酵之前为游戏挽回大量的损失。