100台主机日志采集架构：Filebeat/Fluent Bit + Kafka + ELK

采集 100 台主机的日志，属于中等规模场景（日增量通常在几十 GB 到 100GB 左右）。结合你之前的监控系统架构，我推荐以下方案：

推荐架构：Filebeat/Fluent Bit + Kafka + ELK

一、采集层

Filebeat / Fluent Bit（每台主机部署一个）

这是部署在 100 台被监控主机上的日志采集 Agent，核心职责是：

• 读取日志文件：监控指定路径下的日志文件（如 /var/log/*.log、/var/log/nginx/*.log），支持多行日志（如 Java 异常堆栈）

• 增量采集：记录读取位置（registry 文件），重启后从上次位置继续读，不重复不遗漏

• 轻量预处理：支持简单的字段提取、过滤、添加元数据（主机名、环境标签等）

• 可靠传输：支持 ACK 机制，确保日志成功送达下游才标记为已发送

• 背压感知：当下游（Kafka）处理不过来时，自动减缓读取速度，防止内存爆掉

 Filebeat vs Fluent Bit 的选择：Filebeat 是 Elastic 官方出品，与 Elasticsearch 天然集成，配置简单；Fluent Bit 是 CNCF 项目，资源占用更低（内存仅 ~10MB），支持同时输出到多个目的地。

二、缓冲层

Kafka 集群（建议 3 节点）

Kafka 是整个日志链路的数据总线和缓冲池，核心职责是：

• 削峰填谷：业务高峰期日志量可能暴增 10 倍，Kafka 将突发流量平滑为稳定流速，保护后端存储不被压垮

• 解耦：采集端（Filebeat）只关心把日志送进 Kafka，不关心后端是谁；消费端（Logstash）只从 Kafka 拉数据，不关心采集端有多少台主机

• 持久化缓冲：日志在 Kafka 中默认保留 7 天（可配置），即使后端存储宕机数天，数据也不会丢失

• 多消费者支持：同一份日志可以被多个消费组同时消费——Logstash 消费一份用于存储，Flink 消费一份用于实时分析，安全系统消费一份用于入侵检测

• 分区并行：按日志类型或主机分组创建多个 Partition，实现并行写入和读取，提升吞吐量

 关键配置：对于 100 台主机，建议至少 3 个 Kafka Broker，副本数设为 2~3，确保单节点故障时数据不丢。

三、处理层

Logstash

Logstash 是日志的"清洗工厂"，从 Kafka 消费原始日志后进行标准化处理：

• 解析（Parse）：用 Grok 正则从非结构化的日志文本中提取结构化字段。例如从 Nginx 日志 192.168.1.1 - - [10/Oct/2025:13:55:36] "GET /api/users HTTP/1.1" 200 1234 中提取出 client_ip、method、url、status_code、response_size 等字段

• 过滤（Filter）：丢弃无用的 DEBUG 日志、健康检查日志，降低存储成本

• 转换（Transform）：将时间字段统一为标准格式，将 IP 地址解析为地理位置

• 路由（Route）：根据日志类型分发到不同的 Elasticsearch 索引——错误日志进 logs-error-2025.06，访问日志进 logs-access-2025.06

• 丰富（Enrich）：关联外部数据源，如根据主机 IP 查询 CMDB 获取业务线、负责人等信息，附加到日志中

Flink（可选）

如果需要对日志做实时流式计算，可以在 Kafka 之后接入 Flink：

• 实时告警：统计每分钟 5xx 错误数，超过阈值立即触发告警

• 实时聚合：计算每分钟的 PV/UV、各接口的平均响应时间

• 异常检测：通过机器学习模型实时识别异常登录、SQL 注入等安全事件

四、存储层

Elasticsearch 集群（建议 3 数据节点）

Elasticsearch 是日志的主力存储和检索引擎：

• 全文检索：支持对日志内容进行模糊搜索、正则匹配、高亮显示

• 结构化查询：对解析后的字段（如 status_code、url）进行精确过滤和聚合统计

• 水平扩展：数据自动分片（Shard）分布在多个节点上，支持 PB 级数据量

• 冷热分离：

  • 热节点（SSD）：存储最近 7 天的日志，供高频查询

  • 温节点（HDD）：存储 7~30 天的日志，查询频率较低

  • 冷节点（大容量 HDD）：存储 30~90 天的日志，仅用于审计追溯

• 索引生命周期管理（ILM）：自动滚动创建新索引、合并旧索引、到期自动删除

Loki（可选）

Loki 是 Grafana 团队开发的轻量级日志存储，与 Elasticsearch 形成互补：

• 只索引标签，不索引全文：存储成本仅为 Elasticsearch 的 1/10~1/5

• 适合场景：不需要全文检索，只需要按主机名、日志级别等标签过滤的场景

• 与 Grafana 深度集成：在监控大盘中直接查看对应时间段的日志，实现"指标 + 日志"联动排查

五、展示层

Kibana

Kibana 是 Elasticsearch 的官方可视化平台，核心功能：

• 日志检索：提供类似 Google 的搜索框，支持 KQL（Kibana Query Language）进行复杂查询

• 可视化图表：将日志数据聚合为柱状图、折线图、饼图、热力图等

• Dashboard：将多个图表组合成运维大盘，如"全链路错误率监控"、"各业务线日志量分布"

• 告警：基于日志内容设置告警规则（如"5 分钟内出现 10 次 'Connection refused'"）

• 机器学习：内置异常检测，自动发现日志模式的变化

Grafana + Loki

Grafana 是监控可视化的事实标准，配合 Loki 使用时：

• 统一大盘：在同一个 Dashboard 中同时展示指标（CPU、内存）和日志，实现"指标异常 → 点击查看对应时间段日志"的联动排查

• Explore 模式：临时查询日志，快速定位问题

• 告警通知：基于日志内容触发告警，并通过钉钉、企业微信、邮件等渠道通知

六、数据流向总结

与你现有监控平台的关系

你之前的监控系统是 指标监控（CPU、内存、磁盘等数值型数据），而这套是 日志监控（文本型数据）。两者可以独立运行，也可以在展示层打通：

最佳实践：在 Grafana 中同时接入 InfluxDB（指标数据）和 Loki（日志数据），运维人员看到一个 CPU 飙升的图表时，可以直接在下方展开对应时间段的日志，快速定位是哪个进程、哪行代码导致的问题。