深入 Kibana 14 - 插件体系：New Platform 的 setup/start 生命周期
上一篇解决了 Spaces 与 RBAC 如何在平台层实施访问控制。这一篇进入 New Platform 的插件体系，核心问题是：一个 Kibana 插件如何声明依赖、如何向外暴露 contract、前后端插件的对称结构是什么样的，以及为什么要重构掉旧平台。 旧平台的问题 Kibana 5 到 7 早期，插件系统是有机生长出来的，没有统一的生命周期模型。每个插件在 init 函数里随意注册路由、随意拉取其他插件的引用、随意访问全局 server 对象。这带来三个结构性问题。 第一是循环依赖。插件 A 拉 B，B 拉 C，C 再拉 A。因为没有强制的声明式依赖，运行时才能发现环。第二是缺乏生命周期。所有插件的 init 在服务器启动时同步跑完，但没有清晰的"配置阶段"和"运行阶段"之分，导致在配置阶段就能访问运行时状态（反过来也是）。第三是没有类型安全。插件暴露给外部的 API 是任意 JavaScript 对象，没有类型约束，外部调用者无法静态感知接口变化。 New Platform（NP）从 Kibana 7.0 开始引入，7.x 期间与...
深入 Kibana 13 - Spaces 与安全：RBAC、Feature Controls 与多租户
上一篇剖析了 Task Manager 如何在多节点 Kibana 中调度后台作业。这一篇转入访问控制层面，核心问题是：Kibana 的 Spaces 提供怎样的隔离边界，RBAC 角色如何精确到"能在某个 Space 里看到哪些 Feature"这一粒度，以及 Saved Object 的空间归属在存储层怎么表达。 隔离需求的来源 一个 Elasticsearch 集群承载多个团队的数据是常态。但 Kibana 默认只有一个全局视图——所有 Dashboard、Index Pattern、Saved Search 堆在一起。团队 A 看到团队 B 的运维面板，不是安全问题（数据权限可以通过 ES 索引级别的角色控制），而是噪音问题。Spaces 的出发点是 UI 级别的组织隔离，不是数据安全隔离。安全隔离由 RBAC 叠加在 Spaces 之上实现。 架构总览 12345678910111213141516171819202122232425┌─────────────────────────────────────────────────┐│ ...
深入 Kibana（十二）：Task Manager——Kibana 内部的分布式任务调度
上一篇展示了 Reporting 作为 Task Manager 的具体用户。这一篇进入 Task Manager 本身，核心问题是：告警、上报、后台任务共用的调度器；任务如何在多 Kibana 实例间分配；与 cron 的区别。 Task Manager 的定位 Task Manager 是 Kibana 进程内的分布式任务调度器，7.4 版本引入，解决的问题是：Kibana 需要运行定期或一次性后台任务（告警检查、报表生成、ML 模型同步等），但不依赖外部消息队列或 cron 守护进程。 1234567外部 cron Kibana Task Manager───────────────────────── ──────────────────────────────────运行在 OS 层面 运行在 Kibana 进程内任务状态存在本机 任务状态存在 Elasticsearch多实例需额外协调 多实例通过 ES 乐观锁自动协调不感知 Kiba...
深入 Kibana（十一）：Reporting——从 Dashboard 到 PDF/PNG 的生成链路
上一篇展示了 Task Manager 调度的一种用途——驱动 Alerting Rule 周期执行。这一篇进入 Reporting，核心问题是：headless Chromium 渲染、报表任务队列、CSV 导出走的是搜索而非截图。 两条完全不同的生成路径 Kibana Reporting 对外提供两类产物，但底层实现路径截然不同： 12345678类型 触发源 生成方式 存储─────────────────────────────────────────────────────────────────PDF / PNG Dashboard headless Chromium .kibana + blob Visualize 截图 → PDF 合并 CanvasCSV Saved Search ES scroll / search_after .kibana + blob Dis...
深入 Kibana（十）：Alerting 框架——Rule、Connector 与 Action 的三段契约
上一篇解决了 Dashboard 的可视化组合逻辑。这一篇进入 Alerting 框架，核心问题是：Rule 定期执行、判定、触发 Action，Task Manager 怎么调度，告警状态怎么持久化。 Alerting 框架总览 Kibana Alerting（7.7 引入，8.x 重命名为 Kibana Alerting framework）把告警拆成三个可独立替换的契约： 1234567Rule Connector Action────────────────── ──────────────────── ────────────────────定义条件 + 调度周期 定义外部系统连接参数 定义向该系统发送的(what/when to check) (where to send) 消息模板 │ │ │ └──────── Alert Instance 触发后 ─────────...
深入 Kibana 09 - Dashboard 与 Embeddable：面板的组合与依赖
上一篇（第 08 篇）补全了可视化类型的全貌：Lens 覆盖通用场景，TSVB 专注时序，Vega 作为全自定义逃生舱。本篇回答的问题是：这些可视化如何被组合到一个 Dashboard 里；面板之间如何共享过滤状态；Dashboard Saved Object 的结构如何用 references 管理对可视化对象的依赖；URL 里的 rison 编码存了什么。 Embeddable 框架：任意内容的统一容器契约 Dashboard 不是一个专门为可视化设计的容器，它是 Embeddable 框架的消费者。 1234567891011121314Embeddable 框架的契约： 接口 IEmbeddable<TInput, TOutput> ├── input：Dashboard 传入的上下文（时间范围、过滤、查询） │ + 面板自身的配置（savedObjectId、size、title...） ├── reload()：重新执行查询 ├── render(node)：把自身渲染到指定 DOM 节点 └── getOutput()：向父容...
深入 Kibana 08 - TSVB、Timelion 与 Vega：时序与自定义可视化
上一篇（第 07 篇）展示了 Lens 的智能推断路径，覆盖了大多数通用可视化场景。本篇回答的问题是：当 Lens 的标准化模型不够用时，有哪些替代工具可用；这些工具在时序查询和自定义渲染上各自的边界在哪里；何时该选 TSVB，何时该用 Vega 直接接管数据与渲染。 三种工具的定位 1234Lens 通用推断型编辑器，覆盖大多数可视化场景，推荐首选TSVB 专为时序设计，多 panel 类型，支持 series 级聚合组合Timelion 时序表达式语言（已弃用），以 .es() 函数链为核心Vega 全自定义逃生舱，直接接管数据获取 + 图形渲染 这不是平行关系，而是"覆盖范围递增、配置复杂度也递增"的梯度。绝大多数场景从 Lens 开始即可；只有 Lens 的 layer 模型或标准图表类型无法满足时，才向 TSVB 或 Vega 下沉。 TSVB：时序可视化构建器 TSVB（Time Series Visual Builder）是一个以时序分析为核心的面板编辑器。它最直接的特征是支持多种 pane...
深入 Kibana 07 - Lens：拖拽背后的自动聚合推断
上一篇（第 06 篇）展示了 Visualize 手动配置聚合的模型：每一个 bucket aggregation 和 metric aggregation 都需要用户逐个展开下拉框选择。Lens 想回答的问题是：当用户把一个字段拖到画布上时，系统能不能根据字段类型直接给出一个合理的聚合方案，而不是等用户自己配？ 字段类型到聚合的映射 Lens 拿到一个字段后，它首先读取该字段在 Data View 里登记的类型。映射规则如下： 1234567字段类型 → 默认聚合keyword / ip / boolean → terms（top N 分组）date → date_histogram（时间分桶）number（metric 位置） → avgnumber（bucket 位置） → histogram / rangegeo_point → geotile_grid（地图场景） 这不是硬编码的枚举，而是 Lens 内部的 operation catalog。每种 operation 声明它...
深入 Kibana 06 - 聚合式可视化的老路：Visualize 与 bucket/metric
上一篇展示了 Discover 的执行模型——三类并发请求共享一个父 Search Source，文档检索与直方图各自用子 Search Source 覆盖差异。这一篇进入聚合式可视化。聚合式可视化容易被误解成"拖几个字段选一种图表类型"。更准确的说法是：Visualize 里的每一张图都是对 Elasticsearch 聚合 API 的一次声明——图表类型只是渲染方式，图形背后的数据来自一棵 ES aggregation tree；bucket 聚合决定 X 轴的分组方式，metric 聚合决定 Y 轴的数值，嵌套 bucket 就是树的多层分叉。本文只抓一个问题：bucket 嵌套如何映射到 ES 的 aggregation 树结构，以及 Visualize 作为这条旧路的设计模型——因为理解它，才能理解 Lens 为什么要重新设计。 每张图 = 一次聚合查询 Visualize 编辑器里，用户通过"Buckets"和"Metrics"两组配置描述一张图。这组配置直接对应 ES 的 aggregations 请求体：...
深入 Kibana 05 - Discover：交互式检索的执行模型
上一篇建立了 KQL→DSL 的翻译管道——Search Source 把 KQL、Lucene query string 和过滤器 pills 组装成一个合法的 ES 请求体。这一篇进入 Discover。Discover 容易被误解成"就是个搜索框加日志表格"。更准确的说法是：Discover 是一个多请求编排的 UI 状态机——打开一次 Discover 并不是发一次 ES 请求，而是至少发三类请求：field_caps 请求（字段侧边栏）、date_histogram 聚合请求（顶部直方图）、以及 document search 请求（文档表格）；每次条件变化，三类请求都会按依赖顺序触发。本文只抓一个问题：字段列表怎么来、直方图怎么算、翻页为什么用 search_after，以及这三件事背后共用的 Search Source 父子结构。 Discover 的请求拓扑 123456789101112131415161718192021222324252627282930用户打开 Discover（或改变条件） │ ├─...
