风暴专家，
我们正在使用风暴0.8.2并且具有带有1个喷口的拓扑结构，其向Bolt 1发出元组，其执行一些处理，网络调用＆amp;过滤＆amp;向Bolt 2发射.Bolt 1 to Bolt 2减少了20％，新发出的元组仅占收到的总元组的80％。 螺栓2进行进一步处理＆amp; db调用并向Bolt 3发出元组.Bolt 2丢弃了近50％的不必要消息，并创建了仅发送50％的新元组， Bolt 3进行大量的Web调用，在线程中运行（每个执行程序产生10个线程）并向Bolt 4发出新的元组，几乎90％的传入消息。 Bolt 4对收到的消息进行最终处理并发送到数据库。
我们正在运行1个喷口，50个Bolt 1执行器，8个Bolt 2执行器，120个Bolt 3执行器和100个Bolt 4执行器。它们在AWS的8核机器上运行8个工作人员。
我们面临的问题是在几个小时内，其中一名工人（随机的7名中的任何一名，没有可观察的模式）停止发射。我们添加了一些日志消息来检查此时是否正在每个执行程序中调用execute，并且正如预期的那样，不会调用execute，因为在此期间消息不在日志文件中。
当该工作人员在其上运行喷口时，整个拓扑结构都是零排放。
令人惊讶的是，由于心跳在那里，灵气或主管不会重启任何执行器/工作人员。日志文件没有显示异常。此外，它不是针对单个执行者而是针对整个工作者。通过sudo kill pid杀死worker时，当worker再次活动时重新启动消息流并重新启动该worker的执行者。
有没有办法监控Transfer Queues / Executor Queue / ZeroMQ中的待处理消息？也许这将有助于我们更好地调试。 有没有人早点遇到这样的问题？是否与每个Bolt上的元组数减少有关？