日志收集与分析

概述

日志分散在每台机器上等于没有日志。ELK/EFK 把全集群日志收拢到一个平台，统一检索、可视化、告警。本文讲清楚日志采集架构、业务日志接入 Kibana、慢接口与异常告警，以及日志查询的实践技巧。

---

一、日志采集架构

1.1 ELK 与 EFK

ELK 组件：
  Elasticsearch：存储 + 全文检索（核心）
  Logstash：采集 + 转换 + 输出（较重）
  Kibana：可视化 + 检索界面

EFK 变体（推荐，更轻）：
  Filebeat：轻量采集（替代 Logstash 采集端）
  Elasticsearch：存储
  Kibana：展示
  Logstash：仅做复杂转换（可选保留）

架构：
  应用 → Filebeat → Kafka（缓冲） → Logstash（清洗）
       → Elasticsearch → Kibana

// 采集链路设计
应用输出 JSON 日志（logback）
  → Filebeat 采集（多行合并、解析）
  → Kafka（削峰缓冲，防 ES 抖动拖垮）
  → Logstash（字段解析、脱敏、索引路由）
  → ES（按天/按类型索引）
  → Kibana（查询/看板/告警源）

1.2 业务日志接入

日志规范（可检索前提）：
  统一 JSON 格式（字段化，非字符串拼接）
  统一时间字段（ISO8601 + 时区）
  统一级别（INFO/WARN/ERROR/审计）
  关键字段：traceId/playerId/op/result

// logback 输出 JSON（logstash-logback-encoder）
// 使用 LogstashEncoder，附加 app/env 两个自定义字段
// 日志示例
{"ts":"2026-01-27T10:00:00Z","level":"WARN",
 "app":"game-logic","traceId":"a1b2","playerId":88001,
 "op":"coin_change","msg":"余额不足"}

---

二、Kibana 可视化

2.1 索引与字段

索引规划：
  按应用分：game-gateway-*/game-logic-*
  按天滚动：game-logic-2026.01.27
  按类型分：业务日志 / 错误日志 / 审计日志

常用检索字段：
  level、app、traceId、playerId、op
  耗时字段（request.ms）、状态码

// Kibana 常用检索（DSL 示例）
// 查某玩家近 24h 所有操作
GET game-logic-*/_search
{
  "query": { "bool": { "must": [
    { "term": { "playerId": 88001 } },
    { "range": { "ts": { "gte": "now-1d" } } }
  ]}}
}

2.2 看板设计

看板维度：
  全局总览：日志量、ERROR 占比、各应用分布
  业务视图：充值成功/失败、登录分布
  错误视图：ERROR 排行（按 op 聚合）、堆栈分布
  性能视图：慢接口 Top（按耗时聚合）

常用聚合：
  terms（按字段分组）、date_histogram（时间桶）
  percentiles（P95/P99 耗时）、top_hits（样本）

// 慢接口 Top（按 op 聚合平均耗时）
GET game-logic-*/_search
{
  "aggs": {
    "by_op": {
      "terms": { "field": "op", "size": 10 },
      "aggs": { "avg_ms": { "avg": { "field": "req.ms" } } }
    }
  }
}

---

三、慢接口与异常告警

3.1 告警规则

告警规则（基于 ES 查询）：
  慢接口：op 平均耗时 > 阈值（如 500ms）持续 5min
  异常突增：ERROR 日志量环比 > 3 倍
  特定错误：OutOfMemory / 连接池耗尽等关键字
  业务告警：失败率超阈值（如充值失败率 > 1%）

工具：
  ElastAlert（成熟开源）
  自研轮询（定时查 ES 命中即发）

// ElastAlert 规则示例
alert:
  - "dingtalk"
filter:
  - query:
      query_string:
        query: "level:ERROR AND op:settle"
  # 5 分钟内命中超过 10 次才告警

// 慢接口告警
filter:
  - range:
      "req.ms": { "gte": 500 }
aggregation:
  # 按 op 分组，超阈值发一条

3.2 告警质量

告警质量要求：
  去重：同类型告警合并（防风暴）
  分级：P0（资金/事故）vs P1（服务异常）
  上下文：告警附 TraceId 与日志链接
  值班：告警转人工处理 → 复盘

常见问题：
  告警风暴（阈值过低/无去重）
  告警无上下文（收到无法处理）
  只告警不闭环（反复出现不修复）

---

四、查询与分析实践

4.1 常用排查场景

排查场景：
  玩家问题：traceId / playerId 全链路日志
  线上事故：按时间窗 + 服务聚合错误
  性能问题：慢查询日志 + 接口耗时分布
  安全事件：验签失败/风控命中检索

技巧：
  时间范围收窄（先粗后细）
  多条件组合（level + op + playerId）
  聚合先看分布，再看明细
  保存常用查询为模板

// 一次完整排查
1. 玩家报"充值没到账" → 搜 orderId
2. 看到回调日志 → 判断是未回调还是发货失败
3. 搜 traceId 串联全链路（网关/回调/发货）
4. 定位失败原因 → 修复 → 补发

4.2 性能与成本

查询性能：
  常用字段建索引（keyword）
  按天/按应用分索引（缩小检索范围）
  避免深分页（用 scroll / 聚合代替）
  保留周期与容量规划（见归档）

成本控制：
  低价值日志降级（DEBUG 不采集）
  采样（高 TPS 日志按比例）
  冷热分层（见日志审计归档章节）

// 索引字段映射（关键字段 keyword 类型）
{
  "mappings": {
    "properties": {
      "playerId": { "type": "keyword" },
      "op": { "type": "keyword" },
      "traceId": { "type": "keyword" }
    }
  }
}

---

五、实现要点

日志平台核心：
  采集：Filebeat → Kafka → Logstash → ES → Kibana
  规范：JSON 结构化 + 统一字段 + traceId
  可视化：看板（全局/业务/错误/性能）
  告警：慢接口 + 异常突增 + 分级去重
  实践：traceId 排查 + 聚合分析 + 成本控制

常见坑：
  日志非结构化 → 无法检索
  无缓冲直接入 ES → ES 抖动拖垮业务
  告警风暴 → 失去告警价值
  无限保留 → 成本失控

与其他系统衔接：
  采集端 → 游戏日志审计章节（埋点）
  TraceId → 日志审计章节（透传）
  全链路 → 全链路追踪章节（SkyWalking）
  告警通知 → 实时监控章节（钉钉/企微）