01-ELK Stack 简介与架构

ELK Stack 最初指 Elasticsearch、Logstash、Kibana 三个组件：Elasticsearch 负责存储、搜索和分析，Logstash 负责采集和处理数据，Kibana 负责查询和可视化。后来 Beats、Elastic Agent、Integrations、Ingest Pipeline、Fleet、APM、Security、Observability 等能力加入，官方更常用 Elastic Stack 或 Elastic Platform 来描述这套体系。

这篇作为系列第一篇，不急着安装，也不把每个组件写成百科。真正需要先理解的是：一条日志从业务系统产生后，如何被采集、解析、标准化、写入、索引、查询、展示和告警；哪些场景需要 Logstash，哪些场景 Beats 或 Elastic Agent 直接写入就够；为什么 Elasticsearch 的分片、副本、索引模板和生命周期策略会影响后续所有文章。

后续 02 会讲 Elasticsearch 安装与配置，03 讲 Logstash 管道，04 讲 Kibana 可视化，05 讲 Filebeat 采集。本篇只建立架构边界和选型判断，避免一开始就陷入命令细节。

从“日志平台”到“可观测性数据平台”

图：Elastic Stack 的核心不是某个单点工具，而是采集、处理、存储、查询和展示之间的责任分工。

很多团队第一次接触 ELK，是为了集中日志。应用服务器上有 Nginx 日志、Java 异常日志、系统日志、数据库慢查询、容器日志，分散在不同机器上，排障时要到处 SSH。ELK 的第一价值，是把这些日志集中起来，并提供跨主机、跨时间、跨字段的搜索。

但现代 Elastic Stack 已经不只是日志平台。它可以处理日志、指标、APM trace、安全事件、审计日志、业务事件和搜索数据。官方 Elastic Stack 页面也把它描述为由 Elasticsearch、Kibana、Beats、Logstash 等组成，用于从任意来源采集数据，再搜索、分析和可视化。这个定位决定了架构设计不能只看“能不能收日志”，还要看数据模型、生命周期、权限、容量和使用场景。

从运维角度看，ELK 的价值可以分为四层：

如果只做到第一层，ELK 很容易变成昂贵的全文搜索网盘。真正稳定的平台必须往结构化、关联分析和治理走。

核心组件的责任边界

Elasticsearch 是核心存储和搜索引擎。官方文档称它是分布式、JSON 文档型搜索和分析引擎。对日志平台来说，它负责接收事件、建立索引、执行查询、聚合统计、按时间保留数据。Elasticsearch 不是简单数据库，它的索引、分片、副本、映射和生命周期会决定性能、成本和稳定性。

Logstash 是服务器端数据处理管道。它擅长把来自多种输入的数据解析、过滤、转换、丰富后输出到 Elasticsearch 或其他系统。Logstash 的典型结构是 input、filter、output。它适合复杂解析、字段转换、查表补充、条件路由和多目标输出，但资源开销比轻量采集器更高。

Kibana 是界面层。它让用户通过 Discover 查询数据，通过 Data View 选择索引，通过 Lens 和 Dashboard 做可视化，通过告警、管理和解决方案视图完成更高层操作。Kibana 的价值不是“画图”，而是让不同角色能用同一套数据排障、分析和复盘。

Beats 是轻量采集器家族，Filebeat 用于日志文件，Metricbeat 用于指标，Auditbeat 用于审计，Heartbeat 用于可用性探测。现在很多场景也会使用 Elastic Agent 和 Integrations，用统一 Agent 接入多类数据。选 Beats 还是 Elastic Agent，要看团队是否需要 Fleet 管理、集成包和更统一的运维方式。

这几个组件的边界可以这样理解：

边界不清会造成架构失衡。比如把所有解析都压给 Elasticsearch ingest pipeline，可能难以维护复杂逻辑；把所有日志都先过 Logstash，可能增加不必要延迟和资源；把原始非结构化日志直接写入 Elasticsearch，Kibana 后面就只能做全文搜索。

