kafka_exporter的简单介绍

本篇文章给大家谈谈kafka_exporter，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、【大数据技术】kafka简介和底层实现
• 2、kafka的命令总结和kafka集群的优点2019-12-11（小白白）
• 3、小记一次Kafka集群响应慢问题追查
• 4、Kafka相关内容总结（Kafka集群搭建手记）
• 5、不要再苦没有合适的kafka管理平台，给你分享10款kafka管理工具

【大数据技术】kafka简介和底层实现

一、 K afka的三大组件：Producer、Server、Consumer

 

1、Kafka的 Producer 写入消息

producer采用push（推）模式将消息发布到broker，每条消息，都被追加到分区中（顺序写到磁盘，比随机写内存效率高）。

· 分区的作用：方便容量扩展，可以多并发读写数据，所以我们会指定多个分区进行数据存储。

· 一般根据 event_key的hash  % numPartitions来确定写入哪个分区，如果写入时没有指定key，则轮询写入每个分区；因此导致每个partition中消息是有序的，整体无序。

每条event数据写入partitionA中，并且只会写入partitionA_leader，当partitionA_leader写入完成后partitionA_flower节点再去partitionA_leader上异步拉取数据；默认ack为1，表示不会等待partitionA_flowers写入完成；如果设置ack为副本数或ack=-1，则等待副本全部写完，再写入下一条数据。

2、kafka的 broker—— 保存消息

1、 创建topic，并指定分区和副本数

2、每个分区（partition）有一个leader，多个follower，pull数据时先寻找leader，只会读leader上的数据，leader和follower不会在一个节点上，leader节点宕机后，其中一个follower变成leader

3、 消息数据存在每个分区中，默认配置每条消息保存7天 或 分区达到1GB 后删除数据

3、 K afka的 Consumer 消费数据：

1、consumer采用pull（拉）模式从broker中读取数据。

2、如果一个消费者来消费同一个topic下不同分区的数据，会读完一个分区再读下一个分区

生产者（producer）A PI 只有一套 ；   但是消费者（consumer）A PI 有两套（高级A PI 和低级A PI ）

一、高级API：

Zookeeper管理offset（默认从最后一个开始读新数据，可以配置从开头读）

kafka server（kafka服务）管理分区、副本

二、低级API：

开发者自己控制offset，想从哪里读就从哪里读

// SimpleConsumer是Kafka用来读数据的类

// 通过send()方法获取元数据找到leader

TopicMetadataResponse metadataResponse = simpleConsumer.send(request);  //通过metadataResponse获取topic元数据，在获取topic中每个分区的元数据

// fetch 抓取数据

FetchResponse response = simpleConsumer.fetch(fetchRequest);

// 解析抓取到的数据

ByteBufferMessageSet messageAndOffsets = response.messageSet(topic, partition);

二、数据、broker状态，consumer状态的存储

一、在本地存储原始消息数据：

1、hash取模得分区、kafka中每条消息有一个Key，用来确定 每条数据存储到哪个分区中

2、轮询

3、自定义分区

二、在zookeeper存储kafka的元数据

三、存储consumer的offset数据

每个consumer有一个孝渣陆Key（broker+Topic+partition）的hash，再取模后 用来确定offset存到哪个系巧顷统文件中，Value是partitionMetaData。

1、使用zookeeper启动，zookeeper来存储offset

消费者梁手 消费消息时，offset（消费到的下标）会保存在consumer本地和zookeeper中（由本地上传到zookeeper中，所以本地会保存offset）

2、使用bootstrap启动，本地存储offset（在本地可以减少两节点交互），zookeeper存储其他数据

三、某 F lume对接Kafka案例

kafka的命令总结和kafka集群的优点2019-12-11（小白白）

描述主题的配置

bin/kafka-configs.sh --zookeeper localhost:2181 --describe --entity-type topics --entity-name test_topic

设置保留时间

# Deprecated way

bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic test_topic --config retention.ms=1000

# Modern way

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --entity-ty

在使用kafka默慎迅认安装的zookeeper启动是的命令是

/opt/kafka/bin/旦盯zookeeper-server-start.sh /opt/kafka/config/zookeeper.properties

使用我们自己安装的zookeeper启动命令是：

./zkServer.sh start

启动kafka

/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties

创建主题宽迟此：

