深入 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...
深入 Logstash 00 - 导读：核心对象是 event，骨架是三段管道
Logstash 常被当成"把日志灌进 Elasticsearch 的那个工具"，学习方式往往是抄一段 logstash.conf、改几个 Grok 正则、跑通就算会了。这条路能用起来，但解释不了几个问题：为什么同样一份配置，pipeline.workers 调大有时提升吞吐、有时毫无变化？为什么下游 Elasticsearch 变慢，会反过来让 input 端读取变慢？持久队列到底在崩溃时保住了什么、又保不住什么？ 这些问题的答案都不在插件参数表里，而在两个更底层的抽象上：Logstash 处理的核心对象是 event，处理的骨架是 input-filter-output 三段管道。event 是一个带 @timestamp 的结构化文档，是管道里流动的最小单位；三段管道规定了字节怎么变成 event、event 怎么被加工、加工完的 event 怎么发往下游。codec、Grok、队列、批处理、背压这些机制，全都是围绕"event 在三段管道里怎么流"展开的。 本系列只抓一个问题：Logstash 这套以 event 为核心对象、以三段...
深入 Kibana 00 - 导读：Kibana 的状态存在 Elasticsearch 里
Kibana 常被介绍为"Elasticsearch 的图形界面"或"ES 的可视化前端"。这个说法把 Kibana 的位置放低了一层，也解释不了几个基本现象：为什么 Kibana 要自带一个 Node.js 服务，而不是像 Kibana 3 那样纯浏览器直连 ES？为什么在浏览器里保存一张 Dashboard，会往 Elasticsearch 里写一条数据，而这条数据又不出现在业务索引里？为什么升级 Kibana 大版本时，它会在启动阶段做一轮"迁移"，动的却是 ES 里的某些系统索引？ 更准确的说法是：Kibana 是一个后端在 Elasticsearch、前端在浏览器、而自身状态也存在 Elasticsearch 里的三层应用平台。用户在界面上建的每一个 Data View、拖的每一张可视化、组的每一个 Dashboard、配的每一条告警规则，都不是存在浏览器本地、也不是存在某个独立数据库，而是以 Saved Object 的形式写进以 .kibana 为前缀的系统索引。Kibana 把 Elasticsearch...
OpenAI 与 Anthropic 知识库研究进展深度对比
大模型的知识库能力在过去两年里经历了快速迭代。OpenAI 和 Anthropic 作为这个领域最有代表性的两家公司，走出了截然不同的技术路线。一家押注"窗口越大越好"，另一家选择"检索越准越好"。这种分歧不是表面的产品差异，而是反映了对"如何让 AI 有效利用外部知识"这一基本问题的不同回答。 从时间跨度上看，2023 年底到 2026 年中这段时间是知识库能力爆发式增长的阶段。两家公司几乎每个季度都有新的能力发布，而且技术路线的分化越来越明显。 这里说的"知识库"不仅仅指 RAG 或向量数据库，而是涵盖了从文档存储、检索、记忆管理到工具连接的整个链路——所有让 AI 系统能够有效利用外部知识的技术。 OpenAI：用规模碾压复杂度 OpenAI 在知识库方向上的核心策略可以概括为一句话：把上下文窗口做大，把基础设施做全，让用户把文档直接塞进去。 这个策略的底层逻辑并不复杂：如果模型能一次性「看到」所有相关信息，那检索这个步骤就变得多余。 而 OpenAI 恰好拥有最强的算力基础设施来支撑这个方向。...
