概述

游戏行业的日志诉求

如果说今天的游戏是一个数据驱动的行业，一点也不会错。我们来看一下游戏公司不同的角色面对不同问题的时候，如何使用数据来解决问题。

可以看出数据是以上岗位运作的关键要素。

数据从哪里来？

可以看到，游戏数据的完整，需要全方位的日志采集（从客户端到服务器），随着规模、体量的挑战；

同时日志还需要面对今天数据仓库、数据湖的解决方案。让日志数据分析的整体方案复杂度较高。

随着游戏国际化的推进，日志往往存储在不同的地区，让游戏日志分析使用产生了更多的挑战。因为本身将基于SLS（阿里云日志服务）介绍游戏场景全球日志规划部署方案。

阿里云SLS的解决方案

阿里云SLS为日志场景提供整套的完整解决方案

游戏日志采集

基础概念

一般游戏Project Logstore规划

从业务属性来看有哪些日志

• 用户游戏过程中的行为日志
• 用户注册、登陆、购买、退出的日志
• 用户广告点击日志
• 手机端的程序异常日志（崩溃、卡顿等日志）

从采集视角

• Client端（iOS、Android、Web）
• 服务端

Project建议：根据业务主题，建立相应的Project。例如

• 用户相关的建立一个Project
• 开发运维相关的建立一个Project

Logstore建议：根据不同的端+业务属性来建Logstore，例如

• iOS端、Androind、网页端建不同的Logstore

游戏客户端采集

端SDK埋点 -> SLS

客户端直接SDK写入方法：

• 移动端：可以使用移动端 SDK IOS, Android 接入。
• ARM 设备：ARM 平台可以使用 Native C 交叉编译。
• H5网页端，直接使用Webtracking API 方式写入日志服务 参考链接

客户端埋点的方式是在游戏开发阶段需要介入，一旦使用SDK完成埋点，就可以方便地使用SLS服务

端->服务器日志- > SLS

如果游戏已经大量发行，并且已经有自定义API上传日志到服务器端。

这个情况下，适合直接使用 SLS的iLogtail采集服务端的文件然后再使用SLS服务，iLogtail介绍参考 链接

小结

综合推荐使用“端SDK->SLS”的方案，让游戏开发更专注关注业务本身。

说明1: 对于SDK端写入默认有QPS限制，针对海量高并发写入的场景，请提交工单联系我们

读写限制见 链接

游戏服务端采集

iLogtail

游戏服务端日志采集支持的文件格式

iLogtail支持任意文本文件的采集，并且能够很好适配以下场景

• 极简模式，支持任意格式 链接
• Json格式日志
• Java日志
• 多行采集（设定好行首即可实现，适用Java堆栈、日志换行打印的情况）
• Apache、Nginx、iis访问日志
• 可以完整正则匹配的日志

ECS云服务器、传统IDC以及其他云厂商主机（Windows、Linux）

如果是阿里云的ECS服务器，默认已经安装iLogtail了，可以直接使用。如果发现没有安装可以参考 链接

如果是自建IDC的服务器，可以参考我们iLogtail的安装方法进行安装

• Linux主机 安装参考链接
• Windows主机 安装参考 链接

云原生K8S集群

随着云原生的浪潮，很多游戏服务端也可以尝试云原生的部署方式。

针对K8S的场景，SLS的iLogtail也有完整的云原生解决方案。

• 阿里云ACK 独享模式 参考 链接
• 阿里云ACK Servless模式 SideCar方式 参考 链接
• 自建K8S 安装iLogtail方式 链接

iLogtail在云原生场景下，除了支持采集普通文件外，还支持采集标准输出，只要做好相应配置即可 参考 链接

普通Docker容器的采集方式

如果我们的游戏服务端没有使用k8s等容器调度编排。iLogtail也可以直接采集容器日志 参考 链接

服务端SDK写入方式

SLS支持主流语言的SDK，使用SDK可以很方便地往SLS写入数据

阿里云产品日志采集

如果游戏服务端使用了阿里云的产品，日志服务也可以直接采集阿里云服务的日志到自己的Project

游戏日志中心化

