Hi!下午好!欢迎访问互联网
当前位置:主页 > 软件

迅游科技赵亚南游戏监控实践分享

时间:2018-09-09 18:28:56| 来源:| 编辑:笔名| 点击:0次

迅游科技赵亚南:游戏监控实践分享

赵亚南,7年运维实践经验,早期主要负责过淘宝淘江湖、浙江、银率(北京)、广州宝洁、机电之家等站的维护,2012年后加入重庆迅游,负责开服、开区及多个游戏项目的运维,务真求实,追求以公司项目实际情况出发,权衡成本、效率、安全和稳定,推动团队向最合理的方向发展。

游戏玩家对游戏体验的要求是最苛刻的,任何由于服务器、数据库性能瓶颈、络CDN造成的卡顿、崩溃都会影响游戏体验,并有可能造成玩家的流失和支付的减少,因此如何确保各地玩家在游戏过程中获得最佳用户体验,第一时间发现系统、应用、络故障并予以解决,是游戏公司对运维部门的基本要求。

重庆迅游科技成立于2009年,目前团队规模不到200人。自主运营开服等资讯站,自主研发端游《传奇正传》、页游《开天战神》、手游《满贯游戏》等产品,有专业的研发技术团队,是一家技术导向的公司,和兄弟公司小闲强强联手,在重庆游戏产业内颇具影响力!下面是迅游运维部门负责人赵亚南在云智慧[监控与性能优化]群分享的游戏监控经验。

大家好,我是赵亚南,来自重庆迅游科技,今天分享一些游戏监控的实践经验,谢谢大家棒场。我个人在运维岗工作了7年,主要历程在前面都有介绍,2012年后加入重庆迅游,经验也从这里开始分享吧。

重庆迅游的监控选择

监控的工具和方式太多,相信大家都能列举出很多,但永远是适合自已的才是最好的。因为游戏行业的业务需求,运维工作需要在监控上做到最好,否则就会直接影响公司收入。

经常会有人讲: 运维就是主动发现问题,变被动为主动,说得在理,但实际上是做不到100%主动的,这时候完善的监控体系就能帮助我们更好地发现问题,定位问题。监控做得好不好,就很重要了。

要用好的监控工具,而且不光要会用,还要去深入研究、测试、验证,规划好,做好自动化设置,监控配置合理,报警效率高,发送给该发送的人,不紧要的就发邮件,紧要的那就发邮件和短信,甚至同时报警,不该报的不要报,不该发送的人不要发送。

很啰嗦吧。是啊,要做到这些,是要花很多时间和精力的,尤其是业务变动频繁,变动量大时,不但要承担业务的设备、服务等资源的调整,监控项、阈值也要按需调整,你敢保证这次调整的就一定合理吗?那过两天很可能需要再调整。

废话真多,直接说下我们是怎么做的吧。(我们就做得完美吗?也难讲)

最初迅游采用的是云智慧监控宝,用了很多年。后来监控需求越来越多,就写脚本监控,不过比较分散,管理不方便,于是把Zabbix也加进来。Zabbix 优点包括灵活、稳定、有效、性能好、功能强大,最大的问题是帮助文件全英文,而且功能复杂,就是全翻译成中文看着也头大,因业务变动频繁,变动量大,只好一边用一边摸索,有特别需求时,去找官方文档相关的部分,或百度搜一下,下面说说总体思路。

Zabbix的实践经验粗谈

【模板】

首先,监控这么庞大的量,一个一个去添加?不可能!所以建立模版很重要,而且模版只有一套也不行,我们的服务器类型、配置,所在运营商很多,项目也多,建立多套模版很有必要,甚至有时需要子模板。不要小看这个思路,这和各类软件架构的构成也是一脉相承的,有共性的监控项,可使用同一套模版,按需关联即可。

这样,批量调整成为可能。比如调某个阈值,至少不用一台一台去改了吧。个别主机有少量不同的地方,比如它的磁盘就只有50GB,CPU核就1个,或者它的带宽高达500Mbps,模板不适用了,单独做模板不太好,就把由模板关联进来的相关触发器停用,克隆一个,重调阈值即可。

【主机】

接着说主机的添加,主机按项目或运营商,进行交叉分组,方便查找。主机的命名非常讲究,直接和动作(触发报警后发送给那些人)有关系,根据关键字关联,同一项目的主机(设备)使用同一关键字打头。