现代数据流

图：现代 Elastic Stack 常见链路是 Agent/Beats 在边缘采集，Logstash 或 ingest pipeline 处理，Elasticsearch 存储搜索，Kibana 分析展示。

常见数据流有三种。

第一种是轻量直写：

Filebeat 或 Elastic Agent -> Elasticsearch -> Kibana

它适合格式相对标准、解析简单、吞吐不太复杂的场景。比如 Nginx、系统日志、容器标准输出、常见中间件日志。优点是链路短、延迟低、部署简单；缺点是复杂清洗和丰富能力有限。

第二种是 Logstash 中转：

Filebeat 或 Agent -> Logstash -> Elasticsearch -> Kibana

它适合需要复杂 grok、字段重命名、查字典、补充 CMDB 字段、根据条件写入不同索引、同时输出到多个系统的场景。优点是处理能力强；缺点是多一层服务，需要容量、队列、监控和高可用。

第三种是消息队列缓冲：

Agent/Beats -> Kafka 或 Redis -> Logstash -> Elasticsearch -> Kibana

它适合日志量大、峰值明显、下游需要保护、跨网络区域采集的场景。队列能吸收峰值和短暂故障，但也引入延迟、积压和运维成本。不是所有 ELK 都需要 Kafka，只有当峰值、可靠性和解耦需求明确时才引入。

架构选型的关键不是“哪个最完整”，而是“当前日志量、解析复杂度、可靠性要求和团队能力匹配哪条链路”。

Elasticsearch 的核心模型

图：索引由主分片和副本分片组成，分片设计会影响写入、查询、扩容和恢复。

Elasticsearch 存储的是 JSON 文档。文档进入索引，索引被拆成分片，分片分布在节点上，副本提供高可用和查询扩展。日志类数据通常按时间写入数据流或时间序列索引，再通过生命周期策略滚动和删除。

理解几个概念很重要：

新手常见错误是没有提前设计 mapping。日志全部作为动态字段写入，看似方便，后面会遇到字段类型冲突、聚合失败、存储膨胀和查询慢。比如 status 有时是字符串，有时是数字；response_time 有时带单位，有时是纯数字；message 里混杂 JSON 字符串。越早结构化，后面 Kibana 越好用。

分片也不能随便设。分片太多会增加集群开销，分片太大影响恢复和查询。日志平台要根据每日数据量、保留周期、节点数量和查询模式设计。小规模环境不要为每个应用每天建很多小索引；大规模环境也不要把所有日志写到一个无限增长的索引。

Logstash 的位置

图：Logstash 的价值在 input、filter、output 三段中体现，尤其适合复杂解析、字段转换和条件路由。

Logstash 不应该被理解成“必须经过的一层”。它是强大的处理层，但不是所有数据都需要它。判断是否需要 Logstash，可以问四个问题：

1. 是否需要复杂 grok 或多格式解析。
2. 是否需要查 CMDB、GeoIP、字典或外部服务补字段。
3. 是否需要按条件输出到多个目标。
4. 是否需要队列、缓冲和失败重放能力。

如果答案都是否，Filebeat 或 Elastic Agent 直写 Elasticsearch 可能更简单。如果答案有多个是是，Logstash 就值得引入。

Logstash 的典型价值是把非结构化日志变成结构化事件。比如 Nginx access log 变成 client.ip、http.request.method、url.path、http.response.status_code、event.duration。一旦字段结构化，Kibana 才能做聚合、筛选和仪表板。

但 Logstash 也要治理。复杂 grok 规则会变成新技术债；过滤器顺序会影响性能；异常日志会进入 dead letter 或失败队列；高峰时 pipeline worker、batch size、队列和 JVM 内存都要监控。03 篇会展开这些细节。

Kibana 不是最后一步，而是反馈入口