日志中心化的挑战

游戏服务端往往按不同区域分布，从上图看到出海游戏的营收在增长，越来越多的游戏在走出国门。

而游戏对应的日志日志更加呈现出跨区域割裂的状态。真实的部署形态往往是这样的

而面对游戏数据分析的需求，往往是希望日志是中心化的。

日志中心化主要的挑战是网络传输的稳定性，国际带宽往往存在速度和稳定性的问题，因此游戏日志的中心化，需要传输在网络层面做诸多优化

方案1 iLogtail配置公网跨Region传输

iLogtail支持配置公网传输，并且在网络质量较差的情况下，进行重试。iLogtail配置公网传输存在的一个风险是当网络质量持续较差的情况下，iLogtail会持续重试传输日志，而这个过程中如果日志文件被rotate掉的话，那么这部分被rotate掉但未被iLogtail采集到服务端的日志就永远不会被采集到了。

方案2 使用SLS数据加工集中采集（推荐）

目前比较推荐的日志中心化的方案是通过数据加工来做跨Region的中心化采集，SLS数据加工简介 -> 链接

SLS数据加工提供了对日志数据进行行处理的强大能力，目前有200+的函数（函数总览 链接），数据加工除了提供了丰富的行处理函数，还支持跨Region的数据传输，并且对跨Reion网络质量较差的情况进行了优化

SLS数据加工跨Region传输日志配置方法参考 链接

方案对比

小结

目前日志中心化比较成熟的方式是使用 数据加工的跨Region传输方案，可以有效避免在网络质量较差的情况下日志轮转导致的损失。并且在跨Region传输前，进行日志加工处理。

游戏日志规整和加工处理

数据规整&加工处理

由于游戏开发阶段没有充分考虑到后续数据分析的需求，导致日志采集后要做相应的处理。举个例子，日志先从端手机到logstore，然后再做一些解析处理好复杂的结构，再根据字段判断做分发，到不同的logstore里。

一个实际的场景，我们采集上来的日志是一串json格式的字符串

使用加工语句

e_json("data", fmt="parent")
# 丢弃原字段
e_drop_fields("data", regex=False)

输出结果，可以看到经过json抽取，字段已经抽取到第一级

数据加工功能提供了编程级的支持，在日志行处理方面非常方便，有200+的算子支持

游戏数据分析与可视化

索引查询&SQL分析

SLS除了提供日志存储外，还提供强大的索引和SQL查询能力。

举个例子，客服场景，需要通过日志查询某个用户的操作

以用户在游戏里的动作为例，前面通过e_json抽取已经把日志抽取出来了。我们可以对数据加工输出的logstore建立字段索引，方便进行查询

通过指定 key: value的方式，快速查询某个用户uid的操作记录

* and data.userId: 1049

通过使用管道符|，在索引查询之后可以使用sql进行进一步的过滤查询

* and data.userId: 1049 | select "data.map_x","data.mapY","data.action" from log limit 10

SLS除了提供基础的功能外，还支持使用SQL来查询分析日志，参考

可视化报表

SLS 同样支持丰富的可视化图表通过使用这些图表，可以一站式地完整分析+报表展示的功能

继续上面的例子，我们想统计指定UserId一段时间的操作次数，形成饼图，可以这样写

* and data.userId: 1089 | 
    select "data.action", count(*) as c from log group by "data.action"

除了提供了饼图以外，还有更多的组件可以帮助做可视化。

游戏日志实时消费与投递（数据湖）

实时消费

目前日志消费支持主流的计算引擎（Flink、Spark、Strorm、阿里云流计算等），

同时对于轻量级的场景，也直接使用sdk来进行数据实时消费。

投递到传统数据仓库、数据湖

• 投递到MaxCompute数据仓库 参考 链接
• 投递到AnalyticDB 参考 链接
• 投递到OSS数据湖

总结

本文主要围绕游戏场景，介绍了SLS（日志服务）整体的游戏日志采集、规整、分析、可视化以及数据仓库建设的整体解决方案，希望对看官有帮助。如果对SLS有疑问欢迎加钉钉群或者提工单咨询。