Kafka运维宝典（一）- 查看kafka的运行状态、日记、集群健康检查、集群版本 ...

Kafka运维宝典 （一）


  
一、查看kafka的运行状态

查看 Kafka 历程的详细信息，可以通过以下几个步调和工具来实现。
1. 使用 ps 命令查看 Kafka 历程

起首，可以使用 ps 命令来查看 Kafka 历程是否正在运行，以及历程的详细信息。
示例命令：

1. ps aux | grep kafka

复制代码

示例输出：

1. 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 历程的详细资源消耗。
示例命令：

1. top -p <PID>

复制代码

或者使用 htop
（如果已安装）：

1. htop

复制代码

示例输出：

1. PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
2. 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 来检查服务的状态。
示例命令：

1. sudo systemctl status kafka

复制代码

示例输出：

1. ● kafka.service - Kafka
2.    Loaded: loaded (/etc/systemd/system/kafka.service; enabled; vendor preset: enabled)
3.    Active: active (running) since Sat 2025-01-20 08:00:00 UTC; 1h 30min ago
4.      Docs: http://kafka.apache.org/documentation/
5. Main PID: 12345 (java)
6.     Tasks: 152 (limit: 4915)
7.    Memory: 4.5G
8.    CGroup: /system.slice/kafka.service
9.            └─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 服务的状态。
示例命令：

1. tail -f /path/to/kafka/logs/server.log

复制代码

示例输出：

1. [2025-01-20 08:00:00,123] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
2. [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 是否在该端口上监听。
示例命令：

1. netstat -tuln | grep 9092

复制代码

示例输出：

1. 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. 基本用法

你可以通过以下命令来使用该脚本。
示例命令：

1. bin/kafka-broker-api-versions.sh --bootstrap-server <broker> --describe

复制代码

3. 常用参数

• --bootstrap-server <broker>：指定 Kafka Broker 的地址和端口。通常是集群中任意一个 Broker 地址，例如 localhost:9092。
  
• --describe：输出详细的 API 版本信息。
  

4. 常见输出

该命令会返回 Broker 支持的各个 API 版本的列表，具体包括请求范例、版本号和相应版本号。
示例命令：

1. bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 --describe

复制代码

示例输出：

1. Supported APIs:
2.   API Name        Max Version   Min Version
3.   Fetch           15            0
4.   Produce         15            0
5.   Metadata        12            0
6.   OffsetFetch     4             0
7.   OffsetCommit    8             0
8.   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/ 文件夹。
示例目录结构：

1. /opt/kafka/logs/
2.     ├── server.log
3.     ├── controller.log
4.     ├── kafkaServerShutdown.log
5.     └── <other logs>

复制代码

2. 查看 Kafka 日记

Kafka 会记载不同范例的日记，包括但不限于：

• server.log：Kafka Broker 的主要日记，包含启动、错误、警告和其他告急信息。
  
• controller.log：控制器的日记，用于记载 Kafka 集群控制器（Kafka Controller）相关的事件。
  
• kafkaServerShutdown.log：记载 Kafka Broker 正常关闭时的相关信息。
  
• 其他日记文件：例如，Producer 和 Consumer 相关的日记文件。
  

查看日记的命令：
使用 tail 或 less 命令查看 Kafka 日记文件：

1. # 查看 server.log 最新日志
2. tail -f /path/to/kafka/logs/server.log

复制代码

或者使用 less 查看汗青日记：

1. less /path/to/kafka/logs/server.log

复制代码

3. 常见的日记信息

在 Kafka 的日记中，以下信息是最常见的：

• 启动信息：Kafka 启动时的配置信息和监听端口。
  
• 错误信息：如网络错误、磁盘空间不足、毗连失败等。
  
• 警告信息：如 broker 负载过高、客户端毗连超时等。
  
• 请求和相应日记：包括生产者、消费者和代理之间的请求和相应。
  
• GC (Garbage Collection) 信息：如果 JVM 启动时开启了 GC 日记，会看到 GC 信息，帮助分析内存问题。
  

示例日记输出：

1. [2025-01-20 08:00:00,123] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
2. [2025-01-20 08:01:00,456] INFO [KafkaServer id=0] started serving (kafka.server.KafkaServer)
3. [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：错误信息，表示出现了需要关注的问题。
  

示例日记级别：

1. [2025-01-20 08:00:00,123] INFO [KafkaServer id=0] started (kafka.server.KafkaServer)
2. [2025-01-20 08:01:00,456] WARN [Broker id=0] disk usage is above 85% (kafka.server.KafkaServer)
3. [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 存储日记的目录。
  
  1. log.dirs=/var/lib/kafka/logs

  复制代码
• log.retention.hours：设置 Kafka 日记的保留时间，超过这个时间的日记会被自动删除。
  
  1. log.retention.hours=168  # 保留7天

  复制代码
• log.segment.bytes：设置每个日记段文件的大小，超过该大小后会创建新的日记段。
  
  1. log.segment.bytes=1073741824  # 1GB

  复制代码
• log.cleanup.policy：设置日记的清理策略，常见的有 delete 和 compact。
  
  1. log.cleanup.policy=delete

  复制代码

6. Kafka 错误日记

Kafka 日记文件中通常会记载出现问题时的错误信息，通过查看 server.log 中的 ERROR 级别日记来帮助定位问题。
示例：磁盘空间不足的错误
如果磁盘空间不足，Kafka 可能会报错：

1. [2025-01-20 08:05:00,123] ERROR [Broker id=0] Disk space is running low, unable to write to log (kafka.log.Log)

复制代码

示例：毗连失败
如果某个毗连失败，可能会看到类似的日记：

1. [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 的健康状况。
示例命令：

1. bin/kafka-topics.sh --bootstrap-server <broker_host>:<port> --describe

复制代码

示例输出：

1. Topic: my_topic  PartitionCount: 3  ReplicationFactor: 2  Configs:
2.     Topic: my_topic  Partition: 0  Leader: 2  Replicas: 2,1  Isr: 1,2
3.     Topic: my_topic  Partition: 1  Leader: 1  Replicas: 1,2  Isr: 1,2
4.     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 命令查看消费者的偏移量和滞后状态。

1. bin/kafka-consumer-groups.sh --bootstrap-server <broker_host>:<port> --describe --group <consumer_group_id>

复制代码

示例输出：

1. GROUP            TOPIC              PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
2. my-consumer      my_topic           0          100             200             100
3. my-consumer      my_topic           1          150             150             0
4. 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 日记和消息存储会占用大量磁盘空间，定期检查磁盘空间非常告急。

1. df -h /var/lib/kafka

复制代码

示例输出：

1. Filesystem      Size  Used Avail Use% Mounted on
2. /dev/sda1        100G  80G   20G  80% /var/lib/kafka

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。