监视工作人员在apache风暴中崩溃

zen*_*eni 15 jvm apache-storm

在集群中运行时,如果发生错误,工作人员通常会死亡(JVM关闭).它可能是由许多因素引起的,大多数时候它是一个挑战(暴风雨的最大困难?),找出导致崩溃的原因.

当然,风暴管理员重新启动死亡工人,并且在风暴集群中活跃度相当不错,工作人员崩溃仍然是一个混乱我们应该避免,因为它增加了开销,延迟(可能很长,直到工人被发现死亡和重生)如果您没有设计拓扑来防止这种情况,则会导致数据丢失.

是否有一种简单的方法/工具/方法来检查风暴工人崩溃的时间和原因?它们没有显示在storm-ui中(而显示了监督者),并且所有东西都需要手动监视(例如jstack + JVM opts).

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

  • 超时和许多可能的原因:java垃圾收集速度慢,网络错误,超时配置错误.我们从管理程序日志本地获得的唯一输出是"state:timeout"或"state:disallowed",这很差.此外,当一名工人死亡时,关于storm-ui的统计数据将重新启动.当你害怕超时时,你最终会使用长时间的,这对于实时处理来说似乎不是一个好的解决方案.
  • 具有意外行为的高背压,饥饿的工人心跳以及例如引发超时.Acking似乎是处理背压的唯一方法,需要根据您的负载精心制作螺栓.不是acking似乎是不行,因为它确实会使工作人员崩溃并最终得到不好的结果(处理的数据比压力下的acking拓扑更少?).
  • 代码运行时异常,有时不会在storm-ui中显示,需要手动检查应用程序日志(最简单的情况).
  • 可以通过JVM转储找到的内存泄漏.

小智 1

风暴管理器日志因超时而重新启动。你可以监控supervisor日志,也可以监控bolt的execute(tuple)方法的性能。

至于内存泄漏,由于风暴主管确实杀死了-9工作人员,因此堆转储可能已损坏,因此我将使用动态监视堆的工具或杀死主管以通过jmap生成堆转储。另外,尝试监视 gc 日志。

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