通知关闭

nvbavucw  于 2021-06-04  发布在  Kafka
关注(0)|答案(2)|浏览(503)

**赏金明天到期。回答此问题可获得+100声望奖励。普拉蒂克正在寻找一个可靠来源的答案。

我有一个kafka streams应用程序,即使在调试级别也会在没有任何正确日志记录的情况下关闭-

2020-12-18 14:25:36:875 +0000 [Thread-7] INFO  o.apache.kafka.streams.KafkaStreams:? - stream-client [trinity-client-pandprat-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c] State transition from REBALANCING to PENDING_SHUTDOWN
    2020-12-18 14:25:36:973 +0000 [kafka-streams-close-thread] INFO  o.a.k.s.p.internals.StreamThread:? - stream-thread [trinity-client-pandprat-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1] Informed to shut down
    2020-12-18 14:25:36:974 +0000 [kafka-streams-close-thread] INFO  o.a.k.s.p.internals.StreamThread:? - stream-thread [trinity-client-pandprat-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1] State transition from STARTING to PENDING_SHUTDOWN
    2020-12-18 14:25:36:974 +0000 [XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1] DEBUG org.apache.kafka.clients.Metadata:? - [Consumer clientId=XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1-consumer, groupId=XXXXXX-estestes5-null] Updating last seen epoch from 0 to 0 for partition input-event-stream-client-pandprat-estestes5-0
    2020-12-18 14:25:37:075 +0000 [XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1] DEBUG org.apache.kafka.clients.Metadata:? - [Consumer clientId=XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1-consumer, groupId=XXXXXX-estestes5-null] Updated cluster metadata updateVersion 3 to MetadataCache{cluster=Cluster(id = ibD7yxLZQQSg24kQTlFnZA, nodes = [b-9.XXXXX.ap-southeast-1.amazonaws.com:9092 (id: 9 rack: apse1-az3), b-7.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 7 rack: apse1-az1), b-8.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 8 rack: apse1-az2), b-5.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 5 rack: apse1-az3), b-4.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 4 rack: apse1-az2), b-6.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 6 rack: apse1-az1), b-1.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 1 rack: apse1-az3), b-3.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 3 rack: apse1-az2), b-2.XXXX.ap-southeast-1.amazonaws.com:9092 (id: 2 rack: apse1-az1)], partitions = [Partition(topic = input-event-stream-client-pandprat-estestes5, partition = 0, leader = 9, replicas = [9,2,3], isr = [9,2,3], offlineReplicas = [])], controller = b-3.XXXXXX-msk-temp.k1lph1.c2.kafka.ap-southeast-1.amazonaws.com:9092 (id: 3 rack: apse1-az2))}
    2020-12-18 14:25:37:172 +0000 [XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1] INFO  o.a.k.c.c.i.ConsumerCoordinator:? - [Consumer clientId=XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1-consumer, groupId=XXXXXX-estestes5-null] Revoking previously assigned partitions []
    2020-12-18 14:25:37:172 +0000 [kafka-coordinator-heartbeat-thread | XXXXXX-estestes5-null] DEBUG o.a.k.c.c.i.AbstractCoordinator:? - [Consumer clientId=XXXXXX-estestes5-null-b9346744-6bb4-464d-aeaa-9311ab16ce2c-StreamThread-1-consumer, groupId=XXXXXX-estestes5-null] Heartbeat thread started

kafka版本-2.3.1代理版本-2.2.1没有抛出异常。我们还看到了一个类似的场景,应用程序从运行状态转移到挂起的关闭状态。
有人知道为什么会这样吗?

xu3bshqb

xu3bshqb1#

日志行 "Informed to shut down" 表明 shutdown 方法 StreamThread 被叫来了。只能从2调用places:-
一个-
KafkaStream close 方法-实际上是完全关闭Kafka流(最终关闭所有 StreamThreads )但是您的调试日志并不表示整个kafka流正在关闭。如果是这样的话,你会在日志下面找到的

log.debug("Stopping Streams client with timeoutMillis = {} ms.", timeoutMs);

二- RebalanceListener - onPartitionsAssigned 方法

if (streamThread.assignmentErrorCode.get() == StreamsPartitionAssignor.Error.INCOMPLETE_SOURCE_TOPIC_METADATA.code()) {
                log.error("Received error code {} - shutdown", streamThread.assignmentErrorCode.get());
                streamThread.shutdown();
                return;
            }

这可能意味着因为 INCOMPLETE_SOURCE_TOPIC_METADATA 你的 StreamThread 正在接收关闭请求。这可能是暂时的问题,也可能是永久性的失败,因为元数据不完整(如主题名不存在或拼写错误等)

f1tvaqid

f1tvaqid2#

从显示的日志来看,您的主题似乎有一个唯一的分区( partition 0 ).
这是Kafka流消费者的状态流:

但是你的消费者 PENDING_SHUTDOWN 甚至不“进入”流本身。它只是从 REBALANCINGPENDING_SHUTDOWN 以前甚至没有被分配任何分区,所以我猜您的消费者永远无法阅读主题,甚至无法输入 RUNNING 州。
编辑:消费者也可以设置为 RUNNING 即使无法从主题中阅读( DEAD ),作为 source code 州(第443行):

所以呢 RUNNING 状态可能并不自动意味着消费者能够阅读主题。
如果你的消费群体 groupId=XXXXXX-estestes5-null 已经有消费者在阅读该主题。由于主题只有一个分区,因此任何后续线程都将阻塞,直到分区可用为止。此消息还指出,您的消费者以前无法获得分配 partition 0 : Revoking previously assigned partitions [] Kafka-权威指南(o'reilly)
如果我们将更多的使用者添加到具有单个主题的单个组中,而不是添加到分区中,那么一些使用者将处于空闲状态,根本不会收到任何消息。如果消费者停止发送心跳的时间足够长,其会话将超时,组协调员将认为它已死亡并触发重新平衡
我的猜测是,你的消费者从来没有进入流量,从 CREATED 只是等待/闲着。它可能进入 RUNNING 但如上所述,这并不一定意味着它能够从Kafka那里消费。在空闲/死机一段时间后,它的会话超时,触发消费者的第一个状态上显示的重新平衡( from REBALANCING to PENDING_SHUTDOWN ).
这个消费者是由于闲置而导致重新平衡的消费者,因此自动进入 PENDING_SHUTDOWN -> DEAD .
我建议检查是否有来自同一消费群体的其他消费线索 XXXXXX-estestes5-null 正在运行并阅读该主题。您可以使用consumer groups实用程序进行检查:

bin/kafka-consumer-groups.sh --describe --group XXXXXX-estestes5-null
  --bootstrap-server <BROKER:PORT>

如果显示该组中的活动成员正在读取 input-event-stream-client-pandprat-estestes5 主题,那么你就有了为什么你的消费者会这样做。

相关问题