2、日志采集基础：日志文件格式、轮转策略与采集工具选型

日志采集，说白了就是给服务器装个“黑匣子”。没有它，你连游戏出了啥问题都搞不清楚。我刚开始做运维那会儿，就吃过这个亏——服务器半夜挂了，翻遍硬盘找不到一份完整的日志，那叫一个抓狂。

这一章，咱们就把日志采集的底子打扎实。从文件格式到轮转策略，再到工具选型，一步到位。

2.1 日志文件格式：TXT、CSV、JSON

日志格式决定了你后续解析的难度。选对了，事半功倍；选错了，天天加班。

2.1.1 纯文本格式（TXT）

最原始的格式，一行一条记录。优点是啥？简单，任何编辑器都能打开。缺点也很明显——解析全靠正则，字段一多就乱套。

2025-03-21 14:30:01 [INFO] 玩家[张三] 登录成功，IP:192.168.1.100
2025-03-21 14:30:05 [WARN] 玩家[李四] 登录失败，原因:密码错误
2025-03-21 14:30:10 [ERROR] 数据库连接超时，重试第3次

2.1.2 CSV格式

用逗号分隔字段，结构比TXT清晰一些。适合表格化数据，比如玩家充值记录、在线时长统计。

时间戳,日志级别,玩家ID,事件类型,详情
2025-03-21 14:30:01,INFO,10001,登录,成功
2025-03-21 14:30:05,WARN,10002,登录,密码错误
2025-03-21 14:30:10,ERROR,,数据库,连接超时

CSV有个坑——字段里如果包含逗号或换行符，解析就会出问题。嗯，这里要注意，一定要用引号包裹或者转义。

2.1.3 JSON格式（强烈推荐）

这是目前游戏服务器日志的“标准答案”。结构清晰，支持嵌套，解析起来也方便。Elasticsearch、Logstash这些工具对JSON的支持都非常好。

{
  "timestamp": "2025-03-21T14:30:01.123Z",
  "level": "INFO",
  "player_id": 10001,
  "event": "login",
  "result": "success",
  "ip": "192.168.1.100",
  "duration_ms": 45
}

2.2 日志轮转策略

日志如果不轮转，硬盘迟早被撑爆。我见过最夸张的一次，某台服务器日志文件涨到了200GB，直接把磁盘写满了，游戏进程直接崩溃。从那以后，轮转策略就成了我上线前的必检项。

2.2.1 基于时间的轮转

按时间切分，比如每小时、每天生成一个新文件。适合日志量比较稳定的场景。

2.2.2 基于大小的轮转

文件达到指定大小就切分，比如每100MB生成一个新文件。适合日志量波动大的场景。

# log4j2 配置示例
<RollingFile name="RollingFile" fileName="logs/server.log"
             filePattern="logs/server-%d{yyyy-MM-dd}-%i.log.gz">
  <SizeBasedTriggeringPolicy size="100 MB"/>
  <DefaultRolloverStrategy max="20"/>
</RollingFile>

2.2.3 混合策略

实际生产环境中，我通常采用“时间+大小”混合策略。比如：每天轮转一次，但如果单个文件超过200MB，也立即轮转。这样既控制了文件数量，又避免了单个文件过大。

2.3 采集工具选型：Filebeat、Logstash、Fluentd

工具选型这事儿，没有银弹。我根据实际项目经验，把三款主流工具的特点整理了一下。

2.3.1 Filebeat（轻量级首选）

Filebeat是Elastic公司出品的轻量级日志采集器。它的设计哲学就是“轻”——占用资源少，部署简单。

• 优点： 内存占用低（通常几十MB），CPU开销小，适合部署在游戏服务器上
• 缺点： 功能相对单一，只能做采集和简单过滤，复杂处理需要配合Logstash
• 适用场景： 大规模部署，每台游戏服务器都需要采集日志

# filebeat.yml 配置示例
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/game/*.log
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

output.elasticsearch:
  hosts: ["http://localhost:9200"]

2.3.2 Logstash（全能型选手）

Logstash功能最强大，支持各种输入、过滤、输出插件。说白了，它就是日志处理界的“瑞士军刀”。

• 优点： 过滤能力强，支持grok正则解析、数据转换、字段丰富
• 缺点： 资源消耗大（Java写的），配置复杂，不适合直接部署在游戏服务器上
• 适用场景： 日志清洗、格式转换、复杂过滤逻辑

# logstash.conf 配置示例
input {
  beats {
    port => 5044
  }
}

filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} \[%{LOGLEVEL:level}\] %{GREEDYDATA:message}" }
  }
  date {
    match => [ "timestamp", "ISO8601" ]
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "game-logs-%{+YYYY.MM.dd}"
  }
}

2.3.3 Fluentd（云原生之选）

Fluentd是CNCF（云原生计算基金会）的项目，在Kubernetes环境中用得特别多。它的插件生态也很丰富，性能介于Filebeat和Logstash之间。

• 优点： 插件丰富，内存管理好，支持热加载配置
• 缺点： 社区相对Elastic Stack小一些，中文资料较少
• 适用场景： Kubernetes环境、需要与云原生生态集成的场景

# fluentd.conf 配置示例
<source>
  @type tail
  path /var/log/game/*.log
  pos_file /var/log/fluentd/game.log.pos
  tag game.logs
  <parse>
    @type json
  </parse>
</source>

<match game.logs>
  @type elasticsearch
  host localhost
  port 9200
  logstash_format true
  logstash_prefix game-logs
</match>

2.3.4 选型对比表

好了，日志采集的基础就聊到这儿。下一章咱们进入实战环节——怎么用ELK搭建一套完整的日志分析平台。到时候我会把踩过的坑、总结的经验都抖出来。