日志搜集系统从ELK到EFK

发表于 更新于

一、为什么需要日志系统？

1.1 日志的定义与挑战

日志是程序产生的、遵循特定格式（通常包含时间戳）的文本数据。在分布式系统中，日志通常分为：

  • 系统日志：操作系统和基础服务的运行状态
  • 应用日志：业务应用程序的输出
  • 安全日志：安全审计和访问记录

传统日志管理的痛点：

  1. 分散存储：日志分布在多台服务器的不同文件中
  2. 查找困难：故障排查时需要登录多台服务器，使用 grep/sed/awk 等工具手动搜索
  3. 格式多样：不同应用使用不同的日志格式和滚动策略
  4. 实时性差：难以及时发现和响应系统问题

1.2 日志系统的价值

  • 故障排查：快速定位问题根源，减少平均修复时间（MTTR）
  • 系统监控：实时了解服务运行状态和性能指标
  • 安全审计：追踪异常访问和潜在安全威胁
  • 业务分析：基于日志数据进行用户行为分析和业务洞察

二、ELK Stack 基础架构

2.1 核心组件介绍

组件 角色 特点
Elasticsearch 分布式搜索引擎 高可扩展、高可靠、支持全文检索和结构化查询
Logstash 数据收集处理引擎 支持多种数据源、强大的过滤和转换能力
Kibana 数据可视化平台 丰富的图表类型、交互式仪表板
Filebeat 轻量级数据收集器 资源消耗低、专为日志收集优化

版本信息：

  • Elasticsearch 5.2.2
  • Logstash 5.2.2
  • Kibana 5.2.2
  • Filebeat 5.2.2
  • Kafka 2.10

2.2 Logstash 数据处理流程

1
Input → Filter → Output
  • Input插件：支持 File、Stdin、TCP、Syslog、Redis、Collectd 等
  • Filter插件：
    • grok：正则表达式解析
    • date：时间处理
    • json：JSON编解码
    • mutate：数据修改
  • Output插件：支持 Elasticsearch、Redis、TCP、File 等

Grok 示例：

1
2
3
grok {
  match => ["message", "(?m)\[%{LOGLEVEL:level}\] \[%{TIMESTAMP_ISO8601:timestamp}\] \[%{DATA:logger}\] \[%{DATA:threadId}\] \[%{DATA:requestId}\] %{GREEDYDATA:msgRawData}"]
}

三、架构演进：从简单到复杂

3.1 简单版架构（学习用）

1
应用服务器 → Logstash → Elasticsearch → Kibana

特点：

  • Logstash 直接连接 Elasticsearch
  • 部署简单，适合学习和测试
  • 缺点：单点故障、资源消耗大、不适合生产环境

3.2 集群版架构

1
多台服务器 → Logstash Shipper → Elasticsearch集群 → Kibana

改进：

  • Elasticsearch 集群化，提高可用性
  • 每台服务器部署 Logstash Agent
  • 问题：
    • Logstash 消耗服务器资源
    • 大并发时可能丢失数据
    • 不支持多机房部署

3.3 引入消息队列架构

1
多台服务器 → Logstash Shipper → Kafka集群 → Logstash Indexer → Elasticsearch集群 → Kibana

关键改进：

  • 引入 Kafka 作为消息队列，削峰填谷
  • 分离角色：Shipper（收集）和 Indexer（处理）
  • 选择 Kafka 而非 Redis 的原因：
    • 数据可靠性：Kafka 保证可靠，Redis 可能丢失
    • 堆积能力：Kafka 依赖磁盘，Redis 依赖内存

3.4 多机房部署架构

1
2
机房A：应用 → Logstash → Kafka → Logstash → Elasticsearch → Kibana
机房B：应用 → Logstash → Kafka → Logstash → Elasticsearch → Kibana

单元化设计原则：

  • 每个机房独立完整的日志处理链路
  • 避免跨机房数据传输
  • 降低网络延迟和专线成本

四、关键优化：引入 Filebeat

4.1 为什么需要 Filebeat？

Logstash 的问题：

  • 基于 JVM，资源消耗高（CPU、内存）
  • 安装包大（约100MB）
  • 作为 Agent 运行时代价高

