守株阁

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

上一篇（05）把 Grok 的本质还原成命名正则加 pattern 别名库，说清了 Oniguruma 回溯在复杂 pattern 下的性能风险。这一篇进入 dissect filter，回答核心问题：dissect 按分隔符切分为什么比 Grok 快、两者的选型边界在哪里、以及如何把两者组合起来在结构化前缀和可变尾部之间取得最优的吞吐与覆盖。 123456789101112131415同一行日志，两条处理路径：message: "2026-08-06T13:40:00 INFO pay-svc user=42 amount=99.50" │ ├── dissect ──── 找分隔符 ──── O(n) 线性扫描 ──── 字段 │ 无正则引擎 │ 无回溯 │ └── grok ─────── 展开 pattern → 正则匹配 ──── 字段 ...

上一篇（04）讲清了 input 插件如何把外部数据拉进管道并交给 codec 生成 event。这一篇进入 filter 层的核心插件：Grok。集中回答三个问题：%{PATTERN:field} 是怎么展开成正则的、Grok 匹配失败时 _grokparsefailure tag 从哪里来、以及 Grok 的性能瓶颈在哪里、怎么避免灾难性回溯。 12345678910111213141516171819202122232425input event message: "203.0.113.5 GET /api 200" │ ▼┌───────────────────────────────────────────┐│ grok filter ││ ││ match => { "message" => "%{IP:clien...

上一篇（03）讲清了 codec 作为字节与 event 边界转换器的角色。这一篇进入 input 插件层，回答一个集中问题：file input 如何用 sincedb 追踪读取位点、beats input 的 ack 机制如何实现 at-least-once、kafka input 的消费位点和消费组是怎么回事——以及这三种机制背后"拉模型 vs 推模型"的根本差异。 12345678910111213141516┌──────────────────────────────────────────────────────────┐│ INPUT 层 ││ ││ PULL 模型 PUSH / LISTEN 模型 ││ file ──┐ beats ──...

上一篇确立了 event 的内部结构：业务字段、系统保留字段与 @metadata 三层分离。这一篇进入 codec 层。codec 容易被误解成"就是格式化输出，和 filter 差不多"。更准确的说法是：codec 是字节流与 event 之间的边界转换器，解决的是"如何把连续字节流切割成离散 event"的成帧问题，这个问题在数据进入 filter 之前就必须解决，任何 filter 都无法替代。本文只抓一个问题：codec 与 filter 的分工边界在哪里，以及 multiline 为什么必须是 codec 而不是 filter。 数据流全景 1234567891011121314151617181920212223242526272829303132333435外部数据源 │ │ 字节流（TCP stream / 文件行 / UDP 包 / ...） ▼┌─────────────────────────────────────────────┐│ Input Plugin ...

上一篇确立了 JRuby/JVM/多 pipeline 的运行形态。这一篇进入 event 的内部结构。event 容易被误解成"就是一个 JSON 对象"。更准确的说法是：event 是 Logstash 在管道内部流通的核心数据单元，由 Java 对象实现，包含业务字段、系统保留字段（@timestamp、@version）和管道内部暂存区（@metadata），三者在语义上截然不同。本文只抓一个问题：event 的字段空间如何分层，以及 @metadata 为什么不进最终输出。 数据流全景 1234567891011121314151617181920212223242526272829303132333435363738Input (stdin/beats/kafka/...) │ │ bytes ▼ [ Codec: decode ] │ │ 构造 Event 对象 ▼┌────────────────────────────────────────────...

上一篇确立了 event 与三段管道（input → filter → output）的核心抽象。这一篇进入 Logstash 的运行时层。运行时层容易被误解成"不就是个脚本引擎"。更准确的说法是：Logstash 是跑在 JVM 上的 JRuby 应用，插件是 Ruby gem，核心逻辑有相当比例用 Java 写成，两者通过 JRuby 的 Java 互操作机制在同一进程里协作。本文只抓一个问题：插件是 Ruby gem 却跑在 JVM 上意味着什么，以及一个 Logstash 进程里多 pipeline 的结构如何组织。 数据流全景 12345678910111213141516171819202122OS 进程边界┌──────────────────────────────────────────────────────────────────────┐│ Logstash Process (JVM) ││ ...

上一篇完成了 Kibana 与 Grafana 的外部对比。这一篇是系列的收尾，核心问题是：Kibana 从 Kibana 3（无 server）到 Kibana 4（Node server）到旧平台（5–7）到 New Platform（7.x–8.x）再到 Serverless，每一步在解决什么结构性约束，牺牲了什么。 Kibana 3：无服务端，浏览器直连 Kibana 3 发布于 2014 年，是一个纯前端应用。部署方式是把静态文件丢进任意 Web 服务器或 Elasticsearch 的 site plugin 目录，浏览器直接向 ES 的 REST 接口发 HTTP 请求。 这个架构的优点是极度简单：没有额外运行时依赖，没有状态管理问题，没有服务端语言选型。 它的结构性缺陷有三条。 第一，安全问题。浏览器直连 ES，意味着 ES 的地址和凭据必须暴露给每一个打开页面的用户。任何能看到 Kibana 页面的人都能直接操作 ES。在公网或多用户环境里，这是不可接受的。 第二，状态无处安放。Dashboard 定义存在哪里？Kibana 3 的解法是把 Dashboard ...

上一篇完成了 Kibana 平台内部机制的全貌，覆盖了 bundle 加载序列和异步搜索会话。这一篇转向外部对比，核心问题是：单一后端深度集成（Kibana）与多数据源统一抽象（Grafana）各自解决什么问题，DataSource 模型的差异在哪里，告警模型如何不同。 架构起点的分叉 Kibana 和 Grafana 都是可视化平台，都有 Dashboard、Panel、告警，但它们的架构起点完全不同，导致几乎所有设计决策都走向了不同方向。 Kibana 的起点是"Elasticsearch 的前端"。即使经过多次重构，它的状态（Saved Objects）存在 ES 里，它的查询模型围绕 ES 的 aggregation 体系构建，它的 Data View 是对 ES 索引模式的映射。ES 是 Kibana 唯一的数据后端，也是它的持久化存储。这种深度绑定让 Kibana 能充分利用 ES 的全文检索、嵌套 aggregation、异步搜索、PIT 等特性，但代价是：换掉 ES，Kibana 就什么都不是了。 Grafana 的起点是"不同数据源...

上一篇展示了 New Platform 的插件体系如何通过 setup/start 生命周期和 contract 模式组织代码。这一篇进入性能模型，核心问题是：首屏加载的 bundle 体积如何控制、插件如何按需加载，以及 Search Session 如何让长查询可以后台运行并复用结果。 前端 bundle 体系 Kibana 的前端代码量巨大。Discover、Lens、Dashboard、Maps、Security、Observability 加在一起，编译后的 JavaScript 体积以百 MB 计。如果把所有代码打成一个 bundle 让用户一次性下载，首屏时间会无法接受。 Kibana 的解法是三层 bundle 结构。 12345678910111213浏览器请求 Kibana 页面│├── bootstrap.js 核心 shell，极小，总是先加载│ └── 初始化运行时，注册模块加载器，决定加载哪些插件│├── core bundle 平台公共服务│ └── http client · savedObjects ...