При работе в кластере, если что-то не так, рабочий обычно умирает (останов JVM). Это может быть вызвано многими факторами, большую часть времени это сложная задача (самая большая проблема со штормом?), Чтобы выяснить причину аварии.Монитор работника падает в шлейфе Apache
Разумеется, штурмовик перезапускает мертвых работников, а в рядах шторма довольно хорошо работает, а рабочий крушение - это беспорядок, которого мы должны избегать, поскольку он добавляет накладные расходы, латентность (может быть очень долго до тех пор, пока не будет найден рабочий мертвые и возрожденные) и потерю данных, если вы не разработали свою топологию для предотвращения этого.
Есть ли простой способ/инструмент/методология, чтобы проверить, когда и, возможно, из-за сбоя шторма? Они не показаны во время шторма (в то время как наблюдатели показаны), и все требует ручного мониторинга (например, с помощью jstack + JVM opts) с большой осторожностью.
Вот некоторые случаи, которые могут произойти:
- тайм-ауты и много возможных причин: медленный сбор мусора Java, плохой сети, плохой проклейки в конфигурации тайм-аута. Единственным результатом, который мы получаем из журналов супервизора, является «состояние: тайм-аут» или «состояние: запрещено», которое плохое. Также, когда рабочий умирает, статистика по шторму-ui перезагружается. Поскольку вы боитесь тайм-аутов, вы в конечном итоге используете длинные, которые, похоже, не являются хорошим решением для обработки в реальном времени.
- Высокое давление на спине с неожиданным поведением, голодающий рабочий сердцебиение и, например, индуцирование таймаута. Acking, кажется, единственный способ справиться с противодавлением и нуждается в хорошем изготовлении болтов в соответствии с вашей нагрузкой. Не похоже на то, что это не так, как если бы это действительно привело к крушению рабочих и привело к плохим результатам в конце (даже меньше обрабатываемых данных, чем подталкивающая топология под давлением?).
- исключений для выполнения кода, иногда не отображаемых в storm-ui, которые нуждаются в ручной проверке журналов приложений (самый простой случай).
- утечки памяти, которые можно обнаружить с помощью свалок JVM.
Тайм-ауты и противодавление не похожи на сбои JVM, это поведение приложений. Вам нужен общий мониторинг для всех виртуальных машин в вашей сети или вы пытаетесь диагностировать конкретную проблему в глубину? – the8472
@ the8472 да, вы правы, это шторм. Рабочий - это Java-процесс с собственным экземпляром JVM, управляемым штормом. Плохой материал состоит в том, что он всегда терпит неудачу молча (почти ничего в рабочих журналах). Он генерируется и/или убивается другим процессом Java под названием «штурмовик», который также не регистрирует много. Я задал этот вопрос, поэтому, возможно, мы можем определить здесь правильный метод для мониторинга сбоев рабочих и облегчения задач отладки. – zenbeni
Я предполагаю, что первым шагом будет выяснение того, будут ли рабочие закрыты супервизором или выходят нечисто из-за ошибок в процессе. По-разному потенциальные причины, возможно, придется атаковать по-разному. – the8472