守株阁

上一篇讲完了 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...

Kibana 从浏览器直连 Elasticsearch 的纯前端应用，逐步演化成带 Node.js 服务、插件平台和 Serverless 交付形态的完整产品。每次架构变化都对应上一阶段无法承受的约束，也引入新的复杂度。收尾篇沿版本脉络回看这些取舍，并标出哪些设计已经退出当前主线。 Kibana 3：无服务端，浏览器直连 Kibana 3 发布于 2014 年，是一个纯前端应用。部署方式是把静态文件丢进任意 Web 服务器或 Elasticsearch 的 site plugin 目录，浏览器直接向 ES 的 REST 接口发 HTTP 请求。 这个架构的优点是极度简单：没有额外运行时依赖，没有状态管理问题，没有服务端语言选型。 它的结构性缺陷有三条。 第一，安全问题。浏览器直连 ES，意味着 ES 的地址和凭据必须暴露给每一个打开页面的用户。任何能看到 Kibana 页面的人都能直接操作 ES。在公网或多用户环境里，这是不可接受的。 第二，状态无处安放。Dashboard 定义存在哪里？Kibana 3 的解法是把 Dashboard JSON 存回 Elasticsearch...

Kibana 与 Grafana 都能做可视化和告警，底层假设却不同。Kibana 仍然围绕 Elasticsearch 深度集成，Grafana 13.x 继续保持 datasource-first。版本号往前走，架构分叉没变。 架构起点的分叉 Kibana 和 Grafana 都是可视化平台，都有 Dashboard、Panel、告警，但它们的架构起点完全不同，导致几乎所有设计决策都走向了不同方向。 Kibana 的起点是"Elasticsearch 的前端"。即使经过多次重构，它的状态（Saved Objects）存在 ES 里，它的查询模型围绕 ES 的 aggregation 体系构建，它的 Data View 是对 ES 索引模式的映射。ES 是 Kibana 唯一的数据后端，也是它的持久化存储。这种深度绑定让 Kibana 能充分利用 ES 的全文检索、嵌套 aggregation、异步搜索、PIT 等特性，但代价是：换掉 ES，Kibana 就什么都不是了。 Grafana 的起点是"不同数据源的统一可视化层"。它自己用 S...

插件数量增长会直接推高前端包体和启动成本，长查询又要求结果能够在页面离开后继续保存。Kibana 的性能治理因此同时覆盖 bundle 拆分、bootstrap 顺序和后台搜索。这里的“搜索会话”在 8.15 起已经进入弃用路径，9.0 默认关闭，9.2 之后由 background search 接棒。本篇把首屏加载与后台查询放在一张性能模型里讨论。 前端 bundle 体系 Kibana 的前端代码量巨大。Discover、Lens、Dashboard、Maps、Security、Observability 加在一起，编译后的 JavaScript 体积以百 MB 计。如果把所有代码打成一个 bundle 让用户一次性下载，首屏时间会无法接受。 Kibana 的解法是三层 bundle 结构。 12345678910111213浏览器请求 Kibana 页面│├── bootstrap.js 核心 shell，极小，总是先加载│ └── 初始化运行时，注册模块加载器，决定加载哪些插件│├── core bundle 平台公共服务│ ...