前言

《XXXX》是北极光蜜獾工作室自主研发，以真实冷兵器搏杀体验为重心的竞技类对战网游。游戏融合了第三人称射击与动作游戏的元素，单局最高可支持70VS70共140人同时对战。游戏从2013年发布至今历经首测、天梯测、内测、军团测，迎来2016年7月不删档和8月不限号测试。

游戏为真●全区全服架构，整个游戏对外只有一个大区，大厅和DB等核心模块位于上海机房，战斗进程分布在上海、深圳、天津、成都四个机房，玩家首先登录大厅，进行匹配，然后根据位置信息被分配到不同地区的房间进行战斗，具体战斗流程可以参考下图简单示例（logicd:大厅，Syncd:战斗进程，kernel_netd:核心通信节点，Other:其他逻辑），游戏进程绝大多数模块支持平行扩展，核心模块为主备 动态扩展。

游戏从首测到不限号历经几年的时间，期间游戏架构变化很大，一路踩过的坑也不少，此部分内容此处不做介绍。既然标题提到了游戏内数据，本文将单从XXXX游戏内部数据出发，介绍一些发现和解决问题的方法，希望能对有需要的同学有所帮助。

初衷

北极光研发的游戏一般都会有mon_log日志，具体为类似tlog格式的游戏内数据监控日志，开发可通过该日志观察游戏内各模块功能及其他性能类数据，用于辅助游戏问题排查以及分析游戏模块功能和性能瓶颈等，多位直接分析文本日志且很难提前发现问题和分析历史问题。运维得知后，随即建议将数据接入蓝鲸做分析，结合蓝鲸强大的数据采集和存储计算平台，肯定能更好，更快速准确的反映游戏内各模块数据情况。

早在游戏上次军团测试前（2015年），我们便已开始谋划怎样导演，核心想法便是利用Gseagent采集所有mon_log文本文件，上报枫叶蓝鲸数据平台，不同的mon_log表对应不同的data_id，再通过不同的计算任务实时计算并存储DB，供前端分析使用。当时和DB以及蓝鲸平台合作，提供存储机器试点Tspider存储，加快计算速度，取得不错的成效。大体架构图如下示例。

数据

既然核心为游戏数据，那么具体包含哪些游戏数据哪？为了最大化收集分析游戏内容，我们将游戏定义的mon_log.xml中几乎所有的表都收集上报了，包含在线、网络、用户、支付、体验、DB、服务器、登录、匹配、进房间等核心模块，共计52项内容，可已参见如下图功能示例。

对于可能影响业务功能的关键数据，使用蓝鲸组件设置周期监控策略，定时检查数据是否出现异常，如下图示例（请无视之前比较搓的实现方式）。

成效

此处重点介绍我们收集了这么多的数据后，怎样通过数据发现游戏隐患或者问题，并怎样解决的。

进程内网流量和包量

发现：游戏内有一个玩法是国家战争，国战开始和结束期间，玩家会集中在一个界面上，此时客户端同时会有大量和服务端的请求，导致服务端内网流量瞬间很高，从游戏内数据获知，游戏核心通信管理进程（kn）包量瞬时可达到30W/S，具体如下图所示。几乎要达到进程处理包量的极限，而此时（8月3日），游戏还处于限号不删档期间，等到不限号期间人数会更多，此项将极有可能影响程序可用性。

解决：与开发同学确认隐患，分析问题原因；

           开发层面：减少存盘点，增加按字段拉取数据，减少跨机proxy通信，服务端大厅增加缓存功能，客户端减少数据请求量；

           运维层面：增加大厅kn数量，将包量和流量均分；

来看看优化后的效果，不限号后，9月4号的数据，在人数增加的情况下，出入包量峰值缩减为原来的1/15，已经毫无压力。

进房间失败

发现：游戏上线当天，平台部署的核心监控包含此项功能，通过当前在线人数的动态比例产生告警，在游戏对外后便第一时间发现问题，连续收到大量玩家进房间失败告警，如下：

解决：联系游戏开发同学确认问题，并共同排查，后确认为游戏逻辑bug，通过线上更新游戏二进制文件解决，如下：

其他：也可辅助发现其他周边问题，9月10日晚20:00开始大量收到进房间失败告警，而业务并未有所变动，排查发现业务所用TGW对应IP延迟很高，丢包严重，后确认为网络故障，同时影响很多同业务，如下：

母机降频

发现：平台功能监控发现部分战斗进程（syncd）CPU占用过高，服务端帧率很低，而此时进程所在的人数并不高，如下：

解决：在同样人数承载的情况下，其他进程CPU和帧率完全正常，问题明显出在机器本身上面，横向对比机器性能（如下，python循环1000W次用时），发现有几台机器用时明显很高，同时联系SA和虚拟化平台同学一起排查，发现机器所在母机有降频现象，确认问题，后将问题机器下线，问题解决。

