我们正在使用apache storm。突然间拓扑结构就不再有新的事件发生了。查看zookeeper，我们可以看到一个背压节点正在被创建。
的例子炼金术士/风暴/反压力/OurTopology/ba786e4c - 5119 - 4 - ebc - 856 b - 6 - d02d3740d64 - 6707
这表明节点ba786e4c- 519 -4ebc-856b-6d02d3740d64引起背压，该节点正在6707上侦听。
但是我没有看到这个工人的任何日志。我们可以通过哪些步骤和指标来调试导致反压的原因?
根据这个和这个链接，Storm节流当出现反压力时，有喷嘴。更准确地说，会发生以下情况:
- 如果一个执行器的接收队列已满，则通知一个反压线程
- 这个反压线程与ZooKeeper通信，在给定的拓扑上发生反压
- ZooKeeper通知所有worker必须节流喷口
- 喷口控制发送速度/事件速率。
显然，拓扑不会像您的情况那样崩溃。
我在这里推荐一些东西:
-
检查所有日志从所有主管，工人和云雾中观察到任何错误。我经常检查Storm日志中的日志和错误。根据上面的参考和Storm文档，有几个参数影响背压的行为。也许你可以试试这些，看看是否有任何效果:
topology.max.spout.pending:根据第二个链接，它是在给定时间拓扑中可以等待确认的元组的数量。- 背压系统依赖于螺栓的接收缓冲区大小有多满。这就是为什么有了水印的概念。高水位和低水位定义缓冲区满或空的程度，以便节流喷口或重新启动它:
disruptor.highwatermark(默认为0.9)。这意味着，对于0.9，发送完整的信号，并在螺栓的接收缓冲区满90%时节流喷口。 disruptor.lowwatermark(默认为0.4)表示0.4，发送未满信号，当螺栓接收缓冲区下降到 容量的40%以下时重新启动喷管
- 使用Storm Metrics更精确地分析过程。以下是一些值得观察的指标:
__skipped-backpressure-ms:此指标记录由于背压指示拓扑中的下游队列太满而导致喷口空闲的时间。arrival_rate_secs:在一秒钟内插入队列的元组数量的估计，尽管它实际上是退出队列的速率。sojourn_time_ms是根据到达率计算的，并且是每个元组在被处理之前在队列中停留的毫秒数的估计。
然而，Storm Metrics是一个痛苦，因为这些文件定期记录到磁盘。设置监控工具可能会有所帮助。不幸的是，唯一提到的监测工具是风暴石墨，似乎没有得到维护。我也读过一次有人使用Grafana或其他工具。
总而言之，我对你如何解决这个问题很感兴趣。