9.1 Logstash 与 Beats：数据的进站口

9.1 Logstash 与 Beats：数据的进站口

本节摘要：Beats 是装在服务器上的轻量采集器，把日志、指标搬运到管道；Logstash 是重装加工厂，输入、过滤、输出三段流水线完成解析、补字段、按规则路由到不同索引。本节讲管道全景与分工取舍、Logstash 配置的完整写法，并实操解析一份 nginx 访问日志。数据进站口的原理，就是第 4 章写入之旅的车流版。

数据从哪里来

管道全景与分工

前面八章的数据都靠手工写入，生产的常态是车流：采集、加工、进站、出站一条龙。

进站与出站全景

选择题只有一道：格式干净、无需加工的，Beats 直连引擎；要解析、富化、多路由的，中间加 Logstash——多一套组件就多一份运维，加工需求才是它的门票。

Logstash 三段配置

input {
  beats { port => 5044 }        # 接各服务器上的采集器
}
filter {
  grok { match => { "message" => "%{IP:client_ip} %{WORD:method} %{URIPATHPARAM:uri} %{NUMBER:status:int} %{NUMBER:cost_ms:int}" } }
  date { match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ] target => "@timestamp" }
  mutate { add_field => { "env" => "prod" } remove_field => [ "message" ] }
}
output {
  if [status] >= 500 {
    elasticsearch { hosts => ["es-prod:9200"] index => "errors-%{+YYYY.MM.dd}" }
  } else {
    elasticsearch { hosts => ["es-prod:9200"] index => "access-%{+YYYY.MM.dd}" }
  }
}
​

三段各司其职：input 收（beats、文件、消息队列都行）；filter 加工——grok 用模式把单行日志切成结构化字段（IP、方法、路径、状态码、耗时），date 把日志里的时间设为事件时间（这一步不做，所有事件的时间都是进站时刻，时序全错），mutate 补环境字段、删原始报文省空间；output 按条件路由——五开头的状态码进 errors 索引，其余进 access，索引名带日期后缀自然按天滚动（第 3 章的按月索引思路）。

一次日志解析的完整实操

背景：运维要看"每分钟五错误的趋势与耗时分布"，现状是原始行日志堆在一个索引里，字段没拆开。操作：服务器装文件采集器指向 Logstash；过滤段按上面的 grok 模式解析，date 归一事件时间，mutate 把耗时转整数；输出按天滚动索引，模板预注册（字段类型显式声明，第 3 章的纪律）。结果：第二天起 Kibana 里状态码、耗时、客户端 IP 都是独立字段，按分钟直方图与耗时百分位（第 6 章的语法）直接出图。解读：解析的价值在把"文本"变"字段"——字段才能过滤、聚合、画图；grok 模式是正则的封装，宁可多花一小时调准模式，不要让脏数据进索引（类型错了要重建，第 3 章的教训）。变式：超高流量时 grok 的正则开销可观，改用采集器直接输出结构化日志或引入解析缓存；无法改应用日志格式时，dissect 按定界符切分比 grok 快数倍。

⚠️ 常见坑：忘了配 date 归一事件时间，全部事件以进站时间落库，凌晨导入的历史日志"发生在未来"，时序图变抽象画。凡有时序诉求的管道，date 段是必选项。

💡 关键直觉：管道的每一站都在做同一道题——离结构化更近一步。采集端做不到的交给过滤端，过滤端做不到的（比如业务字段）只能回到应用端打日志。结构化做得越早，下游每一站越省力。

考核与自测

考核知识点清单

动手验证：管道的验收自检

管道上线前按顺序核四件事，每件都有对应的观察点：

第一步 采集端确认 在源服务器看采集器日志 有无发送阻塞或反复重连
第二步 加工端确认 发一条样例日志 看出口事件的字段是否拆全
第三步 存储端确认 在引擎侧按天核对索引文档数 与源端条数对账
第四步 口径确认 抽一条文档核对其时间字段是事件时间而非进站时间
​

四步全绿才算管道可用；任何一步对不上，顺着链路向上一站排查，比在引擎侧盲目调参快得多——链路思维是本章给运维习惯的最大改变。把这份自检固化成上线检查单，新人接手管道也能按图索骥，不再依赖"老师傅的直觉"。

易错点补充

• 索引模板没预注册：按天滚动的新索引第一天就触发动态推断，字段类型漂移，登记表的纪律在管道场景的第一课。
• 解析模式贪婪套用：一条复杂日志套错模式，未命中部分带病上线，先在测试流跑通再放量。
• 持久化队列当摆设：不开队列洪峰一来采集端丢数据，开了不监控水位，洪峰一来先撑爆的是队列盘。
• 采集器与加工端版本错配：跨大版本的事件格式有差异，升级要整条链路一起排期，别让单点先行造成静默丢字段。
• 同一份数据两头入库：既直连引擎又走加工端，同一事件重复出现，对账前先查链路有没有分叉。
• 加工规则无版本管理：过滤段配置随手改、不留痕，解析结果悄悄变化，管道配置要进版本库与代码同权评审。

进站口收工

• Beats 轻采集装在源头，Logstash 重加工放中间，直连或中转取决于加工需求。
• 三段配置：input 收、filter 加工（grok 切字段、date 归时间、mutate 补删）、output 条件路由按天滚动。
• 事件时间必须显式归一，否则时序失真。
• 洪峰靠队列与引擎侧板斧共同消化，管道是常设不是应急。

数据进站了，下一节看它怎么体面地出站：Kibana 的三件套与各语言客户端。