【Elasticsearch从入门到精通】第52篇：Elastic Stack全景解读——ES、Logstash、Beats与Kibana的协作

上一篇【第51篇】Kibana Dashboard构建与共享——从数据到洞察
下一篇【第53篇】用ELK Stack构建集约化日志管理平台——从收集到分析

摘要

Elastic Stack（也称ELK Stack）由Elasticsearch、Logstash、Kibana和Beats四大组件构成，提供从数据采集、传输、存储、分析到可视化的全链路解决方案。本文从架构视角系统梳理各组件在整体体系中的职责定位，详解Beats家族七大数据采集器的功能特点与适用场景（Filebeat文件日志、Metricbeat系统指标、Packetbeat网络数据、Winlogbeat Windows日志、Auditbeat安全审计、Heartbeat健康检查、Functionbeat无服务器数据）。重点分析Logstash与Beats的职责划分原则——Beats负责轻量采集、Logstash负责复杂过滤与转换。最后梳理三种典型架构演进路径，帮助读者根据业务规模选择最合适的部署方案。

关键词：Elastic Stack；ELK；Logstash；Beats；Filebeat；日志采集；架构设计

一、Elastic Stack四大组件职责分工

1.1 组件定位概览

Elastic Stack是一个完整的数据处理流水线，四个组件各司其职：

1.2 数据流转路径

数据源 → Beats → Logstash → Elasticsearch → Kibana (采集) (清洗转换) (存储索引) (可视化) 简化路径（轻量场景）： 数据源 → Beats → Elasticsearch → Kibana 加强路径（高并发场景）： 数据源 → Beats → Kafka → Logstash → Elasticsearch → Kibana

1.3 各组件的技术特征

二、日志管理的挑战

在深入Elastic Stack各组件之前，有必要理解现代IT环境中日志管理面临的核心挑战——这也是ELK诞生的背景。

2.1 日志管理的四大挑战

2.2 ELK的应对策略

三、Beats家族详细介绍

Beats是Elastic公司开发的一系列轻量级数据采集器，每个Beats负责采集特定类型的数据，部署在需要采集数据的服务器上。

3.1 Beats家族总览

3.2 Filebeat——文件日志采集

Filebeat是最常用的Beats，负责监控文件变化并将新增的日志行发送到指定目的地。

# filebeat.yml 基础配置filebeat.inputs:-type:logenabled:truepaths:-/var/log/nginx/access.log-/var/log/nginx/error.logfields:app:nginxenv:productionfields_under_root:falseoutput.elasticsearch:hosts:["http://es-node-01:9200","http://es-node-02:9200"]index:"nginx-logs-%{+yyyy.MM.dd}"

Filebeat工作原理：

1. Harvester (收割机) 打开文件，逐行读取 2. Spooler (缓冲器) 聚合事件并批量发送 3. Registrar (注册器) 记录已读取的文件偏移量（防止重启后重复读取） 4. Output 将事件发送到ES、Logstash、Kafka等目标

3.3 Metricbeat——系统指标采集

Metricbeat定期采集操作系统和常用服务的性能指标。

# metricbeat.yml 配置示例metricbeat.modules:-module:systemperiod:10smetricsets:-cpu-load-memory-network-process-disk-filesystemprocess.include_top_n:by_cpu:5by_memory:5-module:nginxperiod:10smetricsets:-stubstatushosts:["http://localhost:80"]server_status_path:"nginx_status"output.elasticsearch:hosts:["http://localhost:9200"]index:"metricbeat-%{+yyyy.MM.dd}"

3.4 各Beats适用场景深度图谱

服务器环境 Beats 部署指南: ┌─────────────────────────────────────────────────────────────┐ │ Linux 服务器 │ │ ├── Filebeat: 采集应用日志、系统日志、容器日志 │ │ ├── Metricbeat: 采集CPU、内存、磁盘、网络指标 │ │ ├── Auditbeat: 文件完整性监控、用户行为审计 │ │ └── Heartbeat: 定期探测对外服务的可用性 │ ├─────────────────────────────────────────────────────────────┤ │ Windows 服务器 │ │ ├── Winlogbeat: 采集Windows事件日志 │ │ ├── Filebeat: 采集IIS日志、应用程序日志 │ │ ├── Metricbeat: Windows性能计数器 │ │ └── Auditbeat: 安全审计日志 │ ├─────────────────────────────────────────────────────────────┤ │ 网络设备/中间件 │ │ ├── Packetbeat: 抓取网络流量，分析协议性能 │ │ └── Filebeat: 采集设备转发的Syslog │ ├─────────────────────────────────────────────────────────────┤ │ 云环境 │ │ ├── Functionbeat: 采集Lambda/Cloud Functions日志 │ │ └── Filebeat + Metricbeat: EC2/VM 实例级监控 │ └─────────────────────────────────────────────────────────────┘

四、Logstash与Beats的职责划分

4.1 分工原则

在Elastic Stack早期，Logstash承担了数据采集和处理双重职责。随着Beats家族的成熟，架构演变为"Beats采集 + Logstash处理"的分工模式。

4.2 职责边界判断表

