3、日志存储选型：Elasticsearch基础概念、索引与分片、Logstash配置实战、Kibana可视化入门

聊到日志存储，很多新手第一反应就是「扔到数据库里」。嗯，我当年也这么干过。结果呢？游戏高峰期一天几个GB的日志，MySQL直接跪了。后来我换上了Elasticsearch，才算真正把日志这块理顺了。

说白了，Elasticsearch就是为「搜索和分析」而生的。它不是传统的关系型数据库，而是一个分布式搜索引擎。你想想看，游戏日志里最常干的事是什么？查某个玩家某天的行为、统计某个道具的产出、定位某个报错的时间点——这些全是搜索和聚合的活，ES天生就擅长。

3.1 Elasticsearch基础概念

先过一遍核心概念。别嫌基础，我见过不少运维把ES当MySQL用，结果集群崩了都不知道为什么。

  • 索引（Index）：相当于数据库里的「表」。比如我们游戏日志，可以按天建索引：game_log_2025-01-01、game_log_2025-01-02。每个索引里存的是同一类数据。
  • 文档（Document）：相当于表里的「一行记录」。一条玩家登录日志就是一个文档，JSON格式。
  • 字段（Field）：文档里的每个属性。比如玩家ID、登录时间、IP地址。
  • 映射（Mapping）：定义字段的类型。比如时间字段是date类型，玩家ID是keyword类型。映射搞错了，聚合查询就会出问题。
  • 节点（Node）：一台运行ES的服务器。一个集群可以有多个节点。
  • 集群（Cluster）：多个节点组成的整体。数据分散在集群里，对外统一提供服务。

重要提醒：ES的索引名有命名规范——只能小写字母、数字、下划线、连字符。我见过有人用大写字母建索引，结果ES直接报错。嗯，踩过这个坑。

3.2 索引与分片

分片（Shard）是ES实现分布式的核心。一个索引会被拆成多个分片，分散到不同节点上。

为什么要分片？ 举个例子，你一天的游戏日志有50GB。如果只放在一台机器上，查询慢不说，磁盘也扛不住。分片之后，每个节点只存一部分数据，查询时并行搜索，速度翻倍。

分片有两种：

  • 主分片（Primary Shard）：真正存数据的。索引创建时就要定好数量，之后不能改。
  • 副本分片（Replica Shard）：主分片的备份。主分片挂了，副本顶上。副本还能分担读请求。

我个人习惯，游戏日志索引一般设3个主分片、1个副本。为什么是3？因为集群通常3个节点，每个节点一个主分片，负载最均衡。副本设1个，保证高可用就行，太多浪费磁盘。

经验之谈：主分片数量别设太大。我见过有人设20个主分片，结果每个分片只有几百MB数据，查询时反而因为分片太多导致调度开销过大。一般建议每个分片10-30GB数据。

创建索引时指定分片数量：

PUT /game_log_2025-01-01
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}

如果你用的是Logstash自动创建索引，可以在Logstash配置里设置模板，这样每次建索引都自动套用分片规则。

3.3 Logstash配置实战

Logstash是ES的「搬运工」。它从各种来源读取日志，解析成结构化数据，再写入ES。

一个典型的Logstash配置有三部分：input、filter、output。我直接给个实战例子，这是我们游戏项目在用的配置（简化版）：

input {
  beats {
    port => 5044
  }
}

filter {
  # 解析游戏日志格式
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} \[%{LOGLEVEL:level}\] %{DATA:module} - %{GREEDYDATA:log_message}" }
  }
  
  # 转换时间字段
  date {
    match => ["timestamp", "ISO8601"]
    target => "@timestamp"
  }
  
  # 添加玩家ID字段（从日志内容提取）
  if [module] == "player" {
    grok {
      match => { "log_message" => "player_id=%{NUMBER:player_id}" }
    }
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "game_log_%{+YYYY.MM.dd}"
    user => "elastic"
    password => "your_password"
  }
}

这里有几个要点：

  • input用beats：Filebeat采集日志，发送给Logstash。比Logstash直接读文件更稳定。
  • grok是核心：正则表达式解析日志。写grok规则时，建议先用Kibana的Grok Debugger调试，省得反复重启Logstash。
  • output指定索引名：按天建索引，方便后续管理。比如只保留7天的索引，直接删掉旧的就行。

避坑指南：我曾经在filter里写了一个复杂的grok规则，结果日志量大的时候Logstash CPU飙到100%。后来发现是正则回溯导致的。解决办法：用dissect插件代替grok，性能提升好几倍。dissect不支持正则，但解析固定格式的日志比grok快得多。

3.4 Kibana可视化入门

数据进了ES，怎么展示？Kibana就是干这个的。说白了，它就是个可视化面板，把枯燥的日志变成图表。

第一步：创建索引模式

在Kibana的Management页面，添加索引模式。比如输入game_log_*，匹配所有游戏日志索引。然后选择时间字段（通常是@timestamp）。

第二步：Discover里查日志

Discover页面可以搜索和过滤日志。我常用的操作：

  • 按时间范围筛选：只看最近15分钟
  • 按level过滤：只看ERROR级别的日志
  • 按玩家ID搜索：查某个玩家出问题的上下文

第三步：创建可视化图表

Visualize Library里可以创建各种图表。我举几个游戏运维常用的：

图表类型 用途 配置示例
柱状图 每小时错误数统计 X轴：@timestamp（按小时聚合），Y轴：计数，过滤：level:ERROR
饼图 错误类型分布 分片：module.keyword，指标：计数
数据表 Top 10报错玩家 分片：player_id.keyword，排序：计数降序
折线图 玩家在线数趋势 Y轴：去重计数（player_id），X轴：@timestamp

第四步：组装Dashboard

把上面这些图表放到一个Dashboard里，就是你的「游戏服务器监控大屏」了。我个人习惯把Dashboard分成几个区域：

  • 左上：实时错误数（最近5分钟）
  • 右上：错误趋势（24小时）
  • 左下：Top错误模块
  • 右下：最近报错日志列表

小技巧：Kibana的Dashboard支持自动刷新。设置成30秒刷新一次，基本就是实时监控了。另外，可以给Dashboard加一个「时间范围选择器」，方便快速切换查看不同时段的数据。

嗯，到这里，日志存储选型这块就讲完了。ES+Logstash+Kibana这套组合拳，说白了就是：Logstash负责收，ES负责存和查，Kibana负责看。三件套配合好了，游戏日志管理基本就稳了。下一章我们聊聊告警系统，那才是真正让日志「活起来」的关键。

← 上一章 📖 返回目录 下一章 →