/opt/kafka/bin/kafka-topic.sh --create --zookeeper localhost:2181 --replication-factor 1  --partitions 1 --topic 1707d

查看主题：

/opt/kafka/bin/kafka-topics.sh --list 1707d --zookeeper localhost:2181

服务器端：

/opt/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic 1707d

客户端的命令：

/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic 1707d (--from-beginning)

从第一行可以看到这个命令可以修改 topic, client, user 或 broker 的配置。

如果要设置 topic，就需要设置 entity-type 为topics，输入如下命令：

bin/kafka-configs.sh --entity-type topics

Command must include exactly one action: --describe, --alter

命令提示需要指定一个操作（不只是上面提示的两个操作），增加--describe试试：

bin/kafka-configs.sh --entity-type topics --describe

[root@localhost kafka_2.11-0.10.2.1]# bin/kafka-configs.sh --entity-type topics --describe

Missing required argument "[zookeeper]"

继续增加 --zookeeper：

bin/kafka-configs.sh --entity-type topics --describe --zookeeper localhost:2181

Configs for topic '__consumer_offsets' are segment.bytes=104857600,cleanup.policy=compact,compression.type=producer

由于没有指定主题名，这里显示了__consumer_offsets的信息。下面指定一个topic试试。

bin/kafka-configs.sh --entity-type topics --describe --zookeeper localhost:2181 --entity-name test

Configs for topic 'test' are

此时显示了test主题的信息，这里是空。

因为Kafka完善的命令提示，可以很轻松的通过提示信息来进行下一步操作，运用熟练后，基本上很快就能实现自己想要的命令。

pe topics --entity-name test_topic --add-config retention.ms=1000

如果您需要删除主题中的所有消息，则可以利用保留时间。首先将保留时间设置为非常低（1000 ms），等待几秒钟，然后将保留时间恢复为上一个值。

注意：默认保留时间为24小时（86400000毫秒）。

删除主题

bin/kafka-topics.sh --zookeeper localhost:2181 --delete --topic test_topic

注意：需要在Broker的配置文件server.properties中配置 delete.topic.enable=true 才能删除主题。

主题信息

bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test_topic

添加分区

bin/kafka-topics.sh --alter --zookeeper localhost:2181 --topic test_topic --partitions 3

创建主题

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 3 --topic test_topic

列出主题

bin/kafka-topics.sh --list --zookeeper localhost:2181

关于集群方面，我总结的几个点就在于，不管是我们开启的那个服务，数据都是可以联想的，yes,完毕

小记一次Kafka集群响应慢问题追查

某一天业务来找我，反映发数据到某一个Kafka集群特别慢。

并且他们提供了一份自己的测试结果，结果显示发送数据到Kafka集群A的平均响应延迟在10ms以内，但是发送到Kafka集群B的平均响应延迟却达到了2000ms+。

这种问题一般是比较头疼的，首先，我们Kafka集群都有监控和报警，通过查看可用性、流量变化、Kafka日志等方式，都没有发现任何异样；其逗悉兆次，响应慢也有可能和用户的使用方式和测试方法有关系。

因此第一步，我决定验证一下问题的存在。

在 kafka/bin 目录中，kafka提供山租了一个写请求性能测试脚本 kafka-producer-perf-test.sh 。

这个脚本会运行kafka中的 kafka.perf.ProducerPerformance 类，发送消息到kafka并输出CSV报告。

测试命令如下：

kafka/bin/kafka-producer-perf-test.sh --broker-list ${BROKER_LIST} --topics perf-test-topic --show-detailed-stats --messages 10000 --csv-reporter-enabled --metrics-dir ./perf-report

通过分析生成的报告，发现确实有一台节点的响应比较慢:

可以看到P999分布已经达到了1300ms左右，这显然是不正常的，但是原因是什么呢？

既然日志没有问题，那只能看一下jstack信息了：

如上发现jstack中有非常奇怪的信息，很多kafka-request-handler线程都处于阻塞状态。

这里简单解释一下kafka的处理请求线程模型，引用一篇讲 Kafka NIO网络通信的文章 中的图来说明：

如图，kafka采用了Java NIO中的selector模型。一个Acceptor线程负责接受请求，多个Processor线程负责处理请求。但实际上Processor线程只是把请求封装成kafka request，然后丢到RequestChannel中（当然也负责读取response并返回，这里不展开）。真正执行请求的是KafkaRequestHandler，即jstack中的kafka-request-handler线程。