为什么puppet里面建议的主机名那么长,因为那才能准确的描述一台主机,它的IP、机房、用途、服务、功能,都是可能随业务而变化,每个公司有不同的情况。

【触发器】

触发器的名称包含主机名称即可

迅游科技赵亚南游戏监控实践分享

,在模版中统一配置,就不用单独去想它怎么命名了。

【动作】

即把哪些报警发送到哪儿,根据问题的严重性,匹配名称,发送给对应的项目组运维岗的邮箱或短信,或告警。

例如迅游站项目的动作截图:

另外,把{LUE}包含到警报信息中,在非工作时间收到报警,具体监控值也许对你有帮助。

【用户和用户组】

动作只把告警发给用户组,我们用户组按项目建立,用户添加到组中,方便批量管理。

【示警媒介】

我们有自编脚本,自建邮件系统,触发告警发邮件,为什么自建邮件系统呢,因为第三方邮件系统大多有限制,还不便宜。当然你的量真的很少,就没关系了。

重要告警,结合飞信、、139邮箱,189邮箱,联通的wo邮箱,发送告警信息。喜欢长期连的同事,直接通过互联接收公司邮箱的告警也行。这里说个细节,最好尊重每个人的习惯、选择,人性化一点嘛。在非上班时间接收告警和要求应急响应的必须是比较严重的问题,毕竟是对人家私人时间的侵占。严重故障,可以通过监控宝等第三方告警平台触发告警,这种情况通常还会发给领导。

【自动发现(或着叫探索)】

某些监控可以做成自动发现,比如某些主机的进程,重要端口,其监控量和维护量十分庞大,我们的估约有几千项的,所以按json格式自动生成,增减自动完成(shell或python实现)。Zabbix服务端做个模版,配置自动发现,有需要的主机关联下模版即可,监控内容也自动增删,触发阈值统一配置,全程高度自动化。

【重要的业务监控】

举例一:比如站,从玩家发起请求到最终成功响应正确内容,期间要经过DNS、边缘节点、父层节点、前端nginx服务、php服务、haproxy、 mysql,我们就做一个连接数据库并查询必要字串的php程序,Zabbix本来就可以部署在异地的,这样由Zabbix开始,通过公解析后,从边缘节点监控起,获取到查询的正确字符串,并且响应时间不长,完成这一连串监控,哪一层有问题,报警都不会恢复。

举例二:模拟站登陆过程,站功能那么多,能监控到的总是有限。我们就监控经常有问题的、重要的地方,站登陆过程经常出问题,好,我们结合监控宝分布式监测络控件,在异地自动模拟登陆过程。

举例三:太多监控都是从运维角度去发起的,只关注基础设施的运行状况。大家是不是遇到过这样的场景,就是我们所有监控都没有发现问题,但业务部门反馈用户量就是下降了。最后查出来还真是运维的问题,没有监控到业务层的运行状况。如果你能主动监控公司业务的状况,并在发现问题的第一时间向业务部门反馈,现在量下降了,注意一下,也许同时咱们就发现问题了并解决了,或者即使没解决业务部分对运维的印象还是好的。所以能监控到业务数据就最好,幸好迅游的人数写在了数据库中,直接取出来,配置触发器,还做成图,有异常,很容易发现。比如某台DB的监控:

【总览图】

想一眼就直观的看到想关注的监控项目吗?这是由Zabbix的筛选和总览来实现的,其中总览可以按主机来查看,当然也不用一个一个去添,在主机模版中配置好筛选即可。筛选就是比较灵活的了,和监控宝的视图类似,可以组织任意你想观察的图表在一个界面中来。

【各类应用监控】

Zabbix监控很容易扩展,默认的如果没有可以去上找模板,或者自主编写监控脚本,我们找了些模板,也自主编写或完善了一些,如 nginx,memcache,redis,mysql,varnish,想关注的可用性或性能趋势,都做了上去。但说实话,如果业务量不大的话这些真没多少用,但是业务量很大的时候,这些应用服务就有出现性能瓶颈的可能,或者出错率上升,运维必须进行关注,做到心中有数。

