关于阿里云:问题盘点|使用-Prometheus-监控-Kafka我们该关注哪些指标

32次阅读

共计 11248 个字符,预计需要花费 29 分钟才能阅读完成。

作者:阿里云可观测

Kafka 作为以后宽泛应用的中间件产品,承当了重要 / 外围业务数据流转,其稳固运行关乎整个业务零碎可用性。本文旨在分享阿里云 Prometheus 在阿里云 Kafka 和自建 Kafka 的监控实际。

Kafka 简介

Kafka 是什么?

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

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

Producer: 通过 push 模式向 Kafka Broker 发送音讯。发送的音讯能够是网站的页面拜访、服务器日志,也能够是 CPU 和内存相干的系统资源信息。

Kafka Broker: 用于存储音讯的服务器。Kafka Broker 反对程度扩大。Kafka Broker 节点的数量越多,集群的吞吐率越高。

Group: 通过 pull 模式从 Kafka Broker 订阅并生产音讯。

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

Kafka 特点

劣势

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

2. 高吞吐量、低提早: 在较便宜的硬件上,Kafka 也能做到每秒解决几十万条音讯,提早最低只有几毫秒。

3. 持久性: Kafka 能够将音讯长久化到一般磁盘。

4. 可扩展性: Kafka 集群反对热扩大,能够动静向集群增加新节点。

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

须要留神的问题

1. Topic/ 分区数过多,导致性能急速降落: Kafka Topic/ 分区过多(如,对于一般磁盘,单机超过 500 个 topic/ 分区),会导致存储碎片化,load 会产生显著的飙高景象,topic/ 分区越多,load 越高,发送音讯响应工夫越长。

2. 音讯失落: 以下 2 种使用不当的场景,可能导致音讯失落,应依据业务场景防止。

  • 生产音讯:如果 acks!=all 或者音讯正本数不大于 1,则在 Kafka Broker 机器异样宕机时,可能导致音讯失落。
  • 生产音讯:生产端在未齐全解决完音讯时即提交 offset,则在生产端异样时,可能导致局部音讯失落。

3. 反复生产: 生产者可能因为某种原因(如网络抖动或 Kafka broker 宕机)没有收到 Kafka broker 的胜利确认,而后反复发送音讯,最终导致消费者收到多个雷同的业务音讯。此场景须要消费者反对的音讯幂等性来解决。

4. 音讯乱序: Kafka 只能保障同一分区内的音讯有序性,不同分区之间音讯不能保障有序性。

5. 不反对事务

Kafka 典型实用场景

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

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

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

Kafka 外围概念

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 来保留集群的的元信息,以保证系统的可用性。

次要 Kafka 版本介绍

  • 0.x:晚期孵化版本。
  • 1.x:优化 Streams API、加强可观测性和可调试性、反对 Java9、优化 SASL 认证等、优化 Controller 治理等。
  • 2.x:性能显著晋升、加强 ACL 反对、反对 OAuth2 bearer、反对动静更新 SSL、加强可察看能力、反对 Java 11(不再反对 Java 7)、反对增量合作再均衡等。
  • 3.x:去掉 zookeeper 依赖、反对 Java 17(不再反对 Java8 和 Scala 12)、不再反对 v0 和 v1 音讯、性能大幅晋升等。

举荐应用 2.x 和 3.x 版本。

Kafka Metric 监控参考模型

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

  • Metrics 采集

即咱们须要采集哪些 Kafka 相干的 Metric,以便能实现业务监控。上面别离从 Producer、Broker 和 Consumer 三个方面进行探讨。

1. Producer 指标

生产者是将音讯推送到 Broker Topic 的利用。如果生产者失败,消费者将得不到新的信息。咱们倡议关注如下 Producer 的次要指标。

2. Broker 指标

因为所有音讯都必须通过 Kafka Broker 能力被应用,所以对集群中 Broker 的监控是最外围的。咱们倡议关注如下次要指标:

3. Consumer 指标

Consumer 是 Kafka 音讯起点。咱们倡议关注如下次要指标:

4. Zookeeper 指标

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

  • Kafka 监控大盘