Kibana 经常被当成“看图工具”，但它更像数据质量反馈入口。Discover 里搜不到字段，说明采集或解析有问题；Lens 做不了聚合，说明 mapping 有问题；Dashboard 指标不稳定，说明数据源或字段语义不统一；告警误报多，说明查询条件和数据模型需要调整。

Kibana 的常见使用路径是：

1. 在 Discover 中确认数据是否进来。
2. 创建 Data View，让 Kibana 理解索引或数据流。
3. 用 KQL 或 Lucene 查询定位事件。
4. 用 Lens 做趋势、Top N、分布和对比。
5. 组合 Dashboard 给值班或业务使用。
6. 设置告警或保存查询，形成复用。

这条路径说明 Kibana 依赖前面所有环节。采集不稳、字段混乱、时间戳错误、索引命名随意，都会在 Kibana 暴露出来。04 篇会重点讲如何从 Data View、Discover 和 Dashboard 入门。

数据模型：尽量向 ECS 靠拢

Elastic Common Schema，通常简称 ECS，是 Elastic 对字段命名和语义的一套公共约定。日志平台不一定一开始完全遵守 ECS，但应该尽量向它靠拢。比如主机用 host.name，服务用 service.name，日志级别用 log.level，HTTP 状态码用 http.response.status_code，客户端 IP 用 client.ip。

为什么重要？因为统一字段名能让不同来源的数据一起查。Nginx、Java 应用、网关、容器、APM 如果都使用不同字段表示服务名和状态码，Kibana 看板就需要为每个来源写一套查询。字段统一之后，跨系统分析才有可能。

字段设计至少要约定：

没有字段约定，ELK 只能做“搜字符串”；有字段约定，ELK 才能做可观测性分析。

架构选型示例

小团队或学习环境：

Filebeat -> Elasticsearch -> Kibana

目标是快速看到日志和字段。重点是时间戳、索引模板、基础 Dashboard，不要一开始引入过多组件。

中等规模企业内部日志平台：

Filebeat/Elastic Agent -> Logstash -> Elasticsearch -> Kibana

目标是统一解析、多业务接入、字段标准化、权限和生命周期治理。Logstash 负责复杂处理，Elasticsearch 负责稳定存储，Kibana 提供多团队使用入口。

大规模或跨区域平台：

Agent/Beats -> Kafka -> Logstash -> Elasticsearch 集群 -> Kibana

目标是抗峰值、解耦、可重放和跨区域可靠性。此时要治理队列积压、消息顺序、重复写入、索引生命周期和多集群策略。

安全分析场景可能更偏 Elastic Security 和 Elastic Agent，APM 场景可能引入 APM Server 或 OpenTelemetry。不要把所有可观测性问题都硬塞进传统 ELK 三件套。系列后续仍以日志平台基础为主。

生产平台要考虑的非功能需求

ELK 架构不只是功能组件，还要考虑非功能需求：

日志平台最大的成本通常是存储。所有日志永久保留在热节点上不可持续。要按价值分层：高频查询保留短期，历史审计进入温冷层或快照，低价值 debug 日志缩短保留。生命周期策略会在 02 和后续文章里继续展开。

安全也不能后补。日志里可能包含 Token、手机号、客户数据、内部 IP、SQL、错误堆栈。采集前应尽量脱敏，写入后按索引和空间授权。Kibana 能让很多人方便查询，也意味着权限必须细。

数据生命周期：热数据和历史数据不是一回事

日志平台最常见的失败不是“收不到日志”，而是“收到了太多日志，存不起，也查不动”。日志数据有明显时间价值：故障发生后的几小时最有价值，最近几天用于排障和复盘，几周前的数据用于趋势和审计，更久的数据可能只需要归档。

因此架构里必须有生命周期意识。典型分层是：

