Как узнать, какой болт не атакует в топологии шторма? - PullRequest
Новая
       21

Как узнать, какой болт не атакует в топологии шторма?

0 голосов
/ 28 июня 2019

Я работал над топологией шторма и столкнулся с некоторыми сбоями кортежей. Я подозреваю, что один из болтов в конкретном случае не срабатывает, вызывая эти сбои по таймауту. Есть ли способ в Apache Storm API (0.10.0) определить, какой болт не является ожидающим?

Предположим, у нас есть MySpout, BoltA и BoltB в качестве компонентов этой топологии, а MySpout испускает кортежи для обоих болтов, ожидая, что они получат подтверждение после обработки кортежей. BoltA в методе executeTuple () всегда получает подтверждение, но BoltB выполняет проверку только для четных значений, которые он получает. Все кортежи с нечетными значениями выйдут из строя через 10 минут после их отправки.

В этом небольшом образце легко определить сбойный поток. Но в сложной системе, в которой мы можем следить за десятками различных потоков, имеющих несколько болтов, это все равно, что искать иголку в стоге сена. Есть какой-нибудь умный способ найти этот сбой? 

public class MySpout extends BaseRichSpout {
    protected SpoutOutputCollector collector;
    //...
    @Override
    public void nextTuple() {
        Integer msgId = new Integer((int)(Math.random() * 5000 + 1));
        collector.emit(new Values(msgId), msgId);
    }
    @Override
    public void fail(Object msgId) {
        new Exception("Failed tuple. msgId="+msgId).printStackTrace();
    }
}

public class BoltA extends BaseRichBolt {
    private OutputCollector outputCollector;
    //...
    @Override
    protected void executeTuple(Tuple input) {
        Integer n = (Integer) input.getValues().get(0);
        outputCollector.ack(input);
    }
}

public class BoltB extends BaseRichBolt {
    private OutputCollector outputCollector;
    //...
    @Override
    protected void executeTuple(Tuple input) {
        Integer n = (Integer) input.getValues().get(0);
        if (n%2==0) {
            outputCollector.ack(input);
        }
    }
}

Для этого шторма было настроено время ожидания 10 минут. 

<!-- storm config -->
<property>
    <name>topology.enable.message.timeouts</name>
    <value>true</value>
</property>
<property>
    <!-- 10 mins -->
    <name>topology.message.timeout.secs</name>
    <value>600</value>
</property>

Это трассировка стека, которую мы видим при сбое кортежа. Я пытался извлечь некоторую информацию о потоке ошибок кортежа. Он не сказал ничего, что помогло бы мне. 

java.lang.Exception: Failed tuple. msgId=1234
at MySpout.fail(MySpout.java:127) [myJar.jar:?]
at backtype.storm.daemon.executor$fail_spout_msg.invoke(executor.clj:401) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.daemon.executor$fn$reify__4467.expire(executor.clj:461) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.utils.RotatingMap.rotate(RotatingMap.java:73) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.daemon.executor$fn__4464$tuple_action_fn__4470.invoke(executor.clj:466) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.daemon.executor$mk_task_receiver$fn__4455.invoke(executor.clj:433) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.disruptor$clojure_handler$reify__4029.onEvent(disruptor.clj:58) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.utils.DisruptorQueue.consumeBatchToCursor(DisruptorQueue.java:125) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.utils.DisruptorQueue.consumeBatch(DisruptorQueue.java:87) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.disruptor$consume_batch.invoke(disruptor.clj:76) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.daemon.executor$fn__4464$fn__4479$fn__4510.invoke(executor.clj:578) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at backtype.storm.util$async_loop$fn__543.invoke(util.clj:475) [storm-core-0.10.0-beta1.jar:0.10.0-beta1]
at clojure.lang.AFn.run(AFn.java:22) [clojure-1.6.0.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_45]

1 Ответ

0 голосов
/ 29 июня 2019

Носик не знает, какой болт вызвал сбой кортежа, поэтому в трассировке стека ничего не видно.

Я буду использовать код 1.2.2 для ответа. Вероятно, вы можете сделать то же самое в 0.10.0, но эта версия древняя, и я не хочу копаться в ней.

Один из способов отладки - включить ведение журнала отладки в Storm при отправке топологии. 

Config config = new Config();
config.setDebug(true);
//submit your topology using this Config

При сбое в кортеже вы получите журнал типа

2019-06-29 12: 16: 09.552 oasdexecutor Thread-11-word-executor [16 16] [INFO] SPOUT Сбой 32496024444700129: {: stream "default",: values ​​[84 1561716922356 116]} ПРИЧИНА: TIMEOUT MSG-ID: 116

После этого вы можете выяснить, какой болт не атаковал кортеж. Если вы ищете в своем журнале идентификатор кортежа (здесь это значение 32496024444700129), вы увидите журналы для каждого переноса на болт этого кортежа, например,

2019-06-29 12: 15: 22.356 oasdexecutor Thread-11-word-executor [16 16] [INFO] Передача кортежа [dest: 4 кортеж: источник: слово: 16, поток: по умолчанию, id: { 32496024444700129 = 5923978744049352856}, [84, 1561716922356, 116]]

Это говорит мне о том, что кортеж был перенесен в задачу 4. Когда началась топология, он записал, какой болт был задачей 4, вы также можете увидеть это в пользовательском интерфейсе Storm.

2019-06-29 12: 15: 08.801 o.a.s.d.executor main [INFO] Загрузка исполнителя восклицает1: [4 4]

Я вижу, что задание 4 вызвало кортеж, так что это не причина истечения времени ожидания кортежа

2019-06-29 12: 15: 22.359 o.a.s.d.task Thread-17-exclaim1-executor [4 4] [INFO] Излучение: exclaim1 __ack_ack [32496024444700129 7387867738466240036]

Я также вижу, что задача 4 перенесла кортеж в задачу 8

2019-06-29 12: 15: 22.359 oasdexecutor Thread-17-exclaim1-executor [4 4] [INFO] ПЕРЕДАЧА кортежа [dest: 8 tuple: source: exclaim1: 4, поток: default, id: { 32496024444700129 = 3796756412183316156}, [84 !!!]]

и эта задача 8 обработала его

2019-06-29 12: 15: 22.363 oasdexecutor Thread-5-exclaim2-executor [8 8] [INFO] Обработка полученного сообщения FOR 8 TUPLE: источник: exclaim1: 4, поток: по умолчанию, id: {32496024444700129 = 3796756412183316156}, [84 !!!]

Нет лога, что задача 8 проверила этот кортеж, так что задача 8 - это болт, который не получил правильное подтверждение.

Я смотрю задачу 8 в журнале и получаю

2019-06-29 12: 15: 08.446 o.a.s.d.executor main [INFO] Загруженные задачи исполнителя exclaim2: [8 8]

Так что "exclaim2" - это болт в моей топологии, который не проверяется правильно.

...