守株阁

插件数量增长会直接推高前端包体和启动成本，长查询又要求结果能够在页面离开后继续保存。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 平台公共服务│ ...

访问控制划定了插件能做什么，插件平台本身还要解决依赖、生命周期和对外契约。Kibana 的 platform/core 体系通过清单声明依赖，并把启动过程拆成 setup、start 和 stop。这个模型取代了旧平台依赖全局对象与任意初始化顺序的做法。 旧平台的问题 Kibana 5 到 7 早期，插件系统是有机生长出来的，没有统一的生命周期模型。每个插件在 init 函数里随意注册路由、随意拉取其他插件的引用、随意访问全局 server 对象。这带来三个结构性问题。 第一是循环依赖。插件 A 拉 B，B 拉 C，C 再拉 A。因为没有强制的声明式依赖，运行时才能发现环。第二是缺乏生命周期。所有插件的 init 在服务器启动时同步跑完，但没有清晰的"配置阶段"和"运行阶段"之分，导致在配置阶段就能访问运行时状态（反过来也是）。第三是没有类型安全。插件暴露给外部的 API 是任意 JavaScript 对象，没有类型约束，外部调用者无法静态感知接口变化。 Kibana platform（旧称 New Platform, NP）从 Kiban...

多个团队共用同一套 Kibana 时，页面组织、对象可见性和操作权限不能混成一个概念。Spaces 为 Saved Object 提供命名空间，RBAC 决定用户能做什么，Feature Controls 则裁剪可见功能。三层组合后，Kibana 才具备平台级多租户能力。 隔离需求的来源 一个 Elasticsearch 集群承载多个团队的数据是常态。但 Kibana 默认只有一个全局视图——所有 Dashboard、Index Pattern、Saved Search 堆在一起。团队 A 看到团队 B 的运维面板，不是安全问题（数据权限可以通过 ES 索引级别的角色控制），而是噪音问题。Spaces 的出发点是 UI 级别的组织隔离，不是数据安全隔离。安全隔离由 RBAC 叠加在 Spaces 之上实现。 架构总览 12345678910111213141516171819202122232425┌─────────────────────────────────────────────────┐│ Kibana Server ...

Alerting 和 Reporting 已经两次碰到 Task Manager：一个需要周期检查规则，一个需要排队生成报表。Task Manager 是两者共用的进程内分布式调度器，负责任务注册、认领、并发控制和重试。本篇把此前的前向引用收回来，专门分析多 Kibana 实例如何协调后台作业。 Task Manager 的定位 Task Manager 是 Kibana 进程内的分布式任务调度器，7.4 版本引入，解决的问题是：Kibana 需要运行定期或一次性后台任务（告警检查、报表生成、ML 模型同步等），但不依赖外部消息队列或 cron 守护进程。 1234567外部 cron Kibana Task Manager───────────────────────── ──────────────────────────────────运行在 OS 层面 运行在 Kibana 进程内任务状态存在本机 任务状态存在 Elasticsearch多实例需额外协调 ...

Reporting 同样借助 Task Manager 排队执行，但 PDF/PNG 与 CSV 走的是两条不同链路。前者需要 headless Chromium 打开页面并截图，后者直接执行搜索并写出数据。第 12 篇会回到共用的任务调度器，这里只处理报表生成自身的边界。 两条完全不同的生成路径 Kibana Reporting 对外提供两类产物，但底层实现路径截然不同： 12345678类型 触发源 生成方式 存储─────────────────────────────────────────────────────────────────PDF / PNG Dashboard headless Chromium .kibana + blob Visualize 截图 → PDF 合并 CanvasCSV Saved Search ES PIT + search_after .kibana +...

