监测Storm螺栓的潜伏期
我正在尝试测量拓扑中每个bolt的延迟。Storm给出的延迟数是不够的，因为我们想要计算百分位数。在我当前的设置中，我通过测量完成execute方法（包括发出调用）所需的时间来测量bolt的延迟。该方法的假设是,即使当前bolt实例和下一个bolt实例在拓扑结构中共享同一个执行器,收集器的emit也会立即返回,而不需要调用下一个bolt实例执行方法。
共有1个答案
通过将计时器放在execute方法的开头和结尾（在emit之后），您应该就可以了。
-
下面是我的拓扑Storm UI的截图。这是在拓扑完成处理10K消息之后拍摄的。 （拓扑配置为4个工作者并使用KafkaSpout）。 我的螺栓的“进程延迟”之和约为8100ms，而拓扑的完整延迟要长得多，为115881ms。 *请注意，在进程和执行延迟之间有很大差异的一个bolt实现了ticking bolt，批处理模式。因此这种差异是预料到的。 *编辑。我怀疑这种差异可能涉及到消息在完全处理后被
-
因此，如果您使用基于JUnit的单元测试，是否建议您运行一个小型模拟拓扑(？）并测试该拓扑下的（或)的隐含契约？或者，是否可以使用JUnit，但这意味着我们必须仔细模拟Bolt的生命周期（创建它、调用、嘲弄等）？在这种情况下，被测类（螺栓/喷口）有哪些一般的测试点需要考虑？ 其他开发人员在创建正确的单元测试方面做了什么？ 我注意到有一个拓扑测试API（参见：https://github.com/x
-
我用Kafka-Storm来连接Kafka和Storm。我有3台服务器运行zookeeper，kafka和Storm。Kafka中有一个主题“测试”，它有9个分区。 在storm拓扑中，KafkaSpout执行器的数量是9，默认情况下，任务的数量也应该是9。“提取”螺栓是唯一连接到KafkaSpout的螺栓，即“原木”喷口。 从用户界面来看，喷口的失败率很高。但是，bolt中执行的消息数=发出的消
-
我有一个非常简单的Storm螺栓，从Kafka喷口输入，应该只是写到标准输出。它扩展了BaseRichBolt。有关的两种方法是：
-
在我的拓扑中，当元组从spout转移到bolt或从bolt转移到bolt时，我看到大约1-2 ms的延迟。我使用纳秒时间戳来计算延迟，因为整个拓扑运行在单个Worker中。拓扑是在集群中运行的，集群运行在具有生产能力的硬件中。 根据我的理解，在这种情况下，元组不需要序列化/反序列化，因为所有东西都在单个JVM中。我已经将大多数喷流和螺栓的并行性提示设置为5，并且喷流仅以每秒100的速率产生事件。我
-
我对Apache Storm有一个奇怪的问题。我有一个Kafka连接到Kafka集群，里面有10条消息。 螺栓接收每条消息并正确处理，因为在Storm UI中，螺栓被列为“已确认”。然而，storm UI下面列出的喷口表示所有元组都失败了。 我相信这会导致喷口再次发出所有的信息。。。因此，我看到一个Storm螺栓打印出消息1-10，然后以相同的顺序一次又一次地打印出来。 我适当地调用了和方法，我只