遍布全球数十个国家，千亿级的监控体系是这样炼成的

首先是游戏架构的变迁，从最开始的单机架构，扩展到分布式架构。也就是说，玩家看到一个游戏服，在后面会有十几台机器，有的甚至多达百台机器，取决于玩法不同。

后来，很多游戏的开发接触到微服务的概念，开始逐渐的把游戏里面比如大厅、聊天服务从游戏的核心逻辑里面独立出来，变成微服务，对游戏服务提供支持。这种情况下，微服务场景开始逐渐在游戏场景里面出现。

第二方面，我们一直在做游戏上云，一开始在物理机器部署游戏服，后来做私有云，在虚拟机上部署。在出海的过程中也开始逐渐采购海外的公有云和第三方 IDC 的机器。

再后来我们开始做容器化，在容器化进行到一定程度，现在有一些游戏也开始尝试云原生。但是我们这个过程不是一蹴而就的，毕竟体量比较大，而且一个公司可能会有几百个游戏，在这种场景下就会出现一个混合云的状态，有些游戏还是物理部署的，有些游戏已经云原生了，这种情况下挑战是非常大的。

我们在采集层面会做很多数据入口，比如说有 SDK，agent，日志指标，还有第三方数据库。通过多区域部署的就近接入层，把这些数据接过来导到中央，中央会用一个 kafka 的数据队列做解耦和路由，支持多系统的数据订阅，此外还有聚合，数据存储。

在数据应用的迭代过程中，我们会有一些历史包袱，一开始是看业务场景来做监控的，所以就会出现一堆数据子系统，比如说有客户端监控，用户体验的监控，有服务端监控，有资源相关监控，有网络监控，还有性能优化的监控。

我们目前正在逐一整合，并且对外提供统一入口。报警层面是基于一个标准化的规则引擎做报警，现阶段我们也在逐渐把异常检测，事件关联这些功能加进去，此外还有像问题生命周期管理、事件升级来确保通知可达等机制。

最上层我们提供了一些数据可视化、报警通知、实时分析、性能优化等一系列的能力。控制层面，我们通过跟 CMDB 深度结合，订阅 CMDB 变更来减少监控的配置成本。

通过区域管理来做到全球化的监控。我们的 agent 能够支持到丰富的插件自定义功能，所以有一个插件仓库。

最后我们做了一个命令管道，其实就是类似于像 Ansible 的东⻄，跟我们的 agent 集成，最直接的价值就是配置的分发、故障自愈等功能都可以依托这样的基础架构来构建。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!