一条 Kibana 告警规则要经历周期执行、条件判定和 Connector 动作三个阶段。Rule 与 Action 的契约负责业务语义；规则本身保存在 .kibana，而真正生成出来的 alert 文档会遵循 Alerts as Data schema 写到 .alerts-* alias。后台调度由 Task Manager 承担；调度器的内部机制留到第 12 篇集中展开。本篇先沿着一次规则执行观察状态如何产生、持久化并触发外部动作。 Alerting 框架总览 Kibana Alerting 把告警拆成三个可独立替换的契约： 1234567Rule Connector Action────────────────── ──────────────────── ────────────────────定义条件 + 调度周期 定义外部系统连接参数 定义向该系统发送的(what/when to check) (where to send) 消息模板 │ ...

单张可视化只有进入 Dashboard 才会与其他面板共享时间范围、过滤条件和布局状态。当前的 Embeddable 体系已经不是旧式 class 继承模型，而是服务端和前端分别注册的 React 组件 + 可发布的 TypeScript API；Dashboard 负责持久化状态并把最后一次保存的 state 传回去。Saved Object references 负责保存对象依赖。URL 里的 _g、_a 则承接可分享的会话状态。 Embeddable 框架：任意内容的统一容器契约 Dashboard 不是一个专门为可视化设计的容器，它是 Embeddable 框架的消费者。 12345678910Embeddable 当前的契约： 1. server / public 双注册： registerEmbeddableServerDefinition / registerEmbeddablePublicDefinition 2. public 侧以 React component + publishing packages 暴露 API， 不是 class-...

Lens 覆盖了常见可视化，但复杂时序计算和完全自定义渲染仍需要其他工具。TSVB、Timelion 与 Vega 来自不同设计年代，查询表达、渲染控制权和维护状态也不相同。现在的新建首选是 Lens；TSVB 主要承接少数复杂时序场景，Timelion 则只适合作为历史参考或存量迁移对象。 三种工具的定位 1234Lens 通用推断型编辑器，覆盖大多数可视化场景，推荐首选TSVB 专为时序设计，多 panel 类型，支持 series 级聚合组合Timelion 时序表达式语言（历史/legacy），以 .es() 函数链为核心Vega 全自定义逃生舱，直接接管数据获取 + 图形渲染 这不是平行关系，而是"覆盖范围递增、配置复杂度也递增"的梯度。绝大多数场景从 Lens 开始即可；只有 Lens 的 layer 模型或标准图表类型无法满足时，才向 TSVB 或 Vega 下沉。 TSVB：时序可视化构建器 TSVB（Time Series Visual Builder）是一个以时序分析为核心的面板编辑器...

Visualize 要求使用者逐项选择 bucket 和 metric，Lens 则尝试从字段类型和当前画布状态推断合理方案。一次拖拽会触发 operation 匹配、维度约束和可视化建议排序。Lens 的价值不只在交互更轻，而在于它把聚合知识编码进了推断流程。 字段类型到聚合的映射 Lens 拿到一个字段后，它首先读取该字段在 Data View 里登记的类型。映射规则如下： 1234567字段类型 → 默认聚合keyword / ip / boolean → terms（top N 分组）date → date_histogram（时间分桶）number（metric 位置） → avgnumber（bucket 位置） → histogram / rangegeo_point → geotile_grid（地图场景） 这不是 UI 里写死的一张枚举表，而是 Lens datasource 和 operation 定义共同给出的兼容结果。当前 Lens 插件位于 x-pack/pl...

Discover 解决的是文档检索，Visualize 则把 Elasticsearch aggregation tree 映射成图表。bucket 决定如何分组，metric 决定如何计算，嵌套 bucket 继续扩展聚合树；图表类型只负责渲染结果。理解这条旧的手工配置路径，才能看懂 Lens 后来改掉了什么。 每张图 = 一次聚合查询 Visualize 编辑器里，用户通过"Buckets"和"Metrics"两组配置描述一张图。这组配置直接对应 ES 的 aggregations 请求体： 1234567891011121314151617181920212223242526272829303132333435用户在 Visualize 里的配置 Metrics └── Y-axis: Average of bytes → metric agg: avg { field: bytes } Buckets ├── X-axis: Date Histogram on @timestamp → ...