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

可以看出数据是以上岗位运作的关键要素。
数据从哪里来?

日志类型
|
设备
|
主要场景
|
客户端操作日志
|
手机、PC、网页
|
运营、客服、决策
|
客户端运行日志和指标
|
手机、PC、网页
|
开发运维
|
服务端请求日志
|
服务器
|
运营、客服、决策
|
服务端运行日志
|
服务器
|
开发运维
|
可以看到,游戏数据的完整,需要全方位的日志采集(从客户端到服务器),随着规模、体量的挑战;
同时日志还需要面对今天数据仓库、数据湖的解决方案。让日志数据分析的整体方案复杂度较高。
随着游戏国际化的推进,日志往往存储在不同的地区,让游戏日志分析使用产生了更多的挑战。因为本身将基于SLS(阿里云日志服务)介绍游戏场景全球日志规划部署方案。
阿里云SLS的解决方案
阿里云SLS为日志场景提供整套的完整解决方案

游戏日志采集

基础概念

概念
|
说明
|
Project
|
SLS里对资源的组织单位,类似mysql的db
|
Logstore
|
SLS里日志存储的单元,类似mysql的table
|
iLogtail
|
SLS提供的自主研发的高性能日志采集工具,支持Linux/Windows
|
Loghub
|
SLS服务端组件,提供日志存储和订阅能力,类似Kalfka
|
一般游戏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
|
端->服务器日志->SLS
|
开发量
|
客户端集成SLS SDK
|
需要开发采集程序客户端+服务端
|
成本
|
SLS使用费用
|
webserver机器成本+SLS使用费用
|
稳定性/性能
|
SLS服务能力保障 见说明1
|
需要保障端->服务器上传稳定性
|
综合推荐使用“端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的操作记录

通过使用管道符|,在索引查询之后可以使用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有疑问欢迎加钉钉群或者提工单咨询。