最佳实践｜从Producer 到 Consumer，如何有效监控 Kafka-六虎

关于运维人而言，怎么装置保护一套监控体系，或怎么进行技能选型，从来不是工作重点。怎么凭借工具对所需的使用、组件进行监控，发现并解决问题才是重中之重。

跟着 Prometheus 逐渐成为云原生时代可观测标准，为了协助更多运维人用好 Prometheus，阿里云云原生团队将定时更新 Prometheus 最佳实践系列。第一期咱们解说了《最佳实践｜Spring Boot 使用怎么接入 Prometheus 监控》，今天将为咱们带来，音讯行列产品 Kafka 的监控最佳实践。

本篇内容首要包含三部分：Kafka 概览介绍、常见关键方针解读、怎么建立相应监控体系。

什么是 Kafka

Kafka 起源

Kafka 是由 Linkedin 公司开发，并捐赠给 Apache 软件基金会的分布式发布订阅音讯体系，Kafka 的目的是经过 Hadoop 的并行加载机制来统一线上和离线的音讯处理，也是为了经过集群来提供实时的音讯。

Kafka 的诞生是为了解决 Linkedin 的数据管道问题，用作 LinkedIn 的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。起初 Linkedin 选用 ActiveMQ 进行数据交换，但其时的 ActiveMQ 无法满意 Linkedin 对数据传递体系的要求，经常呈现音讯阻塞或许服务无法正常访问等问题。Linkedin 决议研制自己的音讯行列，Linkedin 时任首席架构师 Jay Kreps 便开始组成团队进行音讯行列的研制。

Kafka 特性

相较于其他音讯行列产品，Kafka 存在以下特性：

耐久性：音讯被耐久化到本地磁盘，而且支撑数据备份避免数据丢掉；
高吞吐：Kafka 每秒能够处理百万条音讯；
可扩展：Kafka 集群支撑热扩展；
容错性：答应集群中节点失利（若副本数量为 n,则答应 n-1 个节点失利）；
高并发：支撑数千个客户端一起读写。

与此一起，差异于其他音讯行列产品，Kafka 不运用 AMQP 或任何其他预先存在的协议进行通讯，运用依据 TCP 的自界说二进制协议。并具有强大的排序语义和耐久性保证。

Kafka 使用场景

依据以上的特性，Kafka 经过实时的处理大量数据以满意各种需求场景：

大数据领域：如网站行为分析、日志聚合、使用监控、流式数据处理、在线和离线数据分析等领域。
数据集成：将音讯导入 ODPS、OSS、RDS、Hadoop、HBase 等离线数据仓库。
流核算集成：与 StreamComput e、E-MapReduce、Spark、Storm 等流核算引擎集成。

Kafka 技能架构

一个音讯行列 Kafka 版集群包含 Producer、Kafka Broker、Consumer Group、Zookeeper。

Producer：音讯发布者，也称为音讯出产者，经过 Push 模式向 Broker 发送音讯。发送的音讯能够是网站的页面访问、服务器日志，也能够是 CPU 和内存相关的体系资源信息。
Broker：用于存储音讯的服务器。Broker 支撑水平扩展。Broker 节点的数量越多，集群吞吐率越高。
Consumer Group：Consumer 被称为音讯订阅者或音讯消费者，担任向服务器读取音讯并进行消费。Consumer Group 指一类 Consumer，这类 Consumer 一般接纳并消费同一类音讯，且音讯消费逻辑一致。经过 Pull 模式从 Broker 订阅并消费音讯。
Zookeeper：管理集群装备、推举 Leader 分区，并在 Consumer Group 产生变化时进行负载均衡。其间值得一提的是，如果没有 ZooKeeper 就无法完结 Kafka 部署。ZooKeeper 是将一切东西粘合在一起的粘合剂
发布/订阅模型：Kafka 选用发布/订阅模型，Consumer Group 和 Topic 的对应联系是 N : N，即一个 Consumer Group 能够一起订阅多个 Topic，一个 Topic 也能够被多个 Consumer Group 一起订阅。尽管一个Topic能够被多个 Consumer Group 一起订阅，但该 Topic 只能被同一个 Consumer Group 内的任意一个 Consumer 消费。

监控 Kafka 的关键方针

这里咱们依据 Kafka 云服务以及自建 Kafka 两个不同的产品进行解说。

如果运用的 Kafka 是云厂商提供的保管服务，对外露出的方针相对有限，能够忽略 Zookeeper 相关方针。以阿里云 Kafka 举例，首要针对各资源类型进行监控：

1、实例监控项

实例音讯出产流量（bytes/s）
实例音讯消费流量（bytes/s）
实例磁盘运用率（%）-实例各节点中磁盘运用率的最大值

2、Topic 监控项

