日志系统Kafka运维的经验

• 2020 年 3 月 15 日
• 笔记

背景介绍：

从事日志系统的开发运维1年多了，Kafka集群一直是系统中最重要的集群之一。及时有效地处理Kafka问题，是保障系统运行稳定的重要工作。

KAFKA相关数据：

磁盘占用量：1000TB/天

（一）常见问题

问题1：磁盘只读故障

服务器X.X.X.X发生了逻辑盘只读故障。  故障描述：硬盘分区/data9 只读, 出错信息:Read-only file system

系统日志数量巨大，持续的数据写入操作，导致磁盘很容易故障，出现故障时，需要尽快停止服务，减少对集群的影响。

由于Topic一般使用双副本或者三副本，停止一台机器暂时不会对集群产生影响，但是应当尽快将机器恢复，加入集群，避免集群中有些partiton出现单副本运行的情况。如图，一台机器（Broker2）故障，导致Partition0/Partition1单副本运行。

尽快恢复故障机器的方式：

1：等待故障机器修复（根据集群副本情况判断，如果已经单副本在运行，则需要尽快处理）。

2：在集群建设之初，设定备用磁盘，直接对故障磁盘进行替换。

3：在故障机器停机后，创建新的Topic替换旧的Topic（新的Topic所有partition都落在正常的机器上）

4：可以使用kafka reassign partitions工具，将故障机器上的partition迁移到正常的机器（需要考虑数据量的情况和迁移时间）。

注意：使用kafka reassign partitions工具时，需要根据故障的机器ID和partition分布情况自己制定分次/批量迁移规则，不能使用Kafka推荐的配置。

问题2：单partition消费僵死

曾经出现过某topic的单个partition数据无法消费的情况，其它partition可以消费，消费集群整体无异常，未找到具体原因，重启消费者后，问题消失，为了避免及时发现问题，系统增加了对所有partition的消费情况监控，自上次出现问题后，一直未重现此问题。

问题3：消费积压

消费积压是常见的问题，数据量增长，晚高峰，都可能导致数据积压，需要收集到积压数据，关注积压量，在业务上半段是否需要扩容消费端。

问题4：数据回放

Kafka集群中日志一般保持1天，如果在1天内有需要特殊处理的数据，就需要对Kafka数据重新读取。这时需要提前在每个时间点记录当前partition的offset，在Kafka集群中可以考虑每隔10分钟记录一次offset，在数据回放时，按照时间和offset数据，直接读取Topic中数据进行处理。

（二）Kafka监控

在运维kafka系统的过程中，我们根据业务的特点，为了能及时发现上述问题，对所有的集群进行了如下方面的监控：

1，生产者offset变化监控（partition）

根据系统特点，数据是每时每刻都在产生的，可以对指定的Topic的每个partition，检测数据写入后的offset变化情况，如果未变化，则表示数据写入可能出现了异常，然后检查是集群问题或者是生产者Producer的问题。

2，Spark offset变化监控（partition）

Kafka数据是在持续产生，消费者也是在持续消费，可以检查消费者指定Topic的每个partition的offset变化，如果未变化，则表示数据消费异常。

3，消费滞后（group id）

检测所有消费者的消费滞后（LAG）情况，超过一定的积压值，进行告警，需要进行相关的业务分析和扩容。

4，ISR监控

监控是否所有的partition都具有多个可用副本，保证没有因为机器故障未处理的单副本partition，也能及时发现kafka集群负载高导致的副本无法及时保持与leader数据同步的问题。

5，Leader切换的监控

监控集群中Leader切换的情况，有助于了解集群的稳定状态，以便尽早发现问题和提供解决方案。

—完—