迅游科技：游戏监控实践分享

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

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

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

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

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

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

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

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

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

Zabbix的实践经验粗谈**
【模板】
首先，监控这么庞大的量，一个一个去添加？不可能！所以建立模版很重要，而且模版只有一套也不行，我们的服务器类型、配置，所在运营商很多，项目也多，建立多套模版很有必要，甚至有时需要子模板。不要小看这个思路，这和各类软件架构的构成也是一脉相承的，有共性的监控项，可使用同一套模版，按需关联即可。
这样，批量调整成为可能。比如调某个阈值，至少不用一台一台去改了吧。个别主机有少量不同的地方，比如它的磁盘就只有50GB，CPU核就1个，或者它的带宽高达500Mbps，模板不适用了，单独做模板不太好，就把由模板关联进来的相关触发器停用，克隆一个，重调阈值即可。

【主机】
接着说主机的添加，主机按项目或运营商，进行交叉分组，方便查找。主机的命名非常讲究，直接和“动作”（触发报警后发送给那些人）有关系，根据关键字关联，同一项目的主机（设备）使用同一关键字打头。
为什么puppet里面建议的主机名那么长，因为那才能准确的描述一台主机，它的IP、机房、用途、服务、功能，都是可能随业务而变化，每个公司有不同的情况。
【触发器】
触发器的名称包含主机名称即可，在模版中统一配置，就不用单独去想它怎么命名了。

【动作】
即把哪些报警发送到哪儿，根据问题的严重性，匹配名称，发送给对应的项目组运维岗的邮箱或短信，或电话告警。
例如迅游网站项目的动作截图：

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

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

【示警媒介】
我们有自编脚本，自建邮件系统，触发告警发邮件，为什么自建邮件系统呢，因为第三方邮件系统大多有限制，还不便宜。当然你的量真的很少，就没关系了。
重要告警，结合飞信、微信、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事务流监控。

转载于:https://my.oschina.net/cloudwise/blog/702795