Elastic 的 ILM 可以让索引按大小、时间和阶段滚动。架构导入阶段就要确定不同日志类型的保留策略。比如生产错误日志保留 30 天，访问日志保留 14 天，审计日志保留 180 天，debug 日志只保留 3 天。不要所有数据一个策略。

生命周期还影响索引设计。如果没有 Data Stream 或 rollover，索引可能无限增长；如果每天给每个应用建索引，小团队又可能产生大量小分片。架构设计要在查询便利、分片数量和生命周期之间取平衡。

时间戳是日志平台的地基

ELK 中最重要的字段通常是 @timestamp。它应该表示事件发生时间，而不是 Filebeat 采集时间、Logstash 处理时间或 Elasticsearch 写入时间。时间戳错了，Kibana 时间范围、告警窗口、趋势图和故障复盘都会错。

常见问题包括：

因此每条采集链路都要验证时间戳。导入后在 Kibana 用 Discover 随机抽几条事件，看 @timestamp 是否与日志原文一致。对补采数据，要标明采集时间和事件时间的差异，避免历史事件触发当前告警。

权限模型：谁能看哪些日志

日志经常包含敏感信息。即使应用本身权限严格，日志平台如果对所有人开放，也会绕过原系统权限。架构阶段要设计权限模型。

常见做法是按空间、索引模式、团队和数据敏感度授权：

Kibana Space 可以帮助隔离不同团队的可视化资产，但数据权限仍要落实到 Elasticsearch 索引和字段。不要只靠 Dashboard 隐藏敏感字段。用户如果能直接 Discover 查询索引，就可能看到完整原始日志。

权限还要考虑外部系统接入。比如 Dify 日志分析工作流、自动报表、告警通知机器人，它们使用的账号也应该最小权限。机器账号不应拥有管理员权限。

高可用和灾难恢复

学习环境可以单节点，生产平台不能只看“服务启动”。Elasticsearch 至少要考虑节点故障、磁盘故障、网络隔离、索引损坏、误删除和升级失败。

副本能处理节点故障，但副本不是备份。误删除索引、错误生命周期策略、错误写入覆盖，副本会同步错误。真正的备份需要快照。生产平台应规划快照仓库、快照频率、恢复演练和保留周期。

Logstash 高可用通常靠多实例和上游负载均衡，或通过消息队列削峰。Filebeat/Agent 要处理下游不可用时的缓冲和重试。Kibana 本身也可以多实例部署，但它依赖 Elasticsearch 保存配置和会话状态。

灾难恢复要回答：

1. Elasticsearch 集群不可用时，采集端能缓冲多久？
2. 快照多久一次，恢复到哪里？
3. 误删索引后谁有权限恢复？
4. Logstash 配置如何回滚？
5. Kibana Dashboard 是否有导出备份？

没有这些答案，平台上线后遇到第一次大故障会非常被动。

多环境和多集群

不要让开发、测试、生产日志混在一起。至少要在字段、索引或集群层面区分环境。常见字段是 service.environment 或 labels.env。索引命名也应体现数据集和环境，例如 logs-nginx-prod-*、logs-app-test-*。

小规模可以一个集群承载多环境，通过权限和索引区分。生产规模较大时，建议生产和非生产分集群，避免测试日志量或错误配置影响生产查询。安全数据和普通应用日志也可能需要独立集群或独立权限域。

多集群还涉及跨集群搜索、跨地域复制和集中看板。不要一开始就设计过度复杂的全球架构。先确定数据主权、网络延迟、故障域和团队运维能力，再决定是否多集群。

容量估算方法

容量估算可以从几个数字开始：

粗略公式是：

所需存储 ≈ 每日数据量 × 膨胀系数 × (1 + 副本数) × 保留天数

这只是起点。真实容量还要看压缩、字段数量、doc_values、分片开销、快照和磁盘水位。架构设计时至少要有估算，否则很容易上线几周后磁盘爆满。