倡议默认监控大盘至多蕴含以下指标 panel:

1. Producer

  • topic 音讯生产量随工夫的变动:便于咱们疾速确定流量起源,并为基础设施的变更配置提供根据。
  • 申请 / 响应速率随工夫的变动:亲密关注峰值和降落对于确保间断服务可用性至关重要。
  • 申请均匀提早随工夫的变动:因为提早与吞吐量有很强的相关性,察看此变动,有助于咱们判断是否须要批改 batch.size 参数。
  • IO 期待随工夫的变动:如果咱们发现等待时间过长,就意味着生产者无奈足够快地获取所需的数据。

2. Broker

  • 存在生效正本的分区数量的变动:如果此指标突增,则很可能某个 Broker 产生了异样。
  • ISR 数量变动:除 Broker 或 Partition 数量变动会触发 ISR 数量变动外,其它状况下的以后指标变动都须要咱们留神。
  • 无效 Broker 数量变动。
  • 无效 Controller 数量变动。
  • 离线分区数的变动:此指标大于 0,则意味着这些数量的分区不可用,该分区的消费者和生产者都将被阻塞。
  • Leader 选举速率和耗时的变动:产生选举,则意味着某个 Leader 的失落;耗时过长,则会导致此期间音讯无奈接管生产者音讯和消费者的申请。
  • 申请耗时:通常该值应相当稳固,稳定很小。
  • 网络流量:提供潜在瓶颈所在位置的信息,为咱们判断是否启用音讯的端到端压缩提供根据。
  • 生产 / 拉取 purgatory 音讯数量:通过观察 purgatory 中音讯数量,有助于咱们确定音讯生产或拉取耗时长的起因。

3. Broker JVM

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

4. Consumer

  • group 生产提早数量的变动:该指标越大,则音讯沉积越多。
  • 生产流量的变动:显示生产音讯的网络流量 / 音讯流量大小变动。
  • 拉取数据速率的变动:消费者是否衰弱的重要指标。

5. Zookeeper

  • 待处理的申请数的变动。
  • 均匀申请响应耗时的变动:如果耗时突增,则可能导致整个 Kafka 集群的协调机制碰壁。
  • 客户端连接数的变动:连接数的渐变,通常随同着 Broker 的退出、退出或失落。
  • 关上的文件句柄数和残余数的变动:如果残余数有余,则可能导致 Broker 无奈连贯到 Zookeeper。
  • 同步申请 pending 数量的变动。
  • Kafka 告警规定

咱们倡议配置如下告警规定:

1. Producer

  • 发送失败音讯数:以后发送失败的音讯达到肯定数量时告警。
  • 发送重试音讯数:当单位工夫内发送重试的音讯数量达到阀值时告警。
  • 发送耗时长:发送耗时大于 x 毫秒。

2. Broker

  • Controller 失常:无效 Controller 数量不为 1。
  • 无离线分区:离线分区数大于 0。
  • 无 UnClean Leader 选举:Unclean Leader 选举速率大于 0。
  • Broker 不可用:无效 Broker 数量缩小。
  • ISR 膨胀:Topic 分区的 ISR 数量小于 n。
  • 分区不可用:Topic 分区处于 Under Replicated 状态。
  • Topic/ 分区容量:Topic/ 分区数量大于 n。
  • 实例音讯流入 / 出量:以后实例的流量超过或低于某个阀值时告警。
  • Topic 音讯流入 / 出量:以后某个 Topic 的流量超过或低于指定阀值时告警。
  • 磁盘容量:磁盘使用率大于 x%(参考值:85%)。
  • CPU 使用率:大于 80%。

3. Broker JVM:

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

4. Consumer

音讯沉积:group 生产提早数量大于 n(依据业务流量,适当配置 n 的大小)。

5. Zookeeper

同步申请 pending 数量大于 n。

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

  • Topic 音讯发送慢,并发性能低

1. 场景形容

某个或某几个 Topic 的音讯并发发送性能低。在指标上间接体现为 Producer 的均匀申请提早大、均匀生产吞吐量小。

2. 问题起因

