深入 Kibana（十）：Alerting 框架——Rule、Connector 与 Action 的三段契约
一条 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) 消息模板 │ ...
深入 Kibana 09 - Dashboard 与 Embeddable：面板的组合与依赖
单张可视化只有进入 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-...
深入 Kibana 08 - TSVB、Timelion 与 Vega：时序与自定义可视化
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）是一个以时序分析为核心的面板编辑器...
深入 Kibana 07 - Lens：拖拽背后的自动聚合推断
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...
深入 Kibana 06 - 聚合式可视化的老路：Visualize 与 bucket/metric
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 → ...
深入 Kibana 05 - Discover：交互式检索的执行模型
打开 Discover 不等于只发出一次搜索请求。字段侧边栏、顶部直方图和文档表格各自需要不同的数据，它们围绕同一查询状态触发 field caps、聚合与文档检索。Discover 的核心因此更接近多请求编排器，而不是“搜索框加表格”。 Discover 的请求拓扑 123456789101112131415161718192021222324252627282930用户打开 Discover（或改变条件） │ ├─── [1] field_caps 请求 │ GET /<index-pattern>/_field_caps?fields=* │ → 返回每个字段的类型和能力集 │ → 驱动左侧字段侧边栏渲染 │ 触发条件：Data View 切换、mapping 变化 │ ├─── [2] date_histogram 聚合请求（直方图） │ POST /<index-...
深入 Kibana 04 - Search Source 与查询翻译：KQL、Lucene 与 Query DSL
在 Kibana 查询栏输入的 KQL 并不会原样交给 Elasticsearch。KQL、Lucene query string 和过滤器 pills 会先在 Kibana 内部转换，再由 Search Source 组装成 Query DSL 请求。查询语法、过滤器状态以及 query/filter context 的差异，都在这条翻译链上汇合。 本文讨论的是 Discover 的经典查询模式。切换到 ES|QL 模式后，查询直接面向索引运行，不要求先选择 Data View，也不经过下面这条 KQL/Lucene 翻译链。 翻译管道全局模型 123456789101112131415161718192021222324252627282930313233用户输入层 ├── KQL (Kibana Query Language) e.g. status:200 AND method:GET ├── Lucene query string e.g. status:200 AND method:GET (相同写法, 不同解析器) └── 过滤器...
深入 Kibana 03 - Data View：查询之前的字段抽象
Elasticsearch mapping 只描述字段在索引中的物理类型，Kibana 还需要知道默认时间字段、显示格式和运行时扩展。Data View 位于这两层之间，把一组索引转换成可供 Discover、Lens 等应用消费的字段语义模型。它远不止一个索引名称配置项。 Data View 在链路里的位置 123456789ES 物理索引 Data View (SO) Kibana UI────────────────── ────────────────────────── ──────────────────────logs-app-2026.08.* → title: "logs-app-*" → Discover 字段列表logs-app-2026.07.* timeField: "@timestamp" KQL 自动补全metrics-host-* field...
深入 Kibana 02 - Saved Object：一切状态的统一模型
Dashboard、Data View、Lens 配置和告警规则看起来分属不同功能，落到持久化层却共享同一套 Saved Object 协议。它用 type、attributes、references 和版本迁移机制管理跨插件状态，避免每个功能各自设计一套存储格式。导入、导出与升级迁移也由这层协议统一承接。 Saved Object 的结构 每个 Saved Object 在 .kibana 系列索引里是一条 ES 文档，其 _id 格式为 <type>:<uuid>，_source 里携带固定的元数据字段加上一个以 type 命名的嵌套对象存放实际载荷： 1234567891011Saved Object 文档结构（_source）────────────────────────────────────────────────type "dashboard" # 类型标识，对应注册的 SO 类型id "a1b2c3d4-..." # ...
深入 Kibana 01 - 架构：浏览器、Node.js server 与 platform
Kibana 3 曾让浏览器直接连接 Elasticsearch，Kibana 4 以后却在中间加入了 Node.js server。这个变化不只是部署形态调整：凭据隔离、后台任务、报表生成和插件生命周期都需要一个应用服务层。沿着一次浏览器请求向下追踪，才能看清三层架构各自承担的职责。 三层结构 请求从浏览器出发，经过 Node.js server，最终到达 Elasticsearch。每一层的职责边界如下： 12345678Browser Node.js Server Elasticsearch─────────────────── ────────────────────────── ───────────────────────React UI (plugins) ──► HTTP routes / auth proxy ──► .kibana system indicesKQL / Lens editor Saved Objects service business i...