容量估算还要反过来约束采集范围。不是所有 debug 日志都值得进中心平台；不是所有业务字段都需要全文索引；不是所有历史数据都要热查询。可观测性平台要服务排障和分析，而不是无限保存一切。

常见反模式

第一个反模式是“所有日志写一个索引”。短期方便，长期字段冲突、权限混乱、生命周期无法区分。

第二个反模式是“每个应用每天一个索引”。小规模还行，应用多了会产生大量小分片，集群管理成本升高。

第三个反模式是“只保留 message 字段”。这样 Kibana 只能全文搜索，无法聚合接口、状态码、服务名和耗时。

第四个反模式是“所有采集都过 Logstash”。简单日志不需要复杂管道，过度集中会让 Logstash 成为瓶颈。

第五个反模式是“不做脱敏”。日志平台聚合了大量系统数据，如果没有脱敏和权限，很容易变成敏感信息泄露入口。

第六个反模式是“Dashboard 代替数据治理”。图表能画出来，不代表字段准确、时间正确、口径统一。

第七个反模式是“没有生命周期策略”。这会让热节点越来越满，查询越来越慢，最后通过临时删索引救火。

认识这些反模式，比背组件功能更重要。

从一条日志看完整链路

以一条 Nginx 访问日志为例：

1. Nginx 写入本地 access log。
2. Filebeat 读取文件，记录 offset，附加主机和文件路径元数据。
3. Filebeat 使用模块或 input 配置解析部分字段，或发送给 Logstash。
4. Logstash 使用 grok、date、mutate 等过滤器解析方法、路径、状态码、耗时和客户端 IP。
5. Logstash 输出到 Elasticsearch 数据流。
6. Elasticsearch 按模板应用 mapping，把状态码作为 long 或 keyword，把时间写入 @timestamp。
7. Kibana Data View 识别这组数据。
8. 用户在 Discover 查询 http.response.status_code >= 500。
9. Dashboard 聚合 5xx 趋势和 Top URL。
10. 告警规则发现 5xx 比例超过阈值，通知值班。

这条链路中任何一步出错，最终用户看到的问题都不同。采集错是没有数据，解析错是字段不存在，时间错是查不到窗口，mapping 错是无法聚合，权限错是用户看不到，Dashboard 错是指标失真。架构理解的意义就在于能定位这些问题。

架构交付清单

ELK 架构设计完成后，至少应留下这些内容：

这份清单能避免“ELK 装好了但没人知道怎么用”。平台建设不是安装组件，而是让数据进入、变干净、查得到、看得懂、管得住。

查询路径决定数据建模

很多团队先采集日志，再问“我们能查什么”。更好的做法是反过来：先列出常用查询，再决定字段和索引。日志平台的价值来自查询路径。

典型查询包括：

如果这些字段没有结构化，查询就会退化为全文搜索。全文搜索能救急，但不适合作为长期可观测性能力。架构设计时要让应用团队知道：日志输出格式也是接口。应用日志不是随便打印给人看的文本，而是给平台解析和分析的事件。

结构化日志优先级通常高于复杂解析。应用能直接输出 JSON，采集链路就更简单；如果只能输出传统文本，再用 Logstash 或 ingest pipeline 解析。不要让平台长期为每个应用维护复杂正则，而应用端完全不治理日志格式。

字段冲突和动态映射

Elasticsearch 支持动态映射，这让初次写入很方便，也带来风险。第一个写入的值可能决定字段类型。比如 response_time 第一条是字符串 "12ms"，后面再写数字 12 就可能冲突；status 一会儿是 "200"，一会儿是 200，也会造成查询和聚合困难。

字段冲突的表现包括：

解决方式是使用索引模板和字段规范。生产数据流不应完全依赖动态映射。至少核心字段要显式定义：时间、服务、主机、日志级别、状态码、耗时、trace ID、用户 ID、事件类型。