通常音讯发送慢有如下几种典型起因:

  • 网络带宽有余,导致 IO 期待。
  • 音讯未压缩,导致网络流量超负荷。
  • 音讯未批量发送,或批量阀值配置不失当,导致发送速率慢。
  • Topic 分区数量有余,导致 Broker 接管音讯积压。
  • Broker 磁盘性能低,导致磁盘同步慢。
  • Broker 分区数总量过多,导致碎片化,磁盘读写过载。

3. 排查 / 解决办法

  • 根据上述起因,咱们逐个查看对应的监控指标 / 大盘,定位并解决问题:
  • 确认 Producer 的“均匀 I/O 等待时间”指标是否合乎预期或有陡增?以便确认 Producer 到 Broker 之间的网络带宽是否满足业务流量要求?如果不满足,则须要硬件资源扩容。
  • 确认 Producer 的“均匀压缩率指标”,确保压缩率合乎预期?如果压缩过低,则须要 Producer 端进行排查、修改。
  • 确认 Producer 的“均匀申请包大小”是否过小?如果是的话,则须要思考加大 Producer 发送音讯的 batchsize,同时调整 linger.ms 的阀值,以防止申请音讯碎片化。
  • 查看 Topic 分区数,分区数较小时,思考减少分区数,以程度扩大 Broker 的并发接管音讯容量。
  • 确认 Broker 磁盘 IO 使用率是否在平安范畴内?如果使用率曾经较高,则思考程度扩容 Broker 数量以分担磁盘压力,或降级磁盘为 SSD 以晋升 IO 性能。
  • 确认 Broker 的 CPU 使用率是否在平安范畴内?如果使用率曾经较高,则思考垂直或程度扩容 Broker,同时思考减少 Topic 分区数,以晋升 Topic 并发接管音讯能力。
  • 查看集群的总分区数和单个 Broker 的分区数量,确保在布局的容量范畴内。否则应思考程度扩容 Broker 数量,以防止碎片化磁盘读写导致的性能降落。
  • Topic 音讯沉积

1. 场景形容

某个或某几个 Topic 的音讯沉积继续减少。在指标上间接体现为 group 生产提早数量继续减少。

2. 问题起因

通常音讯沉积有如下几种典型起因:

  • Producer 生产音讯流量增大。
  • Consumer 因为业务变动导致生产提早减少。
  • Consumer 数量有余。
  • Consumer 数量频繁变动,导致 Group 一直做再均衡(Rebalance)。
  • Broker 未收到 Consumer 生产确认音讯。

3. 排查 / 解决办法

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

  • 确认 Producer 的“音讯生产量”指标是否有明显增加?如果有显示减少,则咱们须要对应减少消费者数量。
  • 确认 Consumer 的“音讯生产流量”指标是否显著降落?如果有显示降落,则阐明消费者的业务解决耗时减少,咱们须要确认业务耗费,或减少消费者数量。
  • 通过 Kafka Broker 提供的命令,确认 Topic 对应的 Consumer 数量与理论的 Consumer 数量是否统一?如果不统一,则阐明某些 Consumer 未正确连贯到 Broker,须要排查 Consumer 是否失常运行。
  • 察看 Consumer 的数量是否频繁变动而触发重复再均衡(Rebalance),如果是,则咱们须要排查确认各个 Consumer 是否失常运行。
  • 因为网络或其它起因,可能导致 Consumer 与 Broker 之间的连贯不稳固,Consumer 能继续生产音讯,但 Broker 却始终认为音讯未确认,导致生产位点不变。此时可能须要确认 Consumer 与 Broker 之间的网络稳定性、甚至重启 Consumer。

