第3章 日志收集与解析

日志格式五花八门，解析起来头疼不？我最早接触安全分析时，面对上千台服务器的日志格式不统一，差点崩溃。后来才发现，只要摸清几种主流格式的脾性，配合合适的工具链，这事就没那么玄乎。

这一章，咱们把日志的「骨架」拆开看看。JSON、CSV、Syslog 这三种格式，再加上 Filebeat 和 Logstash 的配置套路，最后聊聊字段提取和清洗的那些坑。

3.1 主流日志格式

你想想看，日志本质就是一行行带有时间戳的事件记录。只是不同系统偏好不同格式罢了。

格式	特点	典型场景	解析难度
JSON	结构化、键值对、可嵌套	Web 应用、API 网关、微服务	低
CSV	扁平、字段固定、分隔符	网络设备日志、旧版应用	中（字段顺序敏感）
Syslog	头部+消息体、RFC 3164/5424	Linux 系统、网络设备	中高（消息体非标）

JSON 格式 是我最喜欢的。字段名和值清清楚楚，Logstash 里一个 json { source => "message" } 就搞定了。但要注意，有些应用会把 JSON 嵌在一行普通文本里，得先过滤掉前缀。

CSV 格式：看似简单，但字段顺序一变就全乱。我的习惯是先在配置文件里写死列名映射，绝不允许「猜字段」。比如：

filter {
  csv {
    columns => ["timestamp", "src_ip", "method", "url", "status", "size"]
    separator => ","
    convert => { "status" => "integer" }
  }
}

Syslog 格式 是历史遗留产物。RFC 3164 的头部格式是 <PRI>时间 主机名 进程[PID]: 消息。我遇到过好几回，设备厂商在消息体里塞了自定义的 JSON，得用双重解析。

3.2 Filebeat 配置实战

Filebeat 是采集端的轻量级选手。我一般只让它干三件事：读日志、传日志、加少量元数据。要解析的事交给后端的 Logstash。

下面这段配置是我压箱底的模板，直接拿去改改就能用：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/access.log
  fields:
    log_type: "nginx_access"
  fields_under_root: true

output.logstash:
  hosts: ["192.168.1.10:5044"]

# 注意：不要在这里做复杂处理，例如 dissect/grok
# 这些事留给 Logstash 专心做

有个细节：fields_under_root: true 能让自定义字段直接挂在顶级，Logstash 那边拿到 key 就省事多了。早期我把字段嵌在 fields 层里，Logstash 还得拆一层，麻烦。

3.3 Logstash 管道：从输入到输出

Logstash 的 pipeline 由三个阶段组成：input → filter → output。我建议在 filter 阶段做全部解析，output 只负责转发。

一个典型的 filter 链示例：

filter {
  # 1. 从 message 中初步提取时间戳
  date {
    match => ["timestamp", "ISO8601", "yyyy-MM-dd HH:mm:ss"]
    target => "@timestamp"
  }

  # 2. 解析 JSON 负载
  json {
    source => "json_payload"
    target => "parsed"
  }

  # 3. 拆解 URL 参数
  urldecode {
    field => "[parsed][request_uri]"
  }

  # 4. 四舍五入去噪
  mutate {
    convert => { "status" => "integer" }
    sanitize => "remove"
  }
}

顺序很重要！我习惯把时间戳解析放第一位，因为后面所有操作都可能依赖正确的 @timestamp。

3.4 字段提取与清洗

这一步直接决定后续异常检测的数据质量。字段提取的三大金刚：Grok、Dissect、正则。

• Grok：基于预定义模式，可读性好；但性能比 Dissect 差，适合不固定的行。
• Dissect：基于定长分隔符，速度快；适合格式固定的日志（比如 Nginx access.log）。
• 正则：最灵活，也最慢；我一般只用于处理变种文本。

方法	性能	可读性	适用场景
Grok	中等	高	Syslog、混合格式
Dissect	高	中	Nginx、Apache 日志
正则	低	低	极端不规则文本

清洗是什么？简单说就是去掉垃圾数据、修正异常值、统一大小写。我常用的 mutate 操作包括：gsub 替换空格、coerce 强制类型、remove_field 丢掉无用字段。

3.5 日志收集解析的知识体系

把上面的流程串起来，就构成了一套轻量、清晰的日志流水线。我画了张图方便你理解：

瞧，左边是原始日志，Filebeat 负责采集并传输，Logstash 在中间完成解析和清洗，最后输出标准化的字段。这个模式我在多个生产环境里验证过，扩展性强，也容易横向扩容。

3.6 避坑指南

最后分享三个我犯过的错，希望你绕开：

1. 别在 Filebeat 里做重解析。Filebeat 的内存和 CPU 资源有限，一旦日志量暴增，解析逻辑会拖垮整个采集进程。把解析扔给 Logstash 或 Elasticsearch pre-processing。
2. 时间戳时区别忘配。我遇到过日志里写的是 UTC，但 Logstash 默认按服务器本地时区解析，结果时间差了半天。加一行 timezone => "Asia/Shanghai" 就解决。
3. 测试阶段就开启死信队列。Logstash 解析失败会直接丢弃事件。我在生产的 Kafka 主题里发现少了一堆日志，排查半天才发现是某个新格式没被 grok 模式覆盖。加上 dead_letter_queue 吧，失败的事件留作调试。

把这块练熟，你的异常检测就相当于站在了「干净」的数据地基上。后续的统计分析、机器学习模型才不会因为脏数据而跑偏。