2. Elastic可观测性平台架构总览
Elastic 可观测性平台并不是单一软件，而是一组职责明确、可独立部署又能协同工作的组件集合。理解这套架构的关键，不是记住每个组件的名字，而是搞清楚三件事：谁负责采集、谁负责加工、谁负责存储与检索、谁负责呈现，以及数据从产生到被查询之间究竟走了哪条路径。本节围绕 Elasticsearch、Logstash、Kibana、Beats、APM Server、Elastic Agent 六个核心组件，梳理它们的职责边界与数据流转关系。
一、六个组件的职责划分
可以把整个平台按“数据面”和“控制面”来理解。数据面负责让可观测数据从源头流向存储，控制面负责配置下发、策略管理和可视化呈现。
- Elasticsearch：分布式搜索与分析引擎，是整个平台的数据存储与查询核心。它负责索引存储、倒排索引构建、聚合计算和检索。可观测性场景中，日志、指标、链路追踪最终都落到 Elasticsearch 的索引或数据流（data stream）中。
- Kibana：可视化与交互入口。它本身不存储数据，而是向 Elasticsearch 发起查询，把结果渲染成 Discover 检索、可视化图表、仪表盘、告警规则和 APM 界面。Kibana 还承担 Fleet 管理界面，用于集中管理 Elastic Agent 策略。
- Beats：轻量级单用途采集器家族。Filebeat 采集日志文件，Metricbeat 采集系统与服务的指标，Packetbeat 采集网络流量，Winlogbeat 采集 Windows 事件日志。Beats 部署在被观测主机上，资源占用低，通常直接把数据写入 Elasticsearch，也可经 Logstash 中转。
- Logstash：服务端数据处理管道。它通过 input、filter、output 三段式配置，完成数据解析、字段提取、格式转换、富化和路由。相比 Beats，Logstash 处理能力更强但资源消耗更高，适合承担复杂的清洗与聚合任务。
- APM Server：接收应用侧 APM Agent 上报的链路追踪、事务、错误和指标数据，做校验与预处理后写入 Elasticsearch。它专注于应用性能监控这一条数据通道。
- Elastic Agent：统一采集代理。一个 Agent 可以同时运行多种集成（integration），采集日志、指标、追踪等多种数据类型，并由 Fleet 集中下发策略。它整合了 Beats 的能力，是 Elastic 当前推荐的采集方式。
二、数据流转路径
不同数据类型的流转路径并不相同，但都遵循“采集 → 加工（可选）→ 存储 → 查询呈现”的主干。下面这张图展示了六类组件之间的数据流与控制流关系。
从图中可以看出，数据流的主干是：数据源 → 采集层 → 加工层（可选）→ Elasticsearch → Kibana。控制流则是 Kibana 的 Fleet 界面把策略下发给 Elastic Agent，实现集中配置管理。
三、两条典型路径的对比
实际部署中，最常见的两条路径是“Beats 直连 Elasticsearch”和“Beats 经 Logstash 中转”。选择哪条路径，取决于数据是否需要复杂加工。
| 对比项 | Beats → Elasticsearch 直连 | Beats → Logstash → Elasticsearch |
|---|---|---|
| 适用场景 | 日志格式规整、字段已结构化 | 需要解析非结构化日志、多源汇聚 |
| 延迟 | 低，链路短 | 略高，多一跳处理 |
| 资源消耗 | 仅采集端开销 | 需额外维护 Logstash 集群 |
| 加工能力 | 依赖 Ingest Pipeline，能力有限 | filter 插件丰富，支持 grok、mutate、geoip 等 |
| 典型配置 | output.elasticsearch 直写 | output.logstash 转发，再由 Logstash 输出 |
例如，采集 Nginx 访问日志时，如果日志已经是 JSON 格式，Filebeat 可以直接写入 Elasticsearch；如果是默认的 combined 格式，则通常需要 Logstash 用 grok 表达式解析出 clientip、method、request、status 等字段后再写入。
四、APM 数据通道的特殊性
APM 数据的流转路径与日志、指标不同。应用侧需要先集成对应语言的 APM Agent（如 Java、Go、Python、Node.js），Agent 在应用进程内采集事务、跨度、错误等数据，通过 HTTP 上报到 APM Server，再由 APM Server 写入 Elasticsearch 的 apm-* 数据流。Kibana 的 APM 应用读取这些数据，展示服务地图、事务耗时分布和错误率。
需要注意的是，APM Server 与 Elastic Agent 存在功能重叠：新版 Elastic Agent 可以内置 APM 集成，直接承担 APM Server 的接收职责。因此在新建部署中，常见做法是用 Elastic Agent 统一承载日志、指标和 APM 三类采集，减少组件数量。
五、部署时的组件选型建议
- 新建中小规模部署：优先使用 Elastic Agent + Fleet，一个代理覆盖多种数据类型，由 Kibana 集中管理策略，减少运维成本。
- 已有 Beats 体系：可继续使用 Beats，按数据类型分别部署 Filebeat、Metricbeat 等，逐步迁移到 Elastic Agent。
- 需要复杂日志解析：在 Beats 与 Elasticsearch 之间加入 Logstash，承担 grok 解析、字段富化和多目标路由。
- 应用性能监控：部署 APM Server 或在 Elastic Agent 中启用 APM 集成，应用侧集成对应语言 Agent。
- 存储与查询：Elasticsearch 集群按数据量规划节点角色，日志、指标、追踪可使用不同数据流和生命周期策略。