4. 自建 Prometheus 监控 Kafka 的痛点

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

  • 因为平安、组织治理等因素,用户业务通常部署在多个互相隔离的 VPC,须要在多个 VPC 内都反复、独立部署 Prometheus,导致部署和运维老本高。
  • 每套残缺的自建观测零碎都须要装置并配置 Prometheus、Grafana、AlertManager 等,过程简单、施行周期长。
  • 开源 Kafka JMX Agent 在某些场景下占用 CPU 高,对自建 Kafka 业务有肯定烦扰。
  • 对于阿里云音讯队列 Kafka 版(简称阿里云 Kafka),自建 Prometheus 无奈监控到,导致无奈实现一站式、全局视角的监控建设。
  • 对于部署在 ECS 上的自建 Kafka,自建 Prometheus 短少与阿里云 ECS 无缝集成的服务发现(ServiceDiscovery)机制,无奈依据 ECS 标签来灵便定义抓取 targets。如果自行实现相似性能,则须要应用 GOlang 语言开发代码(调用阿里云 ECS POP 接口)、集成进开源 Prometheus 代码、编译打包后部署,实现门槛高、过程简单、版本升级艰难。
  • 开源 Grafana Kafka 大盘不够业余,短少联合 Kafka 原理 / 特色和最佳实际进行深刻优化。
  • 短少 Kafka 告警指标模板,须要用户自行钻研、配置告警规定,工作量大,且很可能短少 Kafka 畛域的业余技术积淀。

比照

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

阿里云 Prometheus 提供了阿里云 Kafka 和自建 Kafka 的全套反对。

应用阿里云 Prometheus 监控 Kafka

上面别离介绍如何应用阿里云 Prometheus 监控阿里云 Kafka 和自建 Kafka。

  • 应用阿里云 Prometheus 监控阿里云 Kafka

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

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

  • 实例 /Group/Topic 各级的流量指标
  • Group 和 Topic 的音讯沉积指标
  • 实例磁盘使用率指标
  • Group 的 Rebalance 指标
  • 查看阿里云 Kafka 监控大盘

阿里云 Kafka 提供了实例、Group 和 Topic 等三个监控大盘。通过这三个大盘,用户能够快捷、清晰地把握 Kafka 音讯的生产和生产状况,疾速定位应用阿里云 Kafka 过程中遇到的问题。

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

https://kafka.console.aliyun….

阿里云 Kafka 实例监控大盘

阿里云 Kafka 生产组监控大盘

阿里云 Kafka Topic 监控大盘

  • 应用阿里云 Prometheus 配置阿里云 Kafka 告警

用户能够登录阿里云 Prometheus 控制台,进入“云服务监控”实例的“集成核心”界面,抉择“云产品自监控集成”tab,点击“音讯队列 Kafka”,弹出窗口中的“告警”tab 页,即可查看和新增阿里云 Kafka 的 Prometheus 告警。创立 Prometheus 告警的具体操作步骤,详见 Prometheus 告警规定文档。

https://help.aliyun.com/docum…

阿里云 Prometheus 提供了 13 条默认告警指标(继续更新中),涵盖了实例、Group 和 Topic 的要害指标,不便用户疾速配置常见告警规定。

  • 应用阿里云 Prometheus 监控自建 Kafka

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

  • 根底版:收集 Broker 数量、Topic 分区、音讯组 Lag 等根底指标,Kafka 服务端无端任何配置或重启。
  • 高级版:除根底版能力外,通过 JMX Agent,收集生产者、服务端、消费者及其外部各模块的的重要指标,实现全链路、一体化的专家级 Kafka 监控。但须要进行 JMX Agent 注入和过程重启。

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

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

https://help.aliyun.com/docum…

https://help.aliyun.com/docum…

  • 应用阿里云 Prometheus 进行自建 Kafka 的根底监控

1. 部署自建 Kafka 的根底监控

登录阿里云 Prometheus 控制台,拜访 ARMS 接入核心,点击组件利用“Kafka(根底版)”的“增加”按钮,在弹出界面抉择 Kafka 所部署的环境(目前反对“阿里云容器服务环境”和“阿里云 ECS 环境”),抉择 Kafka 所在的 Prometheus 实例,而后填写配置信息。

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

Exporter 名称:以后 Kafka 监控惟一命名。

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

  • 容器服务内,则能够应用 Kafka Broker 的 IP 或 Service 地址。
  • ECS 环境内,则能够应用 Kafka Broker 的 IP 或 DNS 地址。

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 大盘。根底版监控大盘次要展现:

  • Kafka Broker 数量。
  • 每个 Topic 的分区数。
  • 每个 Topic 的音讯入 / 出 / 沉积数量。
  • 每个 Topic 的 ISR(In-Sync Replicas)数量。

