共计 9093 个字符，预计需要花费 23 分钟才能阅读完成。
简介：对于运维人而言，如何装置保护一套监控零碎，或如何进行技术选型，从来不是工作重点。如何借助工具对所需的利用、组件进行监控，发现并解决问题才是重中之重。随着 Prometheus 逐步成为云原生时代可观测规范，为了帮忙更多运维人用好 Prometheus，阿里云云原生团队将定期更新 Prometheus 最佳实际系列。第一期咱们解说了《最佳实际|Spring Boot 利用如何接入 Prometheus 监控》，明天将为大家带来，音讯队列产品 Kafka 的监控最佳实际。
对于运维人而言，如何装置保护一套监控零碎，或如何进行技术选型，从来不是工作重点。如何借助工具对所需的利用、组件进行监控，发现并解决问题才是重中之重。
随着 Prometheus 逐步成为云原生时代可观测规范，为了帮忙更多运维人用好 Prometheus，阿里云云原生团队将定期更新 Prometheus 最佳实际系列。第一期咱们解说了《最佳实际|Spring Boot 利用如何接入 Prometheus 监控》，明天将为大家带来，音讯队列产品 Kafka 的监控最佳实际。
本篇内容次要包含三局部：Kafka 概览介绍、常见要害指标解读、如何建设相应监控体系。
什么是 Kafka
Kafka 起源
Kafka 是由 Linkedin 公司开发，并捐献给 Apache 软件基金会的分布式公布订阅音讯零碎，Kafka 的目标是通过 Hadoop 的并行加载机制来对立线上和离线的音讯解决，也是为了通过集群来提供实时的音讯。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
增加图片正文，不超过 140 字（可选）
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。
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
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。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
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 在实际操作过程中以文档中最新版本为准。
搭建相干监控体系
通过自建 Prometheus 进行监控
这里不对开源 Prometheus 搭建流程进行论述（尽管绝对繁冗，但技术社区有保姆级教程，可自行百度）。这里只简略介绍相干的 Kafka Exporter，以后最新版本是 v1.4.2，公布于 2021.09.16。最近一次更新是 3 个月前，对于 kafka_exporter.go 的。
但如果你跟我一样遇到了以下一个或多个场景：
高级程度，本人搞不定开源 Prometheus 部署；
比拟懒，又不想日常保护 Prometheus 零碎，包含相干组件更新、零碎整体扩容；
业务上线十分焦急，须要马上有相应的监控零碎；
企业级用户 心愿 Prometheus 服务低成本、数据库规模无下限、高性能高可用
那么，阿里云 Prometheus 监控服务是一个最佳抉择，不必再思考以上问题，真正做到开箱即用，一键集成。
通过阿里云 Prometheus 监控进行监控
登录 Prometheus 控制台。在页面左上角抉择指标地区，而后依据须要单击容器服务、Kubernetes 或者 ECS 类型的 Prometheus 实例名称。在左侧导航栏单击组件监控。
增加 Kafka 类型的组件
- 在组件监控页面，单击右上角的增加组件监控。在接入核心面板中单击 Kafka 组件图标。在接入 Kafka 面板 STEP2 区域的配置页签输出各项参数，并单击确定。在接入 Kafka 面板 STEP2 区域的指标页签可查看监控指标。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
默认采集相干指标
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
查看相干数据指标
在组件监控页面，会显示已接入的组件实例。单击该组件实例大盘列的大盘，查看该组件监控指标数据。通过 Grafana 进行更全面的数据展现。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
如果是购买 Kafka 云产品，能够通过”Prometheus for 云服务“进行监控
登录 Prometheus 控制台。在页面左上角抉择指标地区，而后抉择新建 Prometheus 实例。在弹出页面单击 Prometheus 实例 for 云服务。
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
增加 Alibaba Cloud Kafka 监控
在弹出页面选中增加 Alibaba Cloud Kafka，而后点击确定按钮开启 Kafka 云产品监控。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
增加图片正文，不超过 140 字（可选）
默认采集相干指标
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
查看相干数据指标
在 Prometheus 云监控详情大盘列表页面，会显示已接入的 Kafka。单击该组件实例大盘列的 CMS-KAFKA 大盘，查看该组件监控指标数据。通过 Grafana 进行更全面的数据展现。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
相较于开源 Prometheus，阿里云 Prometheus 监控具备以下个性
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
参考及援用：
Kafka 官网文档：
https://kafka.apache.org/docu…
Kafka Exporter Github 地址：
https://github.com/danielqsj/…
https://zhuanlan.zhihu.com/p/…
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载”。
