冠军资讯
DevOps小王子在微服务架构日益普及的今天，应用日志的集中管理和分析变得至关重要。如果日志散落在各个服务器，排查问题时需要登录多台服务器，效率低下。传统的 grep 命令或简易脚本已经无法满足大规模、高并发场景下的日志分析需求。本文将详细介绍如何使用 Filebeat、Kafka 和 ELK (Elasticsearch, Logstash, Kibana) 构建一套完整的实时日志采集和分析平台，解决上述痛点。我们将深入探讨各个组件的配置，以及在实战中可能遇到的问题和解决方案。
Filebeat：轻量级日志采集
Filebeat 是一款轻量级的日志采集器，它负责将日志数据从服务器发送到 Kafka 或 Elasticsearch。相比于 Logstash，Filebeat 资源占用更少，更适合部署在需要采集日志的服务器上。Filebeat 的核心功能是监控指定的日志文件，一旦发现新的日志条目，就立即将其发送到配置的目标。
Filebeat 配置详解
Filebeat 的配置文件通常是 filebeat.yml。以下是一个典型的 Filebeat 配置文件示例：
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/nginx/access.log
- /var/log/nginx/error.log
# 忽略文件首部的设置，防止重复读取。
ignore_older: 72h
output.kafka:
enabled: true
hosts: ["kafka-1:9092", "kafka-2:9092", "kafka-3:9092"]
topic: 'nginx-logs'
# 设置 key 避免 kafka 数据倾斜。
key:
hash:
enabled: true
key: '%{[log.file.path]}' #基于文件路径做hash
required_acks: 1
compression: gzip
processors:
- add_host_metadata: {}
- add_cloud_metadata: {}
- add_docker_metadata: {}
- add_kubernetes_metadata: {}
这个配置定义了两个输入源，分别是 Nginx 的访问日志和错误日志。output.kafka 配置指定了 Kafka 集群的地址和 Topic 名称。processors配置段用于添加主机、云、Docker、Kubernetes元数据，方便定位问题。
注意： ignore_older 配置项可以避免 Filebeat 重复读取旧的日志文件，单位是小时。
Filebeat 常见问题及解决方案
- Filebeat 无法启动： 检查配置文件语法是否正确，可以使用
filebeat test config命令进行验证。 - Filebeat 采集不到日志： 检查日志文件路径是否正确，Filebeat 进程是否有权限读取日志文件。
- Kafka 接收不到日志： 检查 Kafka 集群是否正常运行，Filebeat 是否能够连接到 Kafka 集群，以及 Topic 是否存在。
Kafka：消息队列中间件
Kafka 是一个高吞吐量、分布式的消息队列中间件，它在日志采集平台中扮演着重要的角色。Filebeat 将日志数据发送到 Kafka，Logstash 再从 Kafka 中读取数据进行处理。Kafka 的优势在于其高可靠性和可扩展性，能够承受高并发的日志写入和读取。
Kafka 集群搭建
搭建 Kafka 集群可以使用 Docker Compose 或者手动安装。这里以 Docker Compose 为例：
version: '3.7'
services:
zookeeper:
image: wurstmeister/zookeeper
ports:
- "2181:2181"
kafka:
image: wurstmeister/kafka
ports:
- "9092:9092"
depends_on:
- zookeeper
environment:
KAFKA_ADVERTISED_HOST_NAME: kafka
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
这个 Docker Compose 文件定义了一个 Zookeeper 服务和一个 Kafka 服务。Zookeeper 用于管理 Kafka 集群的元数据。
Kafka Topic 管理
在 Filebeat 将日志发送到 Kafka 之前，需要先创建对应的 Topic。可以使用 Kafka 自带的 kafka-topics.sh 脚本创建 Topic：
./kafka-topics.sh --create --zookeeper zookeeper:2181 --replication-factor 3 --partitions 3 --topic nginx-logs
这个命令创建了一个名为 nginx-logs 的 Topic，它有 3 个 Partition 和 3 个 Replication Factor。
ELK：日志分析与可视化
ELK (Elasticsearch, Logstash, Kibana) 是一个流行的日志分析和可视化解决方案。Elasticsearch 负责存储和索引日志数据，Logstash 负责对日志数据进行处理和转换，Kibana 负责展示和分析日志数据。
Logstash 配置
Logstash 的配置文件通常是 .conf 文件。以下是一个典型的 Logstash 配置文件示例：
input {
kafka {
bootstrap_servers => "kafka-1:9092,kafka-2:9092,kafka-3:9092"
topics => ["nginx-logs"]
group_id => "logstash-group"
auto_offset_reset => "earliest"
consumer_threads => 5
}
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
geoip {
source => "clientip"
}
}
output {
elasticsearch {
hosts => ["http://elasticsearch:9200"]
index => "nginx-logs-%{+YYYY.MM.dd}"
}
stdout { codec => rubydebug }
}
这个配置定义了一个 Kafka 输入，一个 Grok 过滤器和一个 Elasticsearch 输出。Kafka 输入从 Kafka 集群读取 nginx-logs Topic 的数据。Grok 过滤器使用正则表达式解析日志数据。Elasticsearch 输出将解析后的数据存储到 Elasticsearch 中，索引名称为 nginx-logs-%{+YYYY.MM.dd}，每天创建一个新的索引。
Grok 调试技巧： Logstash 默认自带丰富的 Grok 表达式，但复杂的日志可能需要自定义。可以使用 Grok Debugger 在线工具，测试表达式是否匹配，避免配置错误。比如 Nginx 日志通常包含客户端 IP，服务器状态码等信息，可以通过 Grok 提取这些信息。
Elasticsearch 调优
Elasticsearch 的性能直接影响日志分析的效率。可以从以下几个方面进行调优：
- JVM 堆大小： 根据服务器的内存大小，合理设置 Elasticsearch 的 JVM 堆大小。通常设置为服务器内存的一半。
- 索引设置： 根据实际需求，调整索引的 Refresh Interval 和 number_of_replicas 等参数。
- 分片策略： 合理规划索引的分片数量，避免分片过多或过少。
Kibana 可视化
Kibana 提供强大的数据可视化功能，可以创建各种图表和仪表盘，帮助用户分析日志数据。可以根据实际需求，创建各种图表，例如：
- 访问量趋势图： 展示每天的访问量变化趋势。
- Top N 访问 IP： 展示访问量最高的 IP 地址。
- 错误码分布图： 展示各种错误码的分布情况。
实战避坑经验总结
- Kafka 数据积压： 检查 Logstash 的消费速度是否跟得上 Kafka 的生产速度。可以增加 Logstash 的实例数量，或者优化 Logstash 的配置。
- Elasticsearch 写入缓慢： 检查 Elasticsearch 的资源利用率，例如 CPU、内存、磁盘 I/O。可以增加 Elasticsearch 的节点数量，或者优化 Elasticsearch 的配置。
- 日志格式不统一： 在应用层面统一日志格式，例如使用 JSON 格式，方便 Logstash 进行解析。
- 做好日志切割： 定期切割日志文件，避免单个日志文件过大，影响 Filebeat 的采集效率。
通过 Filebeat, Kafka 和 ELK 的整合，我们可以构建一个高可用、高扩展性的实时日志分析平台，帮助我们更好地监控和分析应用日志，及时发现和解决问题。同时要注意服务器的监控，例如使用 Prometheus+Grafana 监控服务器的 CPU、内存、磁盘 I/O 等指标。当出现问题时，能快速定位是哪个环节出现瓶颈。