Topic 音讯出产流量（bytes/s）
Topic 音讯消费流量（bytes/s）

3、Group 监控项

Group 未消费音讯总数（个）

如果运用自建 Kafka，那么需求重视的方针就十分多，首要包含以下四个方向：Broker、Producer、Consumer、Zookeeper。

Broker 方针

因为一切音讯都必须经过 Broker 才干被运用，因而，对 Broker 进行监控并预警十分重要。Broker 方针重视：Kafka-emitted 方针、Host-level 方针、JVM 废物搜集方针。

Broker – Kafka-emitted 方针

未复制的分区数：UnderReplicatedPartitions（可用性）kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

在运行正常集群中，同步副本（ISR）数量应等于副本总数。如果分区副本远远落后于 Leader，则从 ISR 池中删去这个 follower。如果署理不行用，则UnderReplicatedPartitions方针急剧增加。Tips：UnderReplicatedPartitions 较长时刻内大于零，需求进行排查。

同步副本（ISR）池缩小/扩展的速率：IsrShrinksPerSec / IsrExpandsPerSec（可用性）kafka.server:type=ReplicaManager,name=IsrShrinksPerSec

Tips：如果某副本在一段时刻内未联系 Leader 或许 follower 的 offset 远远落后于 Leader，则将其从 ISR 池中删去。因而，需求重视 IsrShrinksPerSec / IsrExpandsPerSec 的相关动摇。IsrShrinksPerSec增加，不应该形成IsrExpandsPerSec增加。在扩展 Brokers 集群或删去分区等特殊情况以外，特定分区同步副本（ISR）数量应坚持相对安稳。

离线分区数（仅控制器）：OfflinePartitionsCount（可用性）kafka.controller:type=KafkaController,name=OfflinePartitionsCount

望文生义，首要统计没有活跃 Leader 的分区数。Tips：因为一切读写操作仅在分区引导程序上履行，因而该方针呈现非零值，就需求进行重视，避免服务中止。

集群中活动控制器的数量：ActiveControllerCount（可用性）kafka.server:type=ReplicaManager,name=IsrShrinksPerSec

Tips：一切 brokers 中 ActiveControllerCount 总和一直等于 1，如呈现动摇应及时告警。Kafka 集群中启动的第一个节点将自动成为Controller且只要一个。Kafka 集群中的Controller担任保护分区 Leader 列表，并和谐 Leader 改变（比方某分区 leader 不行用）。

每秒 UncleanLeader 推举次数：UncleanLeaderElectionsPerSec（可用性）kafka.controller:type=ControllerStats,name=UncleanLeaderElectionsPerSec

在可用性和一致性之间，Kafka 默选了可用性。当 Kafka Brokers 的分区 Leader 不行用时，就会产生 unclean 的 leader 推举。当作为分区 Leader 的署理脱机时，将从该分区的 ISR 会集推举出新的 Leader。Tips：UncleanLeaderElectionsPerSec 代表着数据丢掉，因而需求进行告警。

特定恳求（出产/提取）用时：TotalTimeMs（功能）kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower}

TotalTimeMs作为一个方针族，用来衡量服务恳求（包含出产恳求，获取消费者恳求或获取跟随者恳求）的用时，其间包括在恳求行列中等候所花费的时刻 Queue，处理所花费的时刻 Local，等候消费者呼应所花费的时刻 Remote（仅其时requests.required.acks=-1）发送回复的时刻 Response。

Tips：正常情况下 TotalTimeMs 应该近似静态且只要十分小的动摇。如果发现异常，需求检查各个行列、本地、远程和呼应值，定位导致速度下降的切当恳求段。

传入/传出字节率：BytesInPerSec / BytesOutPerSec（功能）kafka.server:type=ReplicaManager,name=IsrShrinksPerSec

Tips：咱们能够考虑是否启用音讯的端到端压缩等优化办法。磁盘吞吐量、网络吞吐量都可能成为 Kafka 的功能瓶颈。比方跨数据中心发送音讯且 Topic 数量很多，或副本恰好是 Leader。

每秒恳求数：RequestsPerSec（功能）kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower},version=([0-9]+)

经过 RequestsPerSec，了解 Producer、Consumer、Followers 的恳求率，保证 Kafka 的高效通讯。

Tips：恳求率会跟着 Producer发送更多流量或集群扩展而增加，然后增加需求提取音讯的 Consumer 或 Followers。如果 RequestsPerSec 继续高企，需求考虑增加 Producer、Consumer、Followers。经过削减恳求数量来提高吞吐量，削减非必要开销。

Broker – Host 基础方针 & JVM 废物搜集方针

除了主机等级的相关方针，因为 Kafka 是由 Scala 编写且运行在 JVM 上，需求依靠 Java 的废物回收机制来开释内存，并跟着集群活跃度提升，废物回收频率不断提升。

