守株阁

上一篇（09）拆解了 pipeline 执行模型：worker 并发、batch 凑批、背压自然传导。这一篇进入队列本身：内存队列和持久队列的结构差异，崩溃时各自保住了什么、保不住什么，以及 at-least-once 语义的真实边界。 核心问题：开启持久队列（PQ）之后，Logstash 崩溃重启能恢复哪些 event，又有哪些情况它依然无能为力？ 两种队列的基本结构 Logstash pipeline 内部在 input 和 filter/output 之间有一个队列，起到解耦和缓冲的作用。队列类型由 logstash.yml（或 pipelines.yml）里的 queue.type 参数控制。 1234567891011121314Memory Queue（queue.type: memory）input thread ──▶ [ event | event | event | event | event ] ──▶ worker ↑ RAM 里的有界环形缓冲区 容量 =...

上一篇（08）覆盖了 Elasticsearch output 的 bulk 写入机制。这一篇进入 pipeline 执行模型本身：pipeline.workers、pipeline.batch.size、pipeline.batch.delay 三个参数各自控制什么，它们共同决定了 filter 和 output 阶段的并发方式；当下游变慢时，背压如何从 output 一路传回 input。 核心问题：为什么把 pipeline.workers 调大，有时吞吐上升、有时毫无变化甚至更差？ pipeline 执行结构 Logstash 的 pipeline 里有两类线程，职责分开、数量独立配置： 1234567891011121314input 线程（1 条或多条，取决于 input 插件） │ 每条 event 写入队列 ▼ ┌──────────────────────────────┐ │ queue（内存 / PQ） │ └──────────────────────────────┘ │ 每次拉取一批（...

上一篇把 filter 阶段的常用加工链梳理完：mutate 改写字段、date 覆盖 @timestamp、geoip 扩展地理信息、条件块用 tag 做分支路由。这一篇进入 output 阶段最常见的目标：Elasticsearch output 插件，重点是批量写入机制、索引命名策略、重试语义和背压来源。 核心问题：Logstash 如何把一批 event 打包成 Elasticsearch bulk 请求；索引模板与 data stream 如何决定文档落在哪个物理存储；哪些失败会被重试、哪些会真的丢掉 event；ES 的慢响应如何一路传导成 input 侧的减速。 数据流：event 从 filter 出口到 ES 的路径 123456789101112131415161718192021222324pipeline worker（同一线程内跑完 filter 再跑 output） │ ▼ 攒批边界：pipeline.batch.size 条 或 pipeline.batch.delay 到时 elasticsearch output plugin ...

上一篇讲完了 dissect 如何用分隔符驱动的线性扫描替代 Grok 的回溯正则，代价是无法处理非均匀格式。这一篇进入 filter 阶段最常见的后续加工链：mutate 改写字段、date 把日志时间戳覆盖 @timestamp、geoip 用 IP 换取地理信息，以及用条件判断和 tag 做分支路由。 核心问题：date filter 为什么一定要改写 @timestamp，而不是新增一个字段；条件判断和 tag 驱动的分支是 Logstash 唯一的路由原语，它和消息系统的 topic 路由有何本质区别。 数据流：event 经过 filter 链的变换过程 1234567891011121314 ┌──────────────────────────────────────────────────────┐ │ filter block │ │ ...

官方基准里，同条件单 filter 的 dissect 比 Grok 快一成到两成。这个数字小到不值得为它改配置。dissect 真正值钱的地方在另一头：它不用正则引擎，回溯那条会让单条 event 从微秒跳到秒级的路径在它这里根本不存在。 顺着这个判断往下，本篇落到三件具体的事：线性扫描的每一步怎么走、dissect 的语法能覆盖到哪、以及同一个管道里 dissect 和 Grok 怎么分工。 123456789101112131415同一行日志，两条处理路径：message: "2026-08-06T13:40:00 INFO pay-svc user=42 amount=99.50" │ ├── dissect ──── 找分隔符 ──── O(n) 线性扫描 ──── 字段 │ 无正则引擎 │ 无回溯 │ └── grok ─────── ...