战斗进程（syncd）人数

发现：经过剔除部分问题机器，平台功能监控仍然发现部分战斗进程（syncd），服务端帧率较低，而且多发生在晚上19:30-21:00的70VS70会战期间，依然会影响玩家体验，如下：

解决：战斗进程（syncd）默认配置最高承载300人，70VS70会战期间，可能会分配不均导致人数超过300，如上图iactorcount，导致帧率出现过低的情况，信息同步给产品和开发处，后将syncd承载人数改成200人解决，如下图，人数基本200左右，帧率80左右。

大厅人数

发现：平台有更细化的在线人数分布，通过页面发现，奇数类的大厅在线总是偶数类的大厅在线的一倍，而所有大厅进程都是同样权重接入TGW的，所有的进程和端口都是平等的，理论上应该在线一致。

解决：大厅对外有两个端口，在TCLS入口处将两个端口的URL对调后发现，偶数类的大厅在线编程奇数类的大厅在线的一倍，故可以确认这个是客户端选择端口的逻辑有问题，信息同步给客户端开发，建议取模 轮询或随机 轮询的策略选择链接URL，后解决。

网络

发现：平台有详细的玩家网络类数据展示和监控，通过页面发现玩家跨网（跨网络运营商，如电信访问联通）访问占比在35%左右，以及玩家逻辑延迟高于50ms（玩家到RS，50ms以下最优，高于100ms影响体验）都处于较高水平。如下图所示（不限号前8.16日数据），不能说跨网一定会影响用户体验，考虑到运营商之间互联互通和玩家最短路由问题，跨运营商访问可能稳定性会差一些，如出现瞬时高延迟，跳ping等问题。用户体验是第一位，故优化势在必行。

优化：由于国内网络的复杂性，故网络优化是一个长期的过程，需要一直持续跟进，以下列举几个业务优化点以及取得的效果。

         1、加入新用户引导，玩家首次进入游戏需先选择对应运营商，默认为不知道，若玩家无法确认自己当前运营商，只需点击确定即可。

2、加入局内换线功能，玩家如果在一局游戏内发现延迟或丢包太高，可在当局游戏内选择换线，无需重连即可切换到其他运营商链接，且不影响总体网络配置。

3、建议优化选线策略，优先同运营商链接，若同运营商无法访问或者延迟太高（如高于其他最优运营商*2），则选择其他运营商访问，同时推动开发接入MIG IP地址库功能，服务端根据客户端上报的IP，利用IP地址库的接口确定玩家运营商，再返回给玩家对应的url，客户端最后发起链接选择对应房间。目前两种功能均已在不限号后上线。

效果：1、如下图所示（8.20号数据），同网访问占比由61%提高到81%，同样跨网访问占比有35%降低至15%。

           2、玩家逻辑延迟方面，低于50ms的占比由65%提高到80%。

           3、玩家总体平均延迟方面（8.18日不限号），不限号前后，延迟明显有下降趋势，已从30ms左右降低至21ms左右（数据来自GEM）。

卡顿

发现：通过鹰眼以及项目组同事反馈收集到部分对局游戏出现严重卡顿现象，且该场对局中，玩家几乎同时遇到问题，严重影响玩家体验，需尽快解决。

解决：

         1、首先抓包分析问题，发现出现问题的对局中，有很多TCP重复确认和重传包，通过包序列分析延迟发现，上下行包不定期会出现高延迟（2.5-3秒）现象。

         2、游戏每个机房均有两组TGW VIP做冗余和流量分担，分析游戏内数据收集到的玩家对局类信息发现，反馈有出现问题的对局均连到了上海tgw1这组VIP上，连到另外一组VIP上的游戏并未出现卡顿现象。

         3、利用测试服验证问题，将正式服发现问题的TGW VIP配置到测试服机器上，测试游戏会出现严重卡顿，而将另一组正式服没问题的TGW VIP规则配置到测试服后，测试游戏并未出现卡顿，得出如下结论。

                   1）、tgw1 VIP的某些规则，出现卡顿现象严重；

2）、tgw1 VIP的其他规则，未见严重卡顿现象；

3）、卡顿严重的同一RS换上另外一组VIP tgw2 ，未见严重卡顿现象；

         4、定位到问题可能出现TGW1 这组VIP上面，联系网平TGW同事一起排查，发现TGW机器性能和转发并未见异常，怀疑问题可能出在上层路由上面。

         5、将正式服有问题的这组TGW1 VIP规则下线，更新游戏配置，问题得到解决。如下，客服帮助拉取的玩家反馈数据，9月5日优化后关于卡顿方面的反馈下降明显。

后序

如果单从游戏整体状况来看而忽略游戏内的数据分析，那么很多问题将无法发现或者不能及时发现，所以提前收集建设并分析游戏内数据同样重要，让不会说话的数据说起话来，yes, they can speak something!