全栈攻城狮

Appearance

游戏日志审计 ​

概述 ​

出问题时（刷漏洞、外挂、线上事故），一切判断都靠日志。游戏日志审计要做到三件事：全量记录（玩家操作有据可查）、可追踪（一次请求贯穿全链路）、可告警（异常自动发现）。本文讲清楚日志埋点、链路追踪、告警与存储归档的完整方案。

一、玩家操作全量日志 ​

1.1 埋点规范 ​

全量埋点（重要操作必记）：
  登录/登出、充值、消费
  货币/道具变动（含余额快照）
  交易、赠送、抽卡
  敏感操作（改绑、注销、提现）
  风控判定事件

日志字段：
  traceId / 玩家 ID / 操作类型 / 参数 / 结果
  时间 / IP / 设备指纹 / 请求来源
// 业务日志埋点（统一 LogContext）
LogContext ctx = LogContext.begin(playerId, opType);
ctx.param("goodsId", 1001).param("price", 300);
ctx.result(Result.SUCCESS).balance(coin);
ctx.commit();   // 异步写入日志

1.2 采集架构 ​

日志采集链路：
  应用（logback/log4j2 输出 JSON） 
  → Filebeat（收集 + 解析） 
  → Kafka（缓冲削峰） 
  → Logstash（清洗转换） 
  → Elasticsearch（存储检索） 
  → Kibana（可视化查询）

轻量替代：
  应用 → Loki → Grafana（量小够用）
  应用 → 自研日志中心（私有化）
// 结构化日志（JSON，便于检索）
{
  "ts": "2026-01-24T10:00:00.123Z",
  "traceId": "a1b2c3d4",
  "playerId": 88001,
  "op": "coin_change",
  "amount": -300,
  "balance": 1200,
  "source": "shop"
}

二、日志链路追踪（TraceId） ​

2.1 TraceId 透传 ​

链路追踪目标：
  一次请求：网关 → 逻辑服 → DB/Redis → MQ
  全程同一 TraceId → 全链路日志可串联

透传方式：
  协议头带 traceId（客户端不带则服务端生成）
  RPC/MQ 消息头传递
  线程池传递（MDC 上下文传递）
// 网关生成 TraceId 注入
String traceId = req.header.traceId;
if (traceId == null) {
    traceId = UUID.randomUUID().toString().replace("-", "");
}
MDC.put("traceId", traceId);
// 后续 RPC/MQ 带上 traceId 头
// 异步线程透传（线程池包装）
Runnable task = () -> {
    MDC.put("traceId", traceId);   // 子线程恢复上下文
    try { realTask.run(); } 
    finally { MDC.remove("traceId"); }
};
executor.submit(task);

2.2 异常定位 ​

用 TraceId 排查：
  输入 traceId → 搜出该请求全部日志
  按时间线串联（网关 → 逻辑 → DB）
  定位耗时、失败、异常点

与全链路追踪的关系：
  本文聚焦日志内 TraceId 串联
  分布式调用链（SkyWalking）见运维章节

三、异常操作告警 ​

3.1 告警规则 ​

异常告警类型：
  业务异常：频繁失败、余额异常、重复领取
  安全异常：验签失败、风控命中、异常频次
  技术异常：接口超时、异常堆栈、慢查询
  数据异常：对账不平、流水缺失

告警分级：
  P0 紧急（资金/安全事故）：短信 + 电话
  P1 严重（服务异常）：钉钉/企微群 @人
  P2 一般（指标偏差）：工作台通知
// 告警规则示例（ES 查询频率）
# 验签失败突增（疑似攻击）
es: op=verify_fail 且 5min 计数 > 1000 → P1
# 余额扣成负数（严重 BUG）
es: op=coin_change 且 balance < 0 → P0
# 某玩家 1min 充值失败 > 20 次（疑似刷单）
es: playerId 聚合 1min > 20 → P1

3.2 告警链路 ​

告警链路：
  规则引擎（ElastAlert / 自研）定时查 ES
  → 命中规则 → 发消息（钉钉/企微 Webhook）
  → 值班人处理 → 复盘（规则优化）

要求：
  告警去重（同事件只发一次）
  告警有上下文（附 TraceId/日志链接）
  规则可配置（后台调整阈值）

四、日志存储与归档 ​

4.1 存储分层 ​

日志存储分层：
  热数据（近 7 天）：ES 主集群（快速检索）
  温数据（近 3 月）：ES 冷节点 / 降级索引
  冷数据（超 3 月）：压缩归档（对象存储）

容量评估：
  单条日志 ~0.5KB，千万 DAU 量级
  关注写入 TPS 与存储增长
  采样与裁剪策略（低价值日志降低级别）
// 索引生命周期（ILM）
7 天热索引（SSD） → 90 天温（HDD） → 归档删除
# ES ILM 策略：rollover 按容量/时间，delete 定期清理

4.2 归档与合规 ​

归档策略：
  审计日志强制保留（法规要求，如充值流水）
  归档格式：压缩（zstd）+ 对象存储
  归档可回溯（提供查询接口）

合规约束：
  隐私字段脱敏后入库（见合规章节）
  访问权限控制（日志查询按角色）
  审计日志不可篡改（关键日志加验签）
// 关键日志防篡改（可选增强）
// 日志行加哈希链：hash(i) = H(日志i + hash(i-1))
// 篡改任何一条 → 链断裂可发现

五、实现要点 ​

日志审计核心：
  全量埋点（操作、资金、风控全记录）
  TraceId 透传（全链路串联）
  异常告警（规则 + 分级 + 去重）
  存储分层（热/温/冷 + 归档）
  合规（脱敏、权限、防篡改）

常见坑：
  日志不全 → 出事无法追溯
  明文敏感字段 → 泄露
  告警风暴 → 规则去重 + 分级
  日志无限增长 → 存储成本失控

与其他系统衔接：
  埋点数据 → 行为检测章节
  全链路追踪 → 运维章节（SkyWalking）
  告警通知 → 监控章节
  离线分析 → 大数据平台