Filebeat 的优势：

  • 用 Golang 编写，无需 JVM
  • 安装包小（<10MB）
  • 资源消耗极低
  • 专为日志收集优化

4.2 Filebeat 配置示例

1
2
3
4
5
6
7
8
filebeat.prospectors:
  - input_type: log
    paths: /var/log/nginx/access.log
    json.message_key: log

output.elasticsearch:
  hosts: ["localhost"]
  index: "filebeat-nginx-%{+yyyy.MM.dd}"

4.3 性能对比测试

测试环境：

  • 虚拟机：8 cores, 64G内存, 540G SATA盘
  • 数据：350万条日志，单行580B，8进程写入

测试结果：

指标 Logstash Filebeat 对比
CPU使用率 53.7% 38.0% Filebeat低30%
处理时间 210秒 30秒 Filebeat快7倍
收集速度 1.6万行/秒 11万行/秒 Filebeat快7倍

五、EFK 完整架构（推荐生产方案）

1
应用服务器 → Filebeat → Kafka集群 → Logstash Indexer → Elasticsearch集群 → Kibana

5.1 各组件职责

  1. Filebeat：轻量级日志收集，部署在每台应用服务器
  2. Kafka：消息队列，缓冲日志数据，保证可靠性
  3. Logstash：集中式日志处理，运行在专用服务器
  4. Elasticsearch：分布式存储和搜索
  5. Kibana：数据可视化和查询界面

5.2 配置要点

Filebeat 到 Kafka：

1
2
3
4
output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "app-logs"
  required_acks: 1

Kafka 到 Logstash：

1
2
3
4
5
6
7
input {
  kafka {
    bootstrap_servers => "kafka1:9092,kafka2:9092"
    topics => ["app-logs"]
    codec => json
  }
}

六、实践经验与问题解决

6.1 常见问题及解决方案

问题 现象 解决方案
Indexer 挂掉 日志停止消费 使用 Supervisor 监控进程
Java异常换行 异常日志被分割 使用 multiline codec
时区问题 日志时间差8小时 Kibana 使用浏览器时区
Grok解析失败 日志格式不一致 统一日志格式，使用在线调试

6.2 关键配置示例

处理多行日志：

1
2
3
4
5
6
7
8
9
input {
  stdin {
    codec => multiline {
      pattern => "^\["
      negate => true
      what => "previous"
    }
  }
}

时区处理：

1
2
3
4
5
date {
  match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss.SSS" ]
  target => "@timestamp"
  timezone => "Asia/Shanghai"
}

6.3 监控与维护

  1. 健康检查：
    1
    curl -X GET "localhost:9200/_cluster/health?pretty"
  2. 性能监控：
    • Elasticsearch：节点状态、索引速率、查询延迟
    • Kafka：堆积量、消费速率
    • Logstash：处理速率、错误计数
  3. 容量规划：
    • 根据日志量预估存储需求
    • 设置合理的索引生命周期策略
    • 定期清理过期数据

七、总结与最佳实践

7.1 EFK 架构优势

  1. 高性能：Filebeat 轻量高效，Kafka 缓冲可靠
  2. 可扩展：各组件均可水平扩展
  3. 易维护：职责分离，便于问题定位
  4. 成本可控：根据需求灵活调整资源配置

7.2 部署建议

  1. 开发环境：简单版架构，快速验证
  2. 测试环境：集群版架构，模拟生产
  3. 生产环境：完整 EFK 架构，保证可靠性

7.3 未来演进方向

  1. 容器化部署：使用 Docker 和 Kubernetes 管理
  2. Serverless 架构：利用云服务简化运维
  3. 智能分析：结合机器学习进行异常检测
  4. 安全增强：日志加密、访问控制、审计追踪

7.4 成功关键因素

  1. 标准化：制定统一的日志格式规范
  2. 自动化：部署、配置、监控全流程自动化
  3. 文档化：完善的配置文档和操作手册
  4. 团队培训：确保团队成员掌握相关技能

通过从 ELK 到 EFK 的演进，我们构建了一个高性能、高可靠、易维护的日志系统。这个系统不仅解决了传统日志管理的痛点，还为业务监控、故障排查和安全审计提供了强大支持。随着技术的不断发展，日志系统将继续演进，为企业数字化转型提供更强大的数据支撑。