耗费磁盘空间耗费与可用磁盘空间：Disk usage（可用性）因为 Kafka 将一切数据耐久保存到磁盘，因而需求监视 Kafka 可用磁盘空间量。
页面缓存读取与磁盘读取的比率：Page cache reads ratio（功能）类似于数据库 cache-hit ratio 缓存命中率，该方针越高读取速度越快，功能越好。如果副本追上了 Leader（如产生新署理），则该方针短暂下降。
CPU 运用率：CPU usage（功能）CPU 很少是功能问题根因。但如果产生 CPU 运用率暴涨，最好还是检查一下。
网络字节发送/接纳（功能）署理保管其他网络服务情况下。网络运用率过高可能是功能下降的先兆。
JVM 履行废物回收进程总数：CollectionCount（功能）java.lang:type=GarbageCollector,name=G1 (Young|Old) Generation

YoungGarbageCollector 相对经常产生。在履行时一切使用线程都会暂停，因而该方针的动摇会形成 Kafka 功能的动摇。

JVM 履行废物搜集进程用时：CollectionTime（功能）java.lang:type=GarbageCollector,name=G1 (Young|Old) Generation

OldGarbageCollector 开释老堆栈中未运用的内存，尽管也会暂停使用线程，但只是间歇运行。如果该动作的耗时或许产生频次过高，需求考虑是否有相应的内存支撑。

Producer 方针

Producer 将音讯推送到 Broker 进行消费。如果 Producer 失利，Consumer 将没有新音讯。因而，咱们需求监测以下方针，保障安稳的传入数据流。

每秒收到的均匀呼应数: Response rate（功能）kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)

关于 Producer，呼应率表明从 Brokers 收到的呼应率。收到数据后，Brokers 对 Producer 做出呼应。结合 request.required.acks 实际装备，“收到”具有不同含义，比方：Leader 已将音讯写入磁盘，Leader 已从一切副本收到确认已将数据写入磁盘。在收到确认之前，Producer 数据不行用于消费。

每秒发送的均匀恳求数: Request rate（功能）kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower},version=([0-9]+)

恳求速率指 Producer 将数据发送给 Brokers 的速率。速率走势是保障服务可用性的重要方针。

均匀恳求等候时长: Request latency average（功能）kafka.[producer|consumer|connect]:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+)

从调用 KafkaProducer.send()到 Producer 收到来自 Broker 的呼应之间的时长。Producer 的 linger.ms 值确认在发送音讯批之前将等候的最长时刻，这答应它累积大量音讯，再在单个恳求中发送它们。如果增加 linger.ms 提高 Kafka 吞吐量，则应重视恳求推迟，保证不会超越约束。

每秒均匀传出/传入字节数：Outgoing byte rate（功能）kafka.producer:type=producer-metrics,client-id=([-.w]+)

了解 Producer 效率，并定位可能的传输推迟原因。

I / O 线程等候的均匀时长: I/O wait time（功能）kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\w]+)
每个分区每个恳求发送的均匀字节数：Batch size（功能）

kafka.producer:type=producer-metrics,client-id=([-.w]+)

为了提升网络资源运用率，Producer 尝试在发送音讯前将音讯分组。Producer 将等候累积由 batch.size 界说的数据量，等候时长受 linger.ms 约束。

Consumer 方针

Consumer 在此分区上滞后于 Producer 的音讯数：Records lag/Records lag max（功能）kafka.consumer:type=consumer-fetch-manager-metrics,partition=”{partition}”,topic=”{topic}”,client-id=”{client-id}”

该方针用来记载 Consumer 当前的日志偏移量和 Producer 的当前日志偏移量之间的核算差。如果 Consumer 是处理实时数据，则一直较高的滞后值可能表明运用者过载，在这种情况下，装备更多运用者和将 Topic 划分到更多分区中提高吞吐量并削减滞后。

特定 Topic 每秒均匀耗费的字节数: bytes consumed rate（功能）kafka.consumer:type=consumer-fetch-manager-metrics,client-id=”{client-id}”,topic=”{topic}”
特定 Topic 每秒均匀耗费的记载数: records consumed rate（功能）kafka.consumer:type=consumer-fetch-manager-metrics,client-id=”{client-id}”,topic=”{topic}”
Consumer 每秒获取的恳求数: fetch rate（功能）kafka.consumer:type=consumer-fetch-manager-metrics,client-id=”{client-id}”,topic=”{topic}”

该方针能够直观反映 Consumer 的全体情况。挨近零值的获取率表明 Consumer 存在问题。如果呈现方针下降，则可能是 Consumer 消费音讯失利。

相关方针能够参阅 Kafka 官方文档，方针称号、方针界说、Mean name 在实际操作过程中以文档中最新版本为准。