对于未知扩展字段，可以使用命名空间，例如 labels.*、custom.*，并限制字段数量。日志平台最怕字段爆炸。容器标签、请求参数、动态 JSON 如果全部展开成字段，会显著增加 mapping 压力。

从 PoC 到生产的路线

ELK PoC 可以很轻：单节点 Elasticsearch、一个 Kibana、一个 Filebeat，采集一台机器日志，做一个 Dashboard。PoC 的目标是验证字段、查询和使用价值，不是证明生产架构。

生产路线可以分四步：

第一步，单应用验证。选择一个日志格式相对稳定、业务价值明确的系统。采集、解析、展示、告警闭环跑通。

第二步，多应用标准化。沉淀字段规范、索引命名、采集模板、Dashboard 模板和权限模型。不要每个应用各搞一套。

第三步，平台化接入。提供接入文档、采集配置模板、字段验收、容量评估和生命周期策略。应用团队按规范接入。

第四步，运营治理。看数据量、成本、慢查询、失败写入、字段冲突、告警质量和用户使用情况。定期清理低价值日志和废弃 Dashboard。

这条路线能避免一个常见问题：PoC 成功后直接全量推广，结果字段混乱、容量爆炸、权限失控。ELK 很容易“装起来”，难的是“长期管住”。

Elastic Cloud、自建和 OpenSearch 的边界

当前可选路线不止自建 Elastic Stack。Elastic Cloud 提供托管 Elasticsearch 和 Kibana，减少集群运维；自建适合对数据位置、网络、安全和成本有明确要求的团队；OpenSearch 是另一条生态路线，来自 Elasticsearch/Kibana 早期分支，适合希望走 OpenSearch 生态的团队。

本系列聚焦 Elastic Stack 基础概念和自建入门，但架构判断仍要客观：

不要把选型讨论简化为“哪个免费”。日志平台的真实成本包括节点、存储、备份、值班、升级、故障恢复、权限治理和人员学习。托管服务贵一些，但可能节省运维成本；自建看似省许可，但需要团队承担复杂度。

如果团队只是学习，本地自建最好；如果是生产系统，先评估数据规模、合规、预算和运维能力，再决定路线。

与 Prometheus、Grafana 的关系

ELK 不等于全部可观测性。Prometheus 更擅长指标采集和告警，Grafana 擅长多数据源可视化，Tempo/Jaeger 擅长 trace，Loki 擅长轻量日志。Elastic Stack 的优势是搜索、日志分析、统一数据检索和 Kibana 生态。

很多企业会组合使用：

不要强行用 ELK 替代所有工具。它可以承载日志和部分可观测性，但架构上应允许与指标和 Trace 系统互补。比如日志里保留 trace.id，就能把 ELK 和链路追踪关联起来。

日志平台的组织协作

ELK 平台不是运维一个团队的事。应用团队要输出规范日志，平台团队要维护采集和存储，安全团队要审查敏感信息，业务团队要确认看板口径。

建议建立接入流程：

1. 应用团队提交数据源、日志样例、预计量级和查询需求。
2. 平台团队评估采集方式、字段映射、索引策略和保留周期。
3. 安全团队检查敏感字段和访问范围。
4. 双方在测试环境验证采集、解析和 Dashboard。
5. 上线后观察数据量、错误率和查询效果。

没有流程时，ELK 会变成“谁想接就接”。结果是字段乱、索引乱、权限乱、成本不可控。平台化能力需要入口治理。

第一篇的验收问题

读完本篇，应该能回答这些问题：

• Elasticsearch、Logstash、Kibana、Beats/Agent 各自负责什么；
• 为什么现代 Elastic Stack 不只是传统 ELK 三件套；
• 哪些场景需要 Logstash，哪些可以直写 Elasticsearch；
• 为什么 @timestamp、mapping、索引模板和生命周期重要；
• 为什么日志字段要尽量对齐 ECS；
• 如何估算日志平台容量；
• 为什么权限和脱敏必须在架构阶段处理；
• PoC 和生产架构有什么差异；
• ELK 与 Prometheus/Grafana/OpenSearch/Elastic Cloud 的边界在哪里；
• 后续四篇分别解决什么问题。

