加入收藏 | 设为首页 | 会员中心 | 我要投稿 温州站长网 (https://www.0577zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

问题盘点|使用 Prometheus 监控 Kafka,我们该关注哪些指标

发布时间:2022-12-20 14:38:37 所属栏目:大数据 来源:转载
导读:
Kafka 作为当前广泛使用的中间件产品,承担了重要/核心业务数据流转,其稳定运行关乎整个业务系统可用性。本文旨在分享阿里云 Prometheus 在阿里云 Kafka 和自建 Kafka 的监控实践。
01
K

Kafka 作为当前广泛使用的中间件产品,承担了重要/核心业务数据流转,其稳定运行关乎整个业务系统可用性。本文旨在分享阿里云 Prometheus 在阿里云 Kafka 和自建 Kafka 的监控实践。

01

Kafka 简介

Aliware

01

Kafka 是什么?

Kafka 是分布式、高吞吐、可扩展的实时数据流平台。

Kafka 广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等大数据领域,已成为大数据生态中不可或缺的部分。

7417d553dcf23a64538dfaf689b9a083.png

Producer:通过 push 模式向 Kafka Broker 发送消息。发送的消息可以是网站的页面访问、服务器日志,也可以是 CPU 和内存相关的系统资源信息。

Kafka Broker:用于存储消息的服务器。Kafka Broker 支持水平扩展。Kafka Broker 节点的数量越多,集群的吞吐率越高。

Group:通过 pull 模式从 Kafka Broker 订阅并消费消息。

ZooKeeper:管理集群的配置、选举领导(Leader)分区,并且在 Group 发生变化时,进行负载均衡。

02

Kafka 特点

Aliware

01

优势

1. 通信模式:支持列队和发布/订阅两种通信模式。

2. 高吞吐量、低延迟:在较廉价的硬件上,Kafka 也能做到每秒处理几十万条消息,延迟最低只有几毫秒。

3. 持久性:Kafka 可以将消息持久化到普通磁盘。

4. 可扩展性:Kafka 集群支持热扩展,可以动态向集群添加新节点。

5. 容错性:允许集群中节点失败(若副本数量为 n,则允许 n-1 个节点失败)。

02

需要注意的问题

1. Topic/分区数过多,导致性能急速下降:Kafka Topic/分区过多(如,对于普通磁盘,单机超过 500 个topic/分区),会导致存储碎片化,load 会发生明显的飙高现象,topic/分区越多,load 越高,发送消息响应时间越长。

2. 消息丢失:以下 2 种使用不当的场景,可能导致消息丢失,应根据业务场景避免。

3. 重复消费:生产者可能由于某种原因(如网络抖动或 Kafka broker 宕机)没有收到 Kafka broker的成功确认,然后重复发送消息,最终导致消费者收到多个相同的业务消息。此场景需要消费者支持的消息幂等性来解决。

4. 消息乱序:Kafka 只能保证同一分区内的消息有序性,不同分区之间消息不能保证有序性。

5. 不支持事务

03

Kafka典型适用场景

1. 大数据领域:网站行为分析、日志聚合、应用监控、流式数据处理、在线和离线数据分析等领域。

2. 数据集成:将消息导入 MaxCompute、OSS、RDS、Hadoop、HBase 等离线数据仓库。

3. 流计算集成:与 StreamCompute、E-MapReduce、Spark、Storm 等流计算引擎集成。

04

Kafka 核心概念

197cba7837201b51a4738227212646e1.png

Broker:一个 Kafka 服务端节点。

集群(Cluster):由多个 Broker 组成的集合。

消息(Message):也叫 Record,Kafka 中信息传递的载体。消息可以是网站的页面访问、服务器的日志,也可以是和 CPU、内存相关的系统资源信息,但对于消息队列 Kafka 版大数据监控,消息就是一个字节数组。

Producer:向 Kafka 发送消息的应用。

Consumer:从 Kafka 接收消息的应用。

消费者组(Consumer Group):一组具有相同 Group ID 的 Consumer。当一个 Topic 被同一个 Group 的多个 Consumer 消费时,每一条消息都只会被投递到一个 Consumer,实现消费的负载均衡。通过 Group,您可以确保一个 Topic 的消息被并行消费,提高 Kafka 的吞吐量。

主题(Topic):消息的主题,用于分类消息。在每个 Broker 上都可以创建多个 Topic。

副本(Replica):每一个分区都有多个副本。当主分区(Leader)故障的时候会选择一个备分区(Follower)上位,成为 Leader。在 Kafka 中默认副本的最大数量是 10 个,且副本的数量不能大于 Broker 的数量,Follower 和 Leader 是在不同的机器,同一机器对同一个分区也只可能存放一个副本。

分区(Partition):一个有序不变的消息序列,用于存储消息。一个 Topic 由一个或多个分区组成,每个分区中的消息存储于一个或多个 Broker 上。在一个分区中消息的顺序就是 Producer 发送消息的顺序。

位点(Offset):分区中每条消息的位置信息,是一个单调递增且不变的值。

消费位点:分区被当前 Consumer 消费了的消息的最大位点。

堆积量:当前分区下的消息堆积总量,即最大位点减去消费位点的值。堆积量是一个关键指标,如果发现堆积量较大,则 Consumer 可能产生了阻塞,或者消费速度跟不上生产速度。此时需要分析 Consumer 的运行状况,尽力提升消费速度。可以清除所有堆积消息,从最大位点开始消费,或按时间点进行位点重置。

重平衡(Rebalance):消费者组内某个消费者实例挂掉后,其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

Zookeeper:Kafka 集群依赖 Zookeeper 来保存集群的的元信息,以保证系统的可用性。

03

主要 Kafka 版本介绍

Aliware

推荐使用 2.x 和 3.x 版本。

01

Kafka Metric 监控参考模型

结合 Kafka 的体系架构和使用场景,我们从 Metrics 采集、监控大盘、告警指标等3方面定义了 Kafka Metric 监控的参考模型。

即我们需要采集哪些 Kafka 相关的 Metric,以便能完成业务监控。下面分别从 Producer、Broker 和 Consumer 三个方面进行讨论。

1. Producer 指标

生产者是将消息推送到 Broker Topic 的应用。如果生产者失败,消费者将得不到新的信息。我们建议关注如下 Producer 的主要指标。

cbece33c72ed515528accb9242baaae2.png

2. Broker 指标

因为所有消息都必须通过 Kafka Broker 才能被使用,所以对集群中 Broker 的监控是最核心的。我们建议关注如下主要指标:

273defcea21df570fae48eec77a7d097.png

225e3f547c9713690d04a8e9f57f1a39.png

c0daca00e4258222e59bb995909d26d9.png

3. Consumer 指标

Consumer 是 Kafka 消息终点。我们建议关注如下主要指标:

d711b9a5ba054b1dcccbafb6c1a4ddc8.png

4. Zookeeper 指标

ZooKeeper 是 Kafka 的一个关键组件(v3.x 之前),ZooKeep 停机将使 Kafka 停止运行。

b2b0999ed5e5d5e44107fbecb6378362.png

建议默认监控大盘至少包含以下指标 panel:

1. Producer

2. Broker

3. Broker JVM

Full GC 频率和耗时:GC 频率高或耗时长,都对 Broker 性能有重大影响。据此,我们可以判断是否需要对内存进行扩容。

4. Consumer

5. Zookeeper

我们建议配置如下告警规则:

1. Producer

2. Broker

3. Broker JVM:

FullGC 频率:对频繁的 FGC 告警。

4. Consumer

消息堆积:group 消费延迟数量大于 n(根据业务流量,适当配置 n 的大小)。

5. Zookeeper

同步请求 pending 数量大于 n。

02

Kafka 典型问题场景及其排查/解决方法

1. 场景描述

某个或某几个 Topic 的消息并发发送性能低。在指标上直接体现为 Producer 的平均请求延迟大、平均生产吞吐量小。

2. 问题原因

通常消息发送慢有如下几种典型原因:

3. 排查/解决办法

1. 场景描述

某个或某几个 Topic 的消息堆积持续增加。在指标上直接体现为 group 消费延迟数量持续增加。

2. 问题原因

通常消息堆积有如下几种典型原因:

3. 排查/解决方法

根据上述可能的原因,我们逐一查看对应的监控指标/大盘,定位并解决问题:

4. 自建 Prometheus 监控 Kafka 的痛点

自建 Prometheus 观测 Kafka,我们将面临的典型问题有:

05

对比

Aliware

阿里云 Prometheus 监控是一款全面对接开源 Prometheus 生态,支持类型丰富的组件观测,提供多种开箱即用的预置观测大盘,且提供全面托管的混合云/多云 Prometheus 服务。除了支持阿里云容器服务、自建 Kubernetes、Remote Write 外,阿里云 Prometheus 还提供混合云+多云 ECS 应用的 metric 观测能力;并且支持多实例聚合观测能力,实现 Prometheus 指标的统一查询,统一 Grafana 数据源和统一告警。

阿里云 Prometheus 提供了阿里云 Kafka 和自建 Kafka 的全套支持。

89673b8256d3deef379a3fdf8da7885b.png

01

使用阿里云 Prometheus 监控 Kafka

下面分别介绍如何使用阿里云 Prometheus 监控阿里云 Kafka 和自建 Kafka。

阿里云 Kafka 针对开源的 Apache Kafka 提供全托管服务,解决开源产品的痛点。用户只需专注于业务开发,无需部署运维。相较于开源 Apache Kafka,消息队列 Kafka 版成本更低、弹性更强、可靠性更高。

阿里云 Kafka 现已默认集成了阿里云 Prometheus 监控。由于阿里云 Kafka 无需用户部署和运维,因此 Prometheus 监控聚焦在“使用 Kafka”场景,主要透出的指标有:

阿里云 Kafka 提供了实例、Group 和 Topic 等三个监控大盘。通过这三个大盘,用户可以快捷、清晰地掌握 Kafka 消息的生产和消费情况,快速定位使用阿里云 Kafka 过程中遇到的问题。

用户可登录阿里云 Kafka 控制台,进入 Kafka 实例详情界面“Prometheus 监控”菜单或 tab 页查看。

16f6039873b08c024c2bae3c2cdbe184.png

阿里云 Kafka 实例监控大盘

d6f5d24d171c20413e234fbfde7f2015.png

阿里云 Kafka 消费组监控大盘

614e7980128649081a2afe21a98d35a7.png

阿里云 Kafka Topic 监控大盘

用户可以登录阿里云 Prometheus 控制台,进入“云服务监控”实例的“集成中心”界面,选择“云产品自监控集成”tab,点击“消息队列 Kafka”,弹出窗口中的“告警”tab 页,即可查看和新增阿里云 Kafka 的 Prometheus 告警。创建 Prometheus 告警的详细操作步骤,详见 Prometheus 告警规则文档。

阿里云 Prometheus 提供了 13 条默认告警指标(持续更新中),涵盖了实例、Group 和 Topic 的关键指标,方便用户快速配置常见告警规则。

63c58fbfe9a68d2a477a86736ba28d47.png

6cc011c1d8775249ded7befaa4bdb552.png

除了阿里云 Kafka 外,阿里云 Prometheus 同时提供了自建 Kafka 的监控接入能力。支持容器服务(包含 ACK、ASK、注册集群等)和 ECS 这两个环境类型的 Kafka 监控,提供基础和高级两个版本:

与阿里云 Kafka 的监控场景不同,自建 Kafka 时,用户除了需要关注“使用 Kafka”的例行指标外,还需要进一步关注“运维 Kafka”的内部指标。因此需要深入抓取 Kafka 生产者、服务端、消费者及其内部各模块的重要指标,以便分析和排查 Kafka 本身各环节的可能问题,因此我们推荐使用高级版,以便全面掌握自建 Kafka 的运行状态。

对于 ZooKeeper 和其它基础监控(磁盘、网络等),请参考使用 Prometheus 监控 ZooKeeper 和 Node Exporter 组件接入配置 Prometheus 监控。

1. 部署自建 Kafka 的基础监控

登录阿里云 Prometheus 控制台,访问 ARMS 接入中心,点击组件应用“Kafka(基础版)”的“添加”按钮,在弹出界面选择 Kafka 所部署的环境(目前支持“阿里云容器服务环境”和“阿里云 ECS 环境”),选择 Kafka 所在的 Prometheus 实例,然后填写配置信息。

f635e2ef8da7df724b1792b663f2a29c.png

9a53c900331771b103e284a14821a9ee.png

配置连接 Kafka 所需的各项信息:

Exporter 名称:当前 Kafka 监控唯一命名。

Kafka地址:填写 Kafka Broker 的连接地址。多个 Broker 地址之间使用逗号或分号来分隔。

metrics 采集间隔(秒):监控数据采集时间间隔。

Kafka版本:选择确定 Kafka 服务端的版本号,目前最高支持 3.2.0。

开启 SASL:选择确定 Kafka 服务端是否使用 SASL。

SASL 用户名:如果开启 SASL,则填写对应的用户名。

SASL 密码:如果开启 SASL,则填写对应的用户名密码。

SASL 方法:选择确定 SASL 方法,目前支持 plain、scram-sha512 和 scram-sha256 等三种。

开启 TLS:选择确定 Kafka 服务端是否使用 TLS。

忽略 TLS 安全校验:如果 Kafka 服务端开启 TLS,且是自签名证书,则选择忽略 TLS 安全校验。

2. 查看自建 Kafka 的基础监控大盘

进入 Prometheus 实例的集成中心,点击“Kafka(基础版)”,在弹出界面选择“大盘”tab 页,点击大盘缩略图,即可查看对应 Grafana 大盘。基础版监控大盘主要展示:

80c9a75891b69073ef5cb2046a54f7c5.png

e3a2bb7a0355c700c80c66a758e90f7d.png

3. 配置自建 Kafka 的基础监控告警

进入 Prometheus 实例的集成中心,点击“Kafka(基础版)”,在弹出界面选择“告警”tab 页,即可查看/新增当前 Prometheus 实例的 Kafka 基础版告警规则。创建 Prometheus 告警的详细操作步骤,详见 Prometheus 告警规则文档。

c81f4733748bc0a48b7aec9da0abdee5.png

目前 Kafka 基础版监控提供了 4 个告警指标。用户可根据实际情况,实例化告警规则。

02

使用阿里云 Prometheus进行自建 Kafka 的高级监控

首先需要用户按照部署和配置 JMX Agent 文档,自行在 Kafka Producer、Broker 和 Consumer 端安装和配置 JMX Agent,以便将暴露 Kafka Metric 给阿里云 Prometheus。

然后访问 ARMS 接入中心,点击组件应用“Kafka(高级版)”的“添加”按钮,在弹出界面选择 Kafka 所部署的环境(目前支持“阿里云容器服务环境”和“阿里云 ECS 环境”),选择 Kafka 所在的 Prometheus 实例,然后填写监控接入的配置信息。

f8248144c166a3daaed24ae1157b0c75.png

468ed86302cdf678f062fa14171ef207.png

进入Prometheus实例的集成中心,点击“Kafka(高级版)”,在弹出界面选择“大盘”tab页,点击大盘缩略图,即可查看对应Grafana大盘。高级版监控提供了Intance和Topic两个视角的大盘。

3963c77469c9c31faa9140e0c1d643d4.png

展示 Kafka Broker 内部各项指标:

172b3d6025630eaa920bfdbcefed9db7.png

展示各个Kafka Topic全链路指标:

649a269638a1cd62d410abd9e1baa90e.png

进入Prometheus实例的集成中心,点击“Kafka(高级版)”,在弹出界面选择“告警”tab页,即可查看/新增当前Prometheus实例的Kafka高级版告警规则。Kafka高级版提供Producer、Instance和Consumer三方面的告警指标,供用户选择和配置。创建Prometheus告警的详细操作步骤,详见Prometheus告警规则文档。

a7634b77c67d7d9a7a14ba5a7b69db47.png

05

结束语

Aliware

阿里云Prometheus的Kafka监控,以阿里云消息队列Kafka丰厚运维实践为基础,结合Kafka社区运维建议,提供了阿里云Kafka和自建Kafka监控的一体化解决方案。

针对自建Kafka的场景特点,提供了基础版和高级版监控接入,满足用户不同场景、不同深度的Kafka监控需求。同时支持容器服务环境和ECS环境的Kafka部署,满足用户不同环境的监控需求。Kafka高级版提供200+个有效metric、10+个关键大盘panel、60+个辅助大盘Panel、17个告警指标(持续更新中),为用户提供全链路、一体化的专家级Kafka监控支撑,保障业务稳定运行。

后续我们将持续优化自建Kafka高级版的部署便利性,以进一步简化用户部署JMX Agent的操作。同时还将深度优化JMX Agent的性能,减少对自建 Kafka Broker的CPU消耗。

(编辑:温州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!