所以当kafka-request-handler线程出现大量阻塞的时候，会极大地影响整个节点的响应效率。

关于Java线程中的BLOCKED状态，可以直接看一下Java doc说明：

可见kafka-request-handler线程是因为抢锁而发生了阻塞。我们根据jstack信息中的 kafka.cluster.Partition.appendMessagesToLeader 定位到了源码：

可以看到这个方法确实是同步的，同步对象是leaderIsrUpdateLock。由于leaderIsrUpdateLock是 kafka.cluster.Partition 的成员变量，也就是说只有在写同一个topic partition的时候，才会发陆悉生互斥等待。

所以发生上面问题的原因只可能是某个topic有大量的写请求，而且这个topic的partition数量不多，导致并发不足。

于是大量该topic的ProduceRequest占用了kafka-request-handler线程池，但是这些线程之间互相抢锁，执行效率比较低，从而导致其他topic的请求无法及时被处理。

通过分析日志和查看监控流量，定位到集群中某个topic的ProduceRequest请求的QPS占了整个集群的80%以上。

通过查看该topic监控指标中的单位时间内的消息条目数（MessagesInPerSec）和单位时间内的发送请求数（ProduceRequestPerSec），可以计算出该Topic平均不到10条消息就会触发一次kafka写请求；再考虑到partition数量，推测应该是业务采用了kafka producer的同步模式，每条消息都触发一次kafka写请求。

解决方法有两种：

当然，增加topic partition数量也能在一定程度上缓解问题，因为不同partition之间的写请求是不互斥的，但这种方式更像是治标不治本，掩盖了根本问题。

合理地发送网络请求在分布式系统中非常重要，为了提高效率，通常在权衡时效性和吞吐的情况下，以“聚少为多”的方式发送批量的请求。过多的小请求不仅会降低吞吐，还可能会压垮后端的服务。

当然，作为服务提供方，需要通过多租户、限流等方式，避免不正常使用的场景把服务压垮。

[img]

Kafka相关内容总结（Kafka集群搭建手记）

Kafka is a distributed,partitioned,replicated commit logservice。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

入门请参照：

在此不再赘述。

这部分不是本文的重点，但是kafka需要用到kafka集群，所以先搭建kafka集群。

从kafka官方文档看到，kafka似乎在未来的版本希望抛弃zookeep集群，自己维护集群的一致性，拭目以待吧。

我们搭建集群使用的是三台同机房的机团枯器，因为zookeeper不怎么占资源也不怎么占空间（我们的业务目前比较简单），所以三台机器上都搭建了zookeeper集群。

搭建zookeeper集群没什么难度，参考文档：

下面列一下我的配置并解析：

一共用三台物理机器，搭建一个Kafka集群。

每台服务器的硬盘划分都是一样的，每个独立的物理磁盘挂在一个单独的分区里面，这样很方便用于Kafka多个partition的数据读写与冗余。

/data1比较小，为了不成为集群的瓶颈，所以/data1用于存放kafka以及Zookeeper

每台机器的磁盘分布如下：

下面是kafka的简单配置，三台服务器都一样，如有不一致的在下文有说明。

kafka安装在目录/usr/local/kafka/下，下面的说明以10.1.xxx.57为例。

最重要的配置文件server.properties，需要配置的信息如下：

从上面的配置看到，kafka集群不需要像hadoop集群那样，配置ssh通讯，而且一个kafka服务器（官方文档称之为broker，下面统一使用这个称呼）并不知道其他的kafka服务器的存在，因此你需要逐个broker去启动kafka。各个broker根据自己的配置，会自动去配置文件上的zk服务器报到，这就是一个有zk服务器粘合起来的kafka集群。

我写了一个启动脚本，放在 /usr/local/kafka/bin 下面。启动脚本每个broker都一样：

如同kafka集群里面每一个broker都需要单独启动一样，蔽或携kafka集群里面每一个broker都需要单独关闭。

官方给出的关闭脚本是单独运行 bin/kafka-server-stop.sh

但是我运行的结果是无法关闭。打开脚本一看，才发现是最简单的办法，发一个TERM信号到kafka的java进程，官方脚本给出的grep有点问题。

发信号之后，一直tail着kafka日志，看到正常关闭。宏伏

