Kafka运维宝典 (一)
一、查看kafka的运行状态
查看 Kafka 进程的详细信息,可以通过以下几个步骤和工具来实现。
1. 使用 ps
命令查看 Kafka 进程
首先,可以使用 ps
命令来查看 Kafka 进程是否正在运行,以及进程的详细信息。
示例命令:
ps aux | grep kafka
示例输出:
kafka 12345 0.1 2.3 6789012 23456 ? Sl 08:00 0:12 /path/to/kafka/bin/../libs/kafka-run-class.sh kafka.Kafka
解释:
ps aux
:显示所有进程的详细信息。grep kafka
:过滤出与 Kafka 相关的进程。
在上面的输出中:
kafka
:表示 Kafka 进程的用户。12345
:进程 ID (PID)。0.1
:进程的 CPU 使用率。2.3
:进程的内存使用率。/path/to/kafka/bin/../libs/kafka-run-class.sh kafka.Kafka
:表示 Kafka 启动脚本的位置和主类。
2. 使用 top
或 htop
查看 Kafka 进程
top
和 htop
都是实时查看系统资源使用情况的工具。你可以用它们查看 Kafka 进程的详细资源消耗。
示例命令:
top -p <PID>
或者使用 htop
(如果已安装):
htop
示例输出:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 kafka 20 0 6789012 23456 1234 S 0.5 0.1 0:12.34 kafka.Kafka
这里:
PID
:进程 ID。USER
:运行该进程的用户。VIRT
:进程使用的虚拟内存大小。RES
:进程实际使用的物理内存。S
:进程状态(S=休眠,R=运行中)。%CPU
:进程使用的 CPU 百分比。%MEM
:进程使用的内存百分比。
3. 检查 Kafka 服务状态(systemd)
如果 Kafka 是通过 systemd
管理的,可以使用 systemctl
来检查服务的状态。
示例命令:
sudo systemctl status kafka
示例输出:
● kafka.service - Kafka
Loaded: loaded (/etc/systemd/system/kafka.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2025-01-20 08:00:00 UTC; 1h 30min ago
Docs: http://kafka.apache.org/documentation/
Main PID: 12345 (java)
Tasks: 152 (limit: 4915)
Memory: 4.5G
CGroup: /system.slice/kafka.service
└─12345 /usr/bin/java -Xmx4G -Xms4G -cp /opt/kafka/libs/*:... kafka.Kafka
Active: active (running)
:Kafka 正在运行。Main PID: 12345 (java)
:Kafka 服务的主进程 ID。Memory: 4.5G
:Kafka 使用的内存。CGroup
:显示该服务的进程树。
4. 查看 Kafka 进程的日志
Kafka 的日志文件通常包含详细的启动和运行信息,可以通过日志文件进一步确认 Kafka 服务的状态。
示例命令:
tail -f /path/to/kafka/logs/server.log
示例输出:
[2025-01-20 08:00:00,123] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
[2025-01-20 08:01:00,456] INFO [KafkaServer id=0] started serving (kafka.server.KafkaServer)
INFO [KafkaServer id=0] started
:表示 Kafka 进程已经启动。started serving
:Kafka 服务已经开始接受连接。
5. 查看 Kafka 的端口监听状态
Kafka 通常使用 9092
端口进行通信。可以使用 netstat
或 ss
来检查 Kafka 是否在该端口上监听。
示例命令:
netstat -tuln | grep 9092
示例输出:
tcp 0 0 0.0.0.0:9092 0.0.0.0:* LISTEN
0.0.0.0:9092
:Kafka 正在监听9092
端口,表示外部客户端可以连接。
二、 Kafka 集群的版本信息并确认 broker 是否运行
kafka-broker-api-versions.sh
是 Kafka 自带的一个脚本,用于查询 Kafka Broker 支持的 API 版本信息。通过该脚本,可以查看与 Kafka Broker 交互时支持的 API 版本,帮助调试和确认不同版本的兼容性问题。
1. 功能和作用
kafka-broker-api-versions.sh
脚本通过连接到 Kafka Broker 来查询该 Broker 支持的 API 版本。它会返回支持的 API 的版本信息,以及客户端与 Broker 之间兼容性的问题。
2. 基本用法
你可以通过以下命令来使用该脚本。
示例命令:
bin/kafka-broker-api-versions.sh --bootstrap-server <broker> --describe
3. 常用参数
--bootstrap-server <broker>
:指定 Kafka Broker 的地址和端口。通常是集群中任意一个 Broker 地址,例如localhost:9092
。--describe
:输出详细的 API 版本信息。
4. 常见输出
该命令会返回 Broker 支持的各个 API 版本的列表,具体包括请求类型、版本号和响应版本号。
示例命令:
bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 --describe
示例输出:
Supported APIs:
API Name Max Version Min Version
Fetch 15 0
Produce 15 0
Metadata 12 0
OffsetFetch 4 0
OffsetCommit 8 0
ConsumerMetadata 1 0
输出解释
API Name
:表示支持的 Kafka API 类型(如Fetch
,Produce
,Metadata
等)。Max Version
:表示该 API 支持的最大版本号。Min Version
:表示该 API 支持的最小版本号。Fetch
API:表示拉取消息的 API,支持的版本号从 0 到 15。Produce
API:表示生产消息的 API,支持的版本号从 0 到 15。Metadata
API:用于获取 Kafka 集群元数据,支持的版本号从 0 到 12。OffsetFetch
API:用于获取消费者偏移量的 API,支持的版本号从 0 到 4。OffsetCommit
API:用于提交消费者偏移量的 API,支持的版本号从 0 到 8。ConsumerMetadata
API:获取消费者元数据的 API,支持的版本号从 0 到 1。
5. 实际场景
这个工具在以下场景中非常有用:
- 兼容性检查:检查当前 Kafka Broker 支持的 API 版本是否与客户端兼容,避免版本不匹配导致的错误。
- 版本升级后验证:升级 Kafka 后,使用该命令检查新版本是否支持所需的 API 版本。
- 排查问题:当遇到客户端和 Broker 之间的兼容性问题时,可以用来确认问题的根源。
三、查看 Kafka 日志
Kafka 在运行过程中会生成详细的日志,这些日志文件记录了 Kafka 各种操作和事件的详细信息。
1. Kafka 日志文件的存储位置
Kafka 的日志文件通常会存储在你指定的 logs
目录中,或者是由 log.dirs
配置项指定的目录。默认情况下,日志文件会存储在 Kafka 安装目录下的 logs/
文件夹。
示例目录结构:
/opt/kafka/logs/
├── server.log
├── controller.log
├── kafkaServerShutdown.log
└── <other logs>
2. 查看 Kafka 日志
Kafka 会记录不同类型的日志,包括但不限于:
- server.log:Kafka Broker 的主要日志,包含启动、错误、警告和其他重要信息。
- controller.log:控制器的日志,用于记录 Kafka 集群控制器(Kafka Controller)相关的事件。
- kafkaServerShutdown.log:记录 Kafka Broker 正常关闭时的相关信息。
- 其他日志文件:例如,Producer 和 Consumer 相关的日志文件。
查看日志的命令:
使用 tail
或 less
命令查看 Kafka 日志文件:
# 查看 server.log 最新日志
tail -f /path/to/kafka/logs/server.log
或者使用 less
查看历史日志:
less /path/to/kafka/logs/server.log
3. 常见的日志信息
在 Kafka 的日志中,以下信息是最常见的:
- 启动信息:Kafka 启动时的配置信息和监听端口。
- 错误信息:如网络错误、磁盘空间不足、连接失败等。
- 警告信息:如 broker 负载过高、客户端连接超时等。
- 请求和响应日志:包括生产者、消费者和代理之间的请求和响应。
- GC (Garbage Collection) 信息:如果 JVM 启动时开启了 GC 日志,会看到 GC 信息,帮助分析内存问题。
示例日志输出:
[2025-01-20 08:00:00,123] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
[2025-01-20 08:01:00,456] INFO [KafkaServer id=0] started serving (kafka.server.KafkaServer)
[2025-01-20 08:02:00,789] ERROR [Broker id=0] Failed to process fetch request (kafka.server.KafkaServer)
4. 日志级别
Kafka 日志包含不同的日志级别,帮助用户根据需要进行过滤:
- DEBUG:调试信息,通常用于开发阶段或深入问题分析时。
- INFO:信息性日志,记录 Kafka 正常运行时的重要事件。
- WARN:警告信息,表示潜在问题或性能瓶颈。
- ERROR:错误信息,表示出现了需要关注的问题。
示例日志级别:
[2025-01-20 08:00:00,123] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
[2025-01-20 08:01:00,456] WARN [Broker id=0] disk usage is above 85% (kafka.server.KafkaServer)
[2025-01-20 08:02:00,789] ERROR [Broker id=0] Failed to process fetch request (kafka.server.KafkaServer)
5. Kafka 日志配置
Kafka 提供了多种配置项来控制日志的行为和存储位置。以下是一些重要的日志配置项:
配置文件中的日志配置:
-
log.dirs:指定 Kafka Broker 存储日志的目录。
log.dirs=/var/lib/kafka/logs
-
log.retention.hours:设置 Kafka 日志的保留时间,超过这个时间的日志会被自动删除。
log.retention.hours=168 # 保留7天
-
log.segment.bytes:设置每个日志段文件的大小,超过该大小后会创建新的日志段。
log.segment.bytes=1073741824 # 1GB
-
log.cleanup.policy:设置日志的清理策略,常见的有
delete
和compact
。log.cleanup.policy=delete
6. Kafka 错误日志
Kafka 日志文件中通常会记录出现问题时的错误信息,通过查看 server.log
中的 ERROR
级别日志来帮助定位问题。
示例:磁盘空间不足的错误
如果磁盘空间不足,Kafka 可能会报错:
[2025-01-20 08:05:00,123] ERROR [Broker id=0] Disk space is running low, unable to write to log (kafka.log.Log)
示例:连接失败
如果某个连接失败,可能会看到类似的日志:
[2025-01-20 08:06:00,456] ERROR [Broker id=1] Failed to connect to node 2 (kafka.network.Processor)
四、Kafka 集群健康检查
Kafka 集群健康检查是确保 Kafka 集群高可用性、稳定性和性能的关键任务。Kafka 集群的健康状况影响着消息的生产、消费、存储及网络延迟等方面。因此,定期进行健康检查对于及时发现并解决潜在问题至关重要。
1. 检查 Kafka Broker 状态
Kafka 集群的核心是各个 Kafka Broker,每个 Broker 的状态直接影响集群的整体健康状况。要查看 Kafka Broker 的状态,可以通过以下几种方式:
使用 kafka-topics.sh
命令查看 Kafka Broker 状态
kafka-topics.sh
用于查看 Kafka 中的所有主题及其分区情况,也能间接反映 Broker 的健康状况。
示例命令:
bin/kafka-topics.sh --bootstrap-server <broker_host>:<port> --describe
示例输出:
Topic: my_topic PartitionCount: 3 ReplicationFactor: 2 Configs:
Topic: my_topic Partition: 0 Leader: 2 Replicas: 2,1 Isr: 1,2
Topic: my_topic Partition: 1 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: my_topic Partition: 2 Leader: 3 Replicas: 3,1 Isr: 3,1
- Leader: 该分区的当前 Leader Broker ID。
- Replicas: 该分区的所有副本的 Broker ID 列表。
- Isr: 表示当前同步副本的列表。所有副本都应保持同步,否则可能导致数据丢失。
健康的 Kafka 集群应该有完整的副本列表,且每个分区的 ISR(同步副本列表)应该包含至少一个副本。如果 Isr
列表出现不正常,表示该分区可能没有副本或副本未同步。
2. 检查 Kafka 消费者健康
Kafka 消费者的健康状况直接影响消息的消费。如果消费者滞后过多,可能需要增加消费者实例或调整配置。
a. 使用 kafka-consumer-groups.sh
检查消费者状态
通过 kafka-consumer-groups.sh
命令查看消费者的偏移量和滞后状态。
bin/kafka-consumer-groups.sh --bootstrap-server <broker_host>:<port> --describe --group <consumer_group_id>
示例输出:
GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG
my-consumer my_topic 0 100 200 100
my-consumer my_topic 1 150 150 0
my-consumer my_topic 2 200 300 100
- CURRENT-OFFSET: 消费者组当前的偏移量。
- LOG-END-OFFSET: Kafka 中日志末尾的偏移量。
- LAG: 消费者滞后的消息数量。如果滞后量过大,可能表示消费者处理速度慢或者消费者组配置不当。
如果 LAG
值较大,建议通过增加消费者实例来减轻负载,或者检查消费者的配置(如 fetch.max.wait.ms
等)。
3. 检查磁盘和资源使用
Kafka 集群的磁盘空间、内存和 CPU 使用情况直接影响集群的性能和稳定性。资源的不足可能导致 Kafka 无法正常运行。
使用 df
命令检查磁盘空间
Kafka 日志和消息存储会占用大量磁盘空间,定期检查磁盘空间非常重要。
df -h /var/lib/kafka
示例输出:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 100G 80G 20G 80% /var/lib/kafka