如果这些问题回答不清，直接进入安装和配置很容易走偏。组件能启动只是起点，数据能被正确治理才是平台能力。

最小可落地架构

如果你现在要从零开始做一个小型 ELK 试点，建议采用最小架构：

Filebeat -> Elasticsearch -> Kibana

选择一类日志，例如 Nginx access log 或某个应用的 JSON 日志。先完成五件事：日志能进 Elasticsearch，@timestamp 正确，核心字段可聚合，Kibana 能查询，Dashboard 能回答一个真实问题。不要一开始接入所有系统。

第二步再引入 Logstash。引入条件是确实需要复杂解析、字段补充或路由。比如应用日志不是 JSON，需要 grok；需要根据 CMDB 补充 service.name；需要同时写入审计系统和 Elasticsearch。这时 Logstash 的价值就明确了。

第三步再考虑生命周期和权限。试点数据量小的时候，生命周期似乎不重要；一旦接入更多服务，磁盘和权限会迅速成为问题。试点阶段就应定义保留期和访问范围，避免后面迁移。

第四步再接入告警。没有稳定字段和 Dashboard 前，不建议急着做告警。告警建立在准确数据上，字段不准会导致误报和漏报。

这条路线小，但完整。它能让团队从一条日志走完采集、存储、查询、展示和治理闭环。

首批接入应用也要挑选。不要选日志格式最乱、调用量最大、权限最敏感的系统作为第一个试点。更适合选择日志量中等、业务负责人配合、字段含义清楚、排障价值明确的系统。试点成功后，把字段规范、采集配置、Dashboard 和问题清单沉淀成模板，再推广到更多应用。

试点结束时，不只交付一个 Kibana 看板，还要交付接入规范。后续团队按规范输出日志，平台才能规模化接入。

规范至少包含字段命名、时间戳、日志级别、服务名、环境名、脱敏要求和保留周期。缺少这些约束，第二个应用接入时就会重新产生口径差异。

每次新增数据源，都应按同一规范复核，而不是为单个应用临时开例外。

这样平台才能长期保持查询口径一致并可复盘追踪治理执行落地复核完善沉淀归档。

后续实践提醒

从第二篇开始，会进入安装和配置。实践时不要只复制命令。每完成一个组件，都要回到本篇的架构问题：这个组件在链路中承担什么责任，输出给下游什么证据，失败后如何定位。

安装 Elasticsearch 时，要关注节点角色、磁盘、水位、TLS、账号和索引模板；配置 Logstash 时，要关注输入、过滤、输出、失败队列和字段标准；使用 Kibana 时，要关注 Data View、查询口径、Dashboard 受众和权限；部署 Filebeat 时，要关注文件路径、multiline、offset、下游不可用时的行为。

这样学习，ELK 就不是五篇孤立教程，而是一条完整数据链路。

本系列的学习路线

本系列后续按实际建设顺序展开：

1. Elasticsearch安装与配置：先建立可靠的存储和查询底座。
2. Logstash数据管道配置：处理复杂日志解析、字段转换和路由。
3. Kibana 可视化入门：从 Data View、Discover、Lens 和 Dashboard 使用数据。
4. Filebeat 日志采集：把边缘日志稳定采集到平台。

这个顺序和真实项目略有差异。真实项目常常先从 Filebeat 采集开始，但学习时先理解 Elasticsearch 和架构边界更稳。否则采集器能跑起来，却不知道数据该写到哪里、字段该怎么设计、索引该怎么保留。

参考资料

• Elastic 官方：Elastic Stack
• Elastic Docs：Elastic fundamentals
• Elastic Docs：The Elastic Stack
• Elastic Docs：Logstash Reference
• Elastic Docs：Elastic Common Schema