领导都喜欢看图表,所以我们使用了大屏展示Zabbix的数据,Grafana可以从Zabbix中取数据,定制灵活,图形展示非常好,可做大屏展示,一目了然,它的正则很好用,但有个缺点就是查询时间跨度太大,甚至超过半个月,就会造成Zabbix数据库极大的压力,所以开放给非运维岗的同事查询太不明智了,看看结果就行了。

监控宝的实践经验粗谈

Zabbix主要用于基础设施和应用层的可用性监控,但Zabbix的分布式监控还是比较弱的,并且即使好用,其成本投入也很大。所以络层的监控就要靠监控宝了,监控宝的监控点在国内、国外到处都有,如果有部分服务器或用户在境外,那监控宝更是值得推荐的第三方监控服务了,所以接下来聊聊监控宝。

如果要关心特定地区的络情况,监控宝是很容易做到的,这个功能非常好:

如果有很多边缘节点,又不愿花钱买更多的监控宝站监控项服务,那就针对分布式监测点设置为1~2个,几乎就能监控到各个边缘节点了。如果设置了好几个,而且都报警了,业务部门问起来,你就有分析参考的依据了,和同运营商的其它监控以及不同运营商的监控一对比,就能明白发生什么事儿了,如果骨干的事,也许可以提前松口气说:还好不是我的事儿。

当然这只是监控宝最具价值的功能之一,短信告警、语音告警、用户体验监控都是其核心功能,此外如果大量使用了API,那么监控宝API监控同样是不能错过的,这些也是其它监控服务商或自建监控平台难以替代的,这是老实话。

有的人还在提各种免费监控,确实免费监控很长一段时间好像还可以用,但从企业业务需求的角度出发,过去两年的经验告诉咱们,免费的可靠性确实不高。对于不想在监控方面投入太多人力物力,或者技术能力达不到使用Zabbix的,或者监控量不大的,都可以考虑监控宝,省事还好用。

最后分享一个案例

咱们举个在监控宝上使用的案例,我们购买了2个监控宝账号,按业务需求需要对重点区域和重要运营商的可用性、络质量进行监控,所以咱们建了多个监测点:

每个监测点均精心选择,两个账号选的监测点互不相同,覆盖重点区域和重要运营商。监控服务目前主要以站监控为主,每个监测项均精巧配置,均有不同意义,避免重复配置:

全国CDN节点那么多,我们是这样监控的:

全国CDN监控,咱们就在两个账号分别配置了一个任意点延时就告警。有的人要问了,10秒延时才告警是不是太慢了?是的,但这是有效监控的追求,并且页加载过程中已经不影响访客浏览了,而监控宝一定要等他加载完啊,这是人机的区别。

现在监控宝绑定的告警邮箱只有一个,咱们就使用一个公共邮箱,所有的人都能收到。如果您的监控要分类发送到不同的接收人,那可以考虑监控宝的企业版服务,比你自已去研究Zabbix来得可靠,节省时间和精力,专注于业务。

当然也有一些偏方,比如邮件过滤转发,foxmail过滤转发,这个过程增加了告警成功的依赖,其可靠性理论上肯定要低一些。

谢谢大家,分享结束。

问: Zabbix和监控宝有没有业务冲突,你两个都有用?

答:基本上没有冲突,只在最最重要的业务监控上,做了重复监控。

问:游戏产品的监控有没有特别需要注意的监控点?他们的监控阈值可否给我们一个参考。

答:游戏产品的监控,还是应该根据每款游戏的特点来。一些基础项目包括游戏登陆服是否存活,游戏服务端各重要端口,是否在正常侦听,数据库及其所在服务器各项性能(和站数据库一样的监控了)。通常还有平台,最好配备这两项监控:机器人模拟登陆游戏,模拟一个重要操作,和真实玩家的操作流程越接近越好。

此外要关注平台各项数据是否有大的波动,比如玩家,是否有突然掉线、人数大减,如果其它指标都没变就人数变了,肯定需要人工去处理了。

另外充值数据也是一个重要监控项,经常是什么都好的,就有几个小时没有进账了,直到早上有玩家反馈。通常充值过程很复杂的,涉及到第三方支付接口,所以必须监控到它的一连串服务是否正常,这就可以用到监控宝API事务流监控。

问:如何用Zabbix监控cpu的idel利用率,目前只能是监控cpu的负载?

答:新版Zabbix自带这个功能,il{idle}。