Grok 的全部机制可以用一句话交代：%{PATTERN:field} 在管道启动时被递归展开成一段纯正则，字段名就是命名捕获组的组名，匹配交给一个回溯式正则引擎执行一次。它的性能上限、失败语义、调试手段都能从正则的性质直接推出来，不需要额外的心智模型。 这条线索往下追会落到三个具体问题：展开时哪些默认值决定了"到底有没有字段产出"、匹配失败与匹配超时为什么打的是两个不同的 tag、以及灾难性回溯除了"写 pattern 时小心"之外还有没有运行时的保险。 123456789101112131415161718192021222324input event message: "203.0.113.5 GET /api 200" │ ▼┌───────────────────────────────────────────┐│ grok filter ││ ...

input 层能给出多强的可靠性，由一件事决定："读到哪里"这个状态存放在哪里、在什么时刻推进。file input 把它写进本地 sincedb 文件；kafka input 交给 broker 侧的 consumer group；beats input 自己不存，靠 Filebeat 的 registry 配合一次 ACK 来推进。三种介质完全不同，推进时刻却停在同一条线上：event 进入 Logstash 内部队列，而不是写进下游成功之后。 这一篇沿这条线索展开三件事：sincedb 到底记了哪几列、beats 的 ACK 语义边界在哪里、kafka 的 offset 提交时机由哪个参数控制。顺带回答一个更靠前的问题——拉模型和推模型的分野，落到可靠性上究竟差在哪。 1234567891011121314151617┌──────────────────────────────────────────────────────────┐│ INPUT 层 ││...

multiline 只能是 codec，不能是 filter。这不是历史包袱留下的形状，是成帧这件事本身不可逆决定的：字节流一旦被切成离散 event 进了队列，行与行之间的先后关系就再没有载体，filter 拿到的每个 event 都是孤立的。 上一篇拆开了 event 的内部结构。这一篇往前退一步，看 event 是怎么被造出来的。顺着 codec 与 filter 的这条边界还会掉出一个大多数人记错的细节：默认的 plain codec 其实根本不按行切，按行切的是 line codec，而流式 input 在注册时会悄悄把前者换成后者。 数据流全景 123456789101112131415161718192021222324252627282930外部数据源 │ 字节流（TCP stream / 文件行 / UDP 包 / ...） ▼┌─ Input Plugin ───────────────────────────────────────────┐│ Codec: decode（字节 → event） ...

在 filter 里写 add_field => { "[@metadata][target_index]" => "logs-web" }，output 的 index => 里用 %{[@metadata][target_index]} 能取到值，但写进 Elasticsearch 的 _source 里找不到这个字段。这件事的机制既不在 output 插件里，也不在 codec 里，而在 Event API 上：org.logstash.Event 有两个平级的 ConvertedMap 字段 data 和 metadata，to_hash 返回的只是 data，要连 metadata 一起拿必须改调 to_hash_with_metadata。凡是走 to_hash 的下游，看到的就是一个没有 @metadata 的 event——不需要任何人动手剥离。 上一篇确立了 JRuby/JVM/多 pipeline 的运行形态和本系列的版本前提。这一篇进入 event 的内部结构：...

.conf 里声明的每个插件都是 Ruby gem，但把这些插件串起来执行的已经不是 Ruby 代码。Logstash 8.x 没有 Ruby 执行引擎——8.0 把它整个移除了。.conf 先由 ConfigCompiler 编译成 PipelineIR，再编译成由 Dataset 节点组成的 Java 执行图，插件的 filter/encode 方法是被这张图通过 JRuby 的 Java 互操作回调的。 上一篇确立了 event 与三段管道（input → filter → output）的核心抽象。这一篇顺着上面这道落差往下看两件事：插件是 Ruby gem 却跑在 JVM 上，在启动开销、线程模型和内存账上分别意味着什么；一个进程里多条 pipeline 的结构又是如何组织的。 版本前提 本系列的示例基于 Logstash 8.x，参数名与默认值以 8.19 分支的源码为准。 有一个设置会影响几乎每一篇的实验输出：pipeline.ecs_compatibility。Logstash 8 起它的默认值是 v8，所有实现了 ECS 兼容模式的插件都按 Elastic Co...