【ELK】-6 ELFK 索引架构详解

文章目录

[ELFK 架构详解：为什么有了索引管理，还要创建索引模式？](#ELFK 架构详解：为什么有了索引管理，还要创建索引模式？)
- 一、从一个疑问说起
- 二、先搞清楚数据走到了哪一步
- [三、索引管理 vs 索引模式：两件事，不是一回事](#三、索引管理 vs 索引模式：两件事，不是一回事)
- - 举个例子
  - 为什么不自动全选？
- [四、常见误区：Data View 不会新建索引](#四、常见误区：Data View 不会新建索引)
- 五、完整流程：从日志采集到可视化
- - 实际操作步骤
- 六、深入：索引管理里为什么只有「一行」？
- - [6.1 Tag ≠ Index](#6.1 Tag ≠ Index)
  - [6.2 一行 ≠ 一条日志](#6.2 一行 ≠ 一条日志)
  - [6.3 Data View 的通配符优势](#6.3 Data View 的通配符优势)
  - [6.4 三者关系速查表](#6.4 三者关系速查表)
- 七、自查清单
- 八、总结

ELFK 架构详解：为什么有了索引管理，还要创建索引模式？

TL;DR

「索引管理」是 Elasticsearch 的事 ------确认数据到没到；「索引模式 / Data View」是 Kibana 的事------告诉 Kibana 你要查哪些数据。两者职责完全不同，缺一不可。

一、从一个疑问说起

很多初学者在搭建 ELK 时会遇到一个困惑：

Filebeat → Logstash → Elasticsearch → Kibana，链路都通了。在 Kibana 的 Stack Management → 索引管理 里已经能看到日志索引了，为什么还要再创建一个「索引模式」才能做可视化？

这个问题的答案，藏在 ELK 各组件的职责边界里。

二、先搞清楚数据走到了哪一步

完整的日志链路如下：

text 复制代码

业务服务器
    ↓
Filebeat        → 采集日志
    ↓
Logstash        → 过滤、解析、清洗
    ↓
Elasticsearch   → 真正存储日志的地方
    ↓
Kibana          → 查询与可视化

当你在 Kibana → Stack Management → 索引管理 看到类似 nginx-2026.08.16 或 filebeat-2026.08.16 的索引时，说明：

✅ 日志已经成功进入 Elasticsearch。 Filebeat → Logstash → Elasticsearch 这条链路已经打通。

但这只是"数据到了"，离"能用 Kibana 做可视化"还差一步。

三、索引管理 vs 索引模式：两件事，不是一回事

概念	归属	作用
索引管理（Index Management）	Elasticsearch	告诉你 ES 里现在有哪些数据
索引模式 / Data View	Kibana	告诉 Kibana 你要从哪些数据里做查询和可视化

举个例子

假设 Elasticsearch 里目前有这些索引：

text 复制代码

nginx-2026.08.15
nginx-2026.08.16
nginx-2026.08.17
mysql-2026.08.16
redis-2026.08.16

ES 知道它们都存在。但如果 Kibana 要做「Nginx 日志分析」，它需要知道：我要分析哪些索引？

于是你创建索引模式 nginx-*，意思是：

凡是名字匹配 nginx-* 的 ES 索引，都属于我这个数据视图。

text 复制代码

nginx-2026.08.15  ─┐
nginx-2026.08.16  ─┼──→  nginx-*   （Kibana 把它们作为一个整体查询）
nginx-2026.08.17  ─┘

为什么不自动全选？

假设你的 ES 里有 nginx-*、mysql-*、redis-*、kafka-*、audit-* 等多种日志。如果 Kibana 默认把所有数据混在一起（*），那你做「统计 HTTP 状态码」的图表时，结果里会混进 MySQL、Redis、Kafka 的日志------这显然不合理。

所以 Kibana 需要你明确告诉它：我要分析哪一类数据。 这就是 Data View 的意义。

💡 类比理解：ES 里的索引就像数据库里的表。索引管理是"数据库里有哪些表"，索引模式是"我接下来要从哪些表里查数据"。

四、常见误区：Data View 不会新建索引

"创建的索引模式是不是又创建了一个新索引？"

不是。 这是最容易混淆的一点。

比如 ES 里已经有 filebeat-2026.08.16，你在 Kibana 创建 filebeat-*，不会在 ES 里多出一个索引。Data View 只是 Kibana 保存的一条匹配规则：

text 复制代码

Kibana Data View
├── 名称：filebeat-*
└── 匹配：
    ├── filebeat-2026.08.16
    ├── filebeat-2026.08.17
    └── filebeat-2026.08.18

直观对比：

text 复制代码

Elasticsearch                      Kibana
│                                  │
├── filebeat-2026.08.15            └── Data View: filebeat-*
├── filebeat-2026.08.16                │
├── filebeat-2026.08.17                ├── filebeat-2026.08.15
└── nginx-2026.08.16                   ├── filebeat-2026.08.16
                                       └── filebeat-2026.08.17

Data View 是「选择器」，不是数据本身。

五、完整流程：从日志采集到可视化

把整个链路串起来：

text 复制代码

① Filebeat         → 采集日志
② Logstash         → 过滤、解析、清洗
③ Elasticsearch    → 存储日志
                       ├─ 索引管理里能看到 → ✅ 日志已到 ES
④ Kibana Data View → 告诉 Kibana：我要分析 nginx-* 这些数据
⑤ Discover         → 查看具体日志
⑥ Visualize / Lens → 把日志字段做成图表
⑦ Dashboard        → 把多个图表组合成监控大盘

在索引管理里看到数据，只完成了前半段。创建 Data View 后，才真正进入可视化阶段。

实际操作步骤

假设你在索引管理里看到 filebeat-2026.08.16：

进入 Kibana → Stack Management → Data Views，点击创建
输入名称：filebeat-*
选择时间字段：@timestamp
创建完成后，进入 Discover 页面
选择刚创建的 filebeat-*

此时你就能看到 Logstash 清洗后进入 ES 的日志了。整个 Filebeat → Logstash → ES → Kibana 链路正式闭环。

六、深入：索引管理里为什么只有「一行」？

"索引管理里只有一行，是不是就是我在配置文件里定义的 tag？"

这个观察非常关键。需要把 Tag、Index、Data View 三个概念彻底分开。

6.1 Tag ≠ Index

假设你的 Logstash 配置如下：

ruby 复制代码

input {
    beats {
        port => 5044
    }
}

filter {
    mutate {
        add_tag => ["nginx"]
    }
}

output {
    elasticsearch {
        hosts => ["http://localhost:9200"]
        index => "nginx-%{+YYYY.MM.dd}"
    }
}

这里有两个完全不同的东西：

ruby 复制代码

add_tag => ["nginx"]            # tag：日志事件上的标签，跟着日志走
index => "nginx-%{+YYYY.MM.dd}" # index：决定日志写入 ES 的哪个索引

Tag 只是日志事件上的一个标记，最终会出现在日志文档的 tags 字段里：

json 复制代码

{
  "@timestamp": "2026-08-16T08:30:00Z",
  "message": "GET /api/user 200",
  "host": "server01",
  "tags": ["nginx"]
}

而 Index 才是决定索引管理里出现什么的关键。配置 index => "nginx-%{+YYYY.MM.dd}"，ES 里就会出现 nginx-2026.08.16。

6.2 一行 ≠ 一条日志

假设 Filebeat 今天收集了 10 万条日志 ，全部写入 test-2026.08.16，索引管理里依然只有一行。因为：

一行 ≈ 一个 ES Index，里面可以包含成千上万条日志。

text 复制代码

test-2026.08.16（索引管理里的一行）
│
├── 日志 1
├── 日志 2
├── 日志 3
├── ...
└── 日志 100000

6.3 Data View 的通配符优势

假设索引管理里只有 test-2026.08.16，你创建 Data View test-*。明天 Logstash 又产生了 test-2026.08.17、后天产生 test-2026.08.18......你不需要重新创建 Data View ，因为 test-* 自动匹配所有日期：

text 复制代码

test-2026.08.16  ─┐
test-2026.08.17  ─┼──→  test-*（自动匹配，无需手动更新）
test-2026.08.18  ─┘

这就是生产环境偏爱 业务名-日期 命名方式的原因------配合 Kibana 的 业务名-* 通配符，天然支持按天滚动索引。

6.4 三者关系速查表

概念	作用	归属
Tag	给日志事件贴标签，用于分类和过滤	日志文档的字段
Index	ES 存放日志的容器，按日期滚动	Elasticsearch
Data View	告诉 Kibana 要查询哪些 Index	Kibana

完整关系链：

text 复制代码

Logstash 给日志加 tag → 输出到指定 index → ES 存储
                                              ↓
                              索引管理能看到 index
                                              ↓
                            Kibana 创建 Data View 匹配 index
                                              ↓
                                    Discover 查询日志
                                              ↓
                                Lens / Dashboard 可视化

七、自查清单

如果你还不确定索引管理里的「一行」到底是什么，对照这三点检查：

检查项	说明
Logstash `output` 里的 `index` 字段	决定 ES 里索引的名字，即索引管理里看到的内容
`add_tag` 配置	只是日志事件上的标签，不影响索引名
Kibana 索引模式怎么填	用 `业务名-*` 匹配上面的索引名

八、总结

问题	答案
为什么有了索引管理还要创建索引模式？	索引管理确认"数据到了没有"，索引模式告诉 Kibana"我要查哪些数据"。两者职责不同。
索引管理里只有一行是什么？	是一个 ES Index（由 Logstash 的 `index` 配置决定），不是 tag，也不是单条日志。
Data View 会创建新索引吗？	不会。它只是 Kibana 的一条匹配规则，是"选择器"而非数据本身。
为什么用通配符 `*`？	配合 `业务名-日期` 的索引命名，自动匹配所有日期的索引，无需每天手动更新。

一句话总结：Elasticsearch 负责"存"，Kibana 负责"看"。索引管理是 ES 的仓库清单，Data View 是 Kibana 的取货单------你得先告诉 Kibana 你要取哪些货，它才能帮你做可视化。