3. 配置自建 Kafka 的根底监控告警

进入 Prometheus 实例的集成核心,点击“Kafka(根底版)”,在弹出界面抉择“告警”tab 页,即可查看 / 新增以后 Prometheus 实例的 Kafka 根底版告警规定。创立 Prometheus 告警的具体操作步骤,详见 Prometheus 告警规定文档。

https://help.aliyun.com/docum…

目前 Kafka 根底版监控提供了 4 个告警指标。用户可依据理论状况,实例化告警规定。

  • Consumer Topic 音讯沉积。
  • 分区数量过多:为 Kafka Broker 定义保护性告警,防止分区数量过多导致性能急剧下降。
  • 存在 Under Replicated 分区。
  • 无效 Broker 数量缩小。

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

  • 部署自建 Kafka 的高级监控

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

而后拜访 ARMS 接入核心,点击组件利用“Kafka(高级版)”的“增加”按钮,在弹出界面抉择 Kafka 所部署的环境(目前反对“阿里云容器服务环境”和“阿里云 ECS 环境”),抉择 Kafka 所在的 Prometheus 实例,而后填写监控接入的配置信息。

  • Exporter 名称:以后 Kafka 监控惟一命名。
  • kafka 实例名称:Kafka 实例名称,通过该名称,将 Kafka Producer、Broker 和 Consumer 进行关联,实现 Topic 全链路的大盘展现。
  • JMX Agent 监听端口:部署 JMX Agent 时配置的监听端口。
  • metrics 采集门路:Prometheus 采集 JMX Agent 的 http path,默认是 /metrics。
  • metrics 采集距离(秒):监控数据采集工夫距离。
  • Pod/ECS 标签 / 值:部署 JMX Agent 时,给 Pod/ECS 配置的标签和标签值,Prometheus 通过此标签进行服务发现(Service Discovery)。

  • 查看高级监控大盘

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

  • 自建 Kafka Instance 大盘

展现 Kafka Broker 外部各项指标:

  • 外围指标:展现 Broker 数量、OffLine 分区数、Under Replicated 分区数、Contrller 数量、CPU/ 网络等要害信息。
  • JVM 指标:展现 JVM 的内存和 GC 要害信息。
  • 分区指标:展现分区数量、ISR、Unclean Leader 选举、Replica Lag、Offline 分区、Under Replicated 分区等明细信息。
  • 工夫指标:展现 Produce、Request、Fetch 等各个环境的工夫指标。
  • 集群流量指标:展现集群的总体流量指标。
  • Broker 流量指标:展现 Broker 粒度的流量明细指标。
  • 自建 Kafka Topic 大盘

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

  • Producer:展现 Producer 端的要害指标,包含音讯发送速度、音讯压缩率、发送提早等。
  • Server(即 Kafka Broker):展现该 Topic 对应的分区数、入 / 出音讯速率、入 / 出音讯流量。
  • Consumer:展现音讯生产速率、生产提早和 Rebalance 等。
  • 配置自建 Kafka 的高级监控告警

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

  • 自建 Kafka Producer:提供了音讯发送失败率、音讯发送耗时、音讯发送重试率等 3 个告警指标,不便用户对 Producer 端的异样进行告警。
  • 自建 Kafka Instance:提供了分区数量过多、存在 OffLine 分区、存在 UnClean Leader 选举、存在 Under Replicated 分区、无效 Broker 数量缩小、无效 Controller 数量、实例音讯回绝量、实例音讯流入 / 出量、Topic 音讯流入 / 出量等 13 个告警指标,笼罩了 Kafka Broker 各方面异样。
  • 自建 Kafka Consumer:提供了音讯生产沉积告警指标,通过该告警规定,用户能第一工夫把握生产异常情况。

结束语

阿里云 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 耗费。

点击此处,收费开明 Prometheus 监控!

正文完
 0