jvm - 监控 worker 在 apache Storm 中崩溃

Question

在集群中运行时，如果发生错误，工作人员通常会死亡(JVM 关闭)。它可能由多种因素引起，大多数情况下，找出导致崩溃的原因是一项挑战( Storm 最大的困难？)。

当然，storm-supervisor 会重新启动死亡的 worker，并且在 Storm 集群中的活跃度非常好，但是 worker 崩溃仍然是我们应该避免的一团糟，因为它会增加开销、延迟(在发现 worker 死亡并重新生成之前可能会很长)如果您没有设计拓扑来防止这种情况发生，并且数据丢失。

有没有一种简单的方法/工具/方法来检查 Storm worker 何时以及可能为什么崩溃？它们没有显示在storm-ui中(而显示了监督者)，并且一切都需要非常小心的手动监控(例如使用jstack + JVM opts)。

以下是可能发生的一些情况:

超时和许多可能的原因:Java 垃圾收集缓慢、网络不良、超时配置中的大小调整不当。我们从主管日志中获得的唯一输出是“状态:超时”或“状态:不允许”，这很糟糕。此外，当工作人员死亡时，storm-ui 上的统计信息会重新启动。当您害怕超时时，您最终会使用很长的超时，这似乎不是实时处理的好解决方案。

高背压与意外行为，例如使 worker 心跳不足并导致超时。 Acking 似乎是处理背压的唯一方法，需要根据您的负载精心制作 bolt 。不确认似乎是行不通的，因为它确实会使工作人员崩溃并最终得到糟糕的结果(甚至比压力下的确认拓扑处理的数据更少？)。

代码运行时异常，有时不会在需要手动检查应用程序日志的 Storm-ui 中显示(最简单的情况)。

可以通过 JVM 转储发现的内存泄漏。

Answer 1

Storm 主管日志超时重启。
您可以监控主管日志，也可以监控您的 bolt 的 execute(tuple) 方法的性能。

至于内存泄漏，由于storm supervisor确实杀死了-9 worker，堆转储很可能被破坏，所以我会使用动态监控堆的工具或杀死supervisor的工具通过jmap产生堆转储。另外，尝试监视 gc 日志。

我仍然建议增加默认超时。