应用错误收集

我在t2.medium个实例上构建了一个3节点kafka集群。 Zookeeper和Broker部署在同一个ec2实例中。 ec2实例分布在一个区域内的3个差异区域中。安装程序如下：

Zookeeper具有以下内存设置：export KAFKA_HEAP_OPTS="-Xmx512M -Xms512M"
Broker具有以下内存设置：export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"
Kafka Version - 0.10.1.1正式符合spring-boot 1.5.10
与Kafka捆绑的Zookeeper正在用于安装。

流量模式：流量不高（可能是4 msgs / sec），但是大量的消息（500 msgs / sec）可以在短时间内到达[2-3分钟]。

面临的问题： 1.在broker server.log

INFO Partition [topic1,0] on broker 0: Shrinking ISR for partition [topic1,0] from 0,1,2 to 0 (kafka.cluster.Partition)

INFO Partition [topic1,0] on broker 0: Cached zkVersion [8] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition)

这使得群集不稳定，并且在执行所有代理（也有时是动物园管理员）的滚动重启之前，群集永远不会自行恢复。

从AWS EC2控制台中可用的度量标准进行检查时，没有明显的新问题，除了流量高峰。问题开始时，从nw角度看日志中也没有任何内容。看起来有一个GC运行，在它开始报告时，然后持续报告kafkaServer-GC.log，直到执行整个群集的滚动重启。

处理这种情况的正确实例类型应该是什么？建议什么是理想的内存设置？在这方面是否还有其他可以纠正的配置？
有没有办法找出有问题的节点？
我们如何决定单独重启代理是否有帮助，或者所有经纪人是否也需要重启？
我们如何决定是否还需要重启zookeeper，和/或所有zookeeper实例都需要重启？有没有办法使用zookeeper-shell.sh与kafka捆绑的4个字母单词？
早期发现这种情况的主动监测步骤是什么？

这里非常需要一些指导，不用说它是非常赞赏的！

可能您的流量选择导致此问题，您的经纪人失去了接收器状态。您需要微调一些参数，其中一些参数在官方文档中引用：

与大多数分布式系统一样，自动处理故障   需要准确定义节点的含义   ＆＃34;活＆＃34 ;.对于Kafka节点，活跃度有两个条件



节点必须能够使用ZooKeeper维护其会话（通过ZooKeeper的心跳机制）



如果它是一个奴隶，它必须复制在领导者身上发生的写作，而不是fall太远＆＃34;



我们将满足这两个条件的节点称为＆＃34;同步＆＃34;   避免＆＃34;活着＆＃34;模糊或＆＃34;失败＆＃34;。领导者保持跟踪   同步＆＃34;同步＆＃34;节点。如果追随者死亡，被困，或   落后，领导者将其从同步列表中删除   副本。远远落后的定义是受控制的   通过 replica.lag.max.messages 配置和a的定义   卡住的副本由 replica.lag.time.max.ms 控制   配置。

还要尝试使用代理堆内存（请参阅this）。

关于监控，通过JMX，您可以观看很多指标，尤其是：

ISR收缩率＆amp; ISR扩张率

参考：https://kafka.apache.org/082/documentation/#ops

EC2上的Kafka Cluster面临“缩小分区ISR”和“缓存zkVersion []不等于zookeeper中的问题，跳过更新ISR”

1 个答案: