如何在日志中找出 Kafka 流应用程序重新平衡的原因答案

【问题标题】：How to find out in the log the cause of rebalancing in Kafka streams applications如何在日志中找出 Kafka 流应用程序重新平衡的原因
【发布时间】：2021-07-31 14:38:19
【问题描述】：

我的 Kafka 流应用程序经常不断地重新平衡。我在这里有几张红票，以及关于不同解决方案的博文。例如。 MAX_POLL_INTERVAL_MS 和 MAX_POLL_RECORDS。

我和他们一起玩过，我是静态会员。

此时我正试图从日志中找出可能的原因，因此我不是仅仅猜测和应用这些设置，而是真正理解并确定原因。

因此我要求的是我需要在代理和流应用程序上都有什么日志配置，以及我需要对哪一行日志进行 grep。

我浏览了日志，但不知道典型的错误或警告，或者 grep 的关键字，几乎不可能弄清楚发生了什么，尤其是如果代理和应用程序都处于调试状态。在不知道要 grep 什么的情况下，要查看大量日志。

因此，我应该 grep 哪些关键字？我可能会在该区域周围添加诸如 -A 20 -B 20 之类的东西。

编辑

在我的 Kafka 流应用程序中，我发现了很多

14:46:23.166 [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-1] DEBUG o.a.k.s.p.internals.StreamThread - stream-thread [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-1] Unable to commit as we are in the middle of a rebalance, will try again when it completes.
14:46:23.166 [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-1] DEBUG o.a.k.s.p.internals.StreamThread - stream-thread [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-1] Processing tasks with 2550 iterations.
14:46:23.172 [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-2] DEBUG o.a.k.s.p.internals.StreamThread - stream-thread [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-2] Processed 2886 records with 2886 iterations; invoking punctuators if necessary
14:46:23.172 [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-2] DEBUG o.a.k.s.p.internals.StreamThread - stream-thread [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-2] 0 punctuators ran.
14:46:23.172 [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-2] DEBUG o.a.k.s.p.internals.StreamThread - stream-thread [sdc-oxygen-dev-entellect-cbe-builder-resnet-12-StreamThread-2] Committing all active tasks [10_6, 28_6, 44_6, 14_6, 32_6, 2_6, 18_6, 36_6, 6_6, 24_6, 40_6] and standby tasks [] since 203216ms has elapsed (commit interval is 120000ms)

【问题讨论】：

标签： apache-kafka-streams

【解决方案1】：

分布式流处理系统 (DSP) 包含类型为 Static 和 Adaptive 的 Scheduler，它们将应用程序拓扑映射到物理节点。 Adaptive Scheduler 持续监控系统以卸载过载节点，反之亦然。但是，它可能会定期触发或基于负载阈值触发。

因此，我会猜测您的主要顾虑，可能是在特定时间间隔内重新平衡系统或系统可能遭受弱节点的影响，迫使它在为了防止灾难性的失败。

这不是所有可能的原因。但是，大多数情况下的主要原因。

【讨论】：

感谢您抽出宝贵时间。但是，您能否在 kafka、kafka stream jardon 中翻译它，此外，我可以查看日志中的哪些指标，真的很有帮助。例如，您如何找出弱节点？您是在谈论 kafka 流实例还是代理？
@MaatDeamon 请你提供一个全面的logcat，提供一个链接，看看。并且您的环境设置也很有帮助。
嗨，我已经解决了部分问题。我投票的记录太多了。将最大投票记录更改为合理的默认值就可以了。
@MaatDeamon 我的回答有帮助吗？我怎样才能帮助你更多？事实上，我正在为我的硕士论文研究 DSP。
在一般意义上，它确实有帮助。但不是我需要弄清楚的特定卡夫卡事情。从某种意义上说，它拓宽了我的调查视野。例如我检查了我的 kubernetes DNS，等等。