指定zookeeper服务器，topic名称是LvsKafka（注意topic名称不能有英文句号(.)和下划线(_)，否则会通不过，理由是名称会冲突，下文对此略有解析）

replication-factor指出重复因子是2，也就是每条数据有两个拷贝，可靠性考虑。

partitions 指出需要多少个partition，数据量大的多一点，无论生产和消费，这是负载均衡和高并发的需要。

可以看到刚才新建的24个partition，比如partition 5， 他的leader是broker 59，也就是10.1.xxx.59这台机器。

建立topic时我们指出需要2个拷贝，从上面的输出的Replicas字段看到，这两个拷贝放在59,58两个机器，也就是10.1.xxx.59和10.1.xxx.58.

Isr表示当前partition的所有拷贝所在的机器中，哪些是还活着（可以提供服务）的。现在是59和58都还存活。

这个命令另外还会看到一些类似于下面的内容：

__consumer_offsets到底是什么呢？其实就是客户端的消费进度，客户端会定时上报到kafka集群，而kafka集群会把每个客户端的消费进度放入一个自己内部的topic中，这个topic就是__consumer_offsets。我查看过__consumer_offsets的内容，其实就是每个客户端的消费进度作为一条消息，放入__consumer_offsets这个topic中。

这里给了我们两个提示：

1、kafka自己管理客户端的消费进度，而不是依靠zk，这就是kafka官方文档说的kafka未来会抛弃zk的底气之一；

2、留意到这个kafka自己的topic是带下划线的，也就是，kafka担心我们自己建的topic如果带下划线的话会跟这些内部自用的topic冲突；

不要再苦没有合适的kafka管理平台，给你分享10款kafka管理工具

这10款工具如下：

AKHQ

Kowl

Kafdrop

UI for Apache Kafka

Lenses

CMAK

Confluent CC

Conduktor

LogiKM

kafka-console-ui

如空察果上面这个地址可以打开，可以直接去看介绍，下文也不再重复说明。

关于前8款的对比，可以看下面这张图片，图片也是于上面，我直接copy过来了（可能有好多同学打不开上面这个链接，就直接看这张图片了解了下吧）

关于这8款工具的介绍，人家说的很清晰了，这里就不再重复说明了，并且这些工具，大部分我也没用过，也没资格评价太多。

考虑到很多同学可能打开github太慢，我下面会把相关基本信息整理一下，供大家快速了解，方便选型。

概览

AKHQ (previously known as KafkaHQ)

开发语言：后端是java为主

Kowl - A Web UI for Apache Kafka

p.s. github上完整的动图这里上传失斗首茄败，就只放一个静态的截图了，如果可以打开github，建议打开下面的地址直接看吧。

但是这个并不是所有功能都是免费，有部分功能是商业版才有：

开发语言：后端是go为主

Kafdrop – Kafka Web UI

开发语言：后端以java为主

要求jdk11或更高版本

UI for Apache Kafka – Free Web UI for Apache Kafka

开发语言：后端以java为主

要求jdk13或更高版本

Lenses.io

Apache Kafka 和 Kubernetes 的实时应用程序和数据操作 #DataOps 门户。

CMAK (Cluster Manager for Apache Kafka, previously known as Kafka Manager)

这个想必很多同学都知道，原来的名字就是kafka manager。

开发语言：后端以scala为主

Confluent Inc.

Apache

Conduktor

一个商业版本的桌面客户端

官网找到一个这样的图片，凑合看吧：

LogiKM

滴滴开源的一站式Apache Kafka集群指标监控与运维管控平台。

也是分社区版和商业版的。

这个建议直接看github说明吧，都是中文，内容清晰，相关的资料也都有。

我也简单的了解了下，有个逻辑集群的概念，对于规模比较大的kafka集群管理还是挺好的，不过，这里比较高端的特性都是不开源的，必须商业版才能用。

开发语言：后端以java为主芹闹

kafka-console-ui(kafka可视化管理平台)

一款轻量级的kafka可视化管理平台，安装配置快捷、简单易用。界面风格有点类似rocketmq-console。

这款权当是“王婆卖瓜，自卖自夸”吧，一个小工具，如果刚接触kafka的同学或者是中小型集群，想找个简单易用的，可以考虑一下。

开发语言：后端以java和scala为主

参考链接：

关于kafka_exporter和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。