决策流程： 数据是否只需要简单采集转发？ ├── 是 → 使用 Beats 直传 ES └── 否 → 需要哪些处理？ ├── 需要复杂正则解析（Grok）？ → 使用 Logstash ├── 需要数据库查询富化？ → 使用 Logstash ├── 需要条件路由到多个目标？ → 使用 Logstash ├── 需要字段重命名和类型转换？ → Logstash/Pipeline └── 只需要基础字段提取？ → Filebeat + processors

4.3 Logstash Pipeline基本结构

# logstash.conf - 基础Pipeline结构input{beats{port=>5044host=>"0.0.0.0"}}filter{# Grok解析grok{match=>{"message"=>"%{COMBINEDAPACHELOG}"}}# 字段转换mutate{convert=>{"bytes"=>"integer"}remove_field=>["@version","host"]}# GeoIP富化geoip{source=>"clientip"}}output{elasticsearch{hosts=>["http://localhost:9200"]index=>"web-logs-%{+YYYY.MM.dd}"}}

五、架构演进路径

随着业务规模的增长，ELK的部署架构也需要相应调整。以下是三种典型的架构模式及其适用场景。

5.1 架构一：Beats → ES 直传（入门级）

适用于日志量小、格式简单的小规模场景。

架构图： ┌─────────┐ ┌──────────────────┐ ┌─────────┐ │ Filebeat │────→│ Elasticsearch │────→│ Kibana │ │(app服务器)│ │ (单节点/小集群) │ │ │ └─────────┘ └──────────────────┘ └─────────┘ 特点: - 架构最简单，部署成本最低 - 适合日志量 < 10GB/天的场景 - 不支持复杂的日志解析和富化 - ES压力直接来自采集端

5.2 架构二：Beats → Logstash → ES（标准级）

适用于需要日志解析、转换、富化的中大规模场景。

架构图： ┌─────────┐ ┌───────────┐ ┌──────────────────┐ ┌─────────┐ │ Filebeat │ │ Logstash │ │ Elasticsearch │ │ Kibana │ │(app-1) │────→│ │────→│ │────→│ │ ├─────────┤ │(解析/转换) │ │ (集群模式) │ │ │ │ Filebeat │────→│ │ │ │ │ │ │(app-2) │ └───────────┘ └──────────────────┘ └─────────┘ 特点: - Logstash承担数据处理职责，ES不直接暴露给采集端 - 支持Grok解析、GeoIP富化、字段转换等复杂处理 - 适合日志量 10GB~100GB/天的场景 - 需注意Logstash可能成为瓶颈，必要时可扩展为多实例

5.3 架构三：Beats → Kafka → Logstash → ES（企业级）

适用于高并发日志、需要削峰填谷和数据持久化的大规模生产场景。

架构图： ┌─────────┐ ┌───────────┐ ┌───────────┐ ┌──────────────────┐ ┌─────────┐ │ Filebeat │ │ Kafka │ │ Logstash │ │ Elasticsearch │ │ Kibana │ │(app-1) │────→│ │────→│(consumer) │────→│ │────→│ │ ├─────────┤ │ │ ├───────────┤ │ (多节点集群) │ │ │ │ Filebeat │────→│ │────→│ Logstash │────→│ │ │ │ │(app-2) │ │ │ │(consumer) │ │ Hot-Warm-Cold │ │ │ ├─────────┤ │ │ ├───────────┤ │ │ │ │ │ ... │────→│ │────→│ Logstash │────→│ │ │ │ │(app-N) │ └───────────┘ │(consumer) │ └──────────────────┘ └─────────┘ └───────────┘ 特点: - Kafka作为缓冲层，解耦采集和处理 - 支持削峰填谷（峰值数据不丢失） - Logstash可以水平扩展Consumer数量 - 适合日志量 > 100GB/天的大规模场景

5.4 三种架构对比

六、总结与最佳实践

核心要点回顾

1. Elastic Stack是一体化数据平台：覆盖数据采集、清洗、存储、搜索、可视化全链路
2. Beats是轻量触角：Filebeat和Metricbeat是最常用的两大数据采集器，部署在数据源头
3. Logstash是数据加工厂：负责复杂的数据解析、转换和富化，与Beats互补而非替代
4. 架构随规模演进：从直传到引入Logstash再到引入Kafka，是渐进的架构升级过程
5. Kibana是统一窗口：所有数据最终通过Kibana呈现，是面向用户的数据分析入口

最佳实践清单

• 组件版本对齐：所有Elastic Stack组件使用相同大版本，避免兼容性问题
• Beats先行：优先使用Beats采集，Logstash作为可选的数据处理层
• 生产必加缓冲：日志量超过50GB/天时应在采集和处理之间加入Kafka缓冲
• 监控自身：使用Metricbeat监控ES集群、Logstash Pipeline和Kibana实例的健康状态
• 日志保留策略：结合ILM（索引生命周期管理）自动归档和删除过期日志
• 安全加固：生产环境开启ES安全认证，Beats和Logstash使用SSL传输数据

上一篇【第51篇】Kibana Dashboard构建与共享——从数据到洞察
下一篇【第53篇】用ELK Stack构建集约化日志管理平台——从收集到分析