Декомпиляция Java-методов на продуктивном приложении под нагрузкой – миф или реальность?10.11.2016 10:33

Тестирование, несомненно, является одним из китов, на которых стоит разработка приложений. Как и любой характерный кит, тестирование может зафонтанировать багами и долго не останавливаться. Но главный вопрос заключается в достаточности тестового покрытия — все ли баги по написанным тест-кейсам удастся отловить? Возможно, некоторые появятся только под пользовательской нагрузкой. Для выявления оных, как правило, детонирует обращение пользователя и далее задействуется следующая цепная реакция: специалист Help Desk, вторая линия поддержки и, если повезет, сообщение о нештатной работе попадет в руки разработчика. Да, инцидент может также прийти от системы APM-мониторинга (если она у вас есть, конечно). Но все эти вещи не позволят однозначно определить, какие значения принимали переменные до возникновения исключения. В посте мы как раз поговорим о решении, призванном в помогать в подобных ситуациях.

Устраивайтесь поудобнее. Поговорим об OverOps — решении для обнаружения ошибок в работе приложений на Java, Scala, Clojure и Groovy. Покажу несколько скриншотов и расскажу об основных фичах продукта. Во вступительной части не случайно шла речь о тестировании. Ошибки. возникающие в продуктивной среде совсем не обязательно появятся в среде разработки и тестирования. А нагрузка реальной пользовательской активностью может выдать доселе невиданные исключения.

Суть работы OverOps в следующем:

1) при старте JVM рядом с ней запускается агент OverOps;
2) агент умеет мониторить возникновение в коде исключений (как обрабатываемых, так и не обрабатываемых);
3) агент в момент возникновения исключения снимает heapdump и накладывает его на декомпилированный байткод.

В итоге можно увидеть, какие значения принимали переменные до момента возникновения исключения. При работе агента вендор заявляет его максимальный overhead в 3%. На нашем лабораторном стенде при небольшой нагрузке приблизиться к этому показателю очень сильно не удалось, поэтому пока верим на слово.

Уж не знаю кому как, но мне особое удовольствие доставляют монстры, которые периодически мелькают то там, то сям в интерфейсе. Оказывается, у OverOps есть целый монстрический набор, отдельные представители которого материализуются при возникновении соответствующих ошибок. Забавно, да?

В самом интерфейсе это выглядит примерно так:

Система собирает снапшоты на периодической основе (т.е. мы увидим не все ошибки, но увидим их количество). Можно создавать правила, например,»10 ошибок такого-то типа»: «сообщи туда-то» («заведи баг в Jira», «черкани в Slack», «запости в Твиттер» и т.д.). Полный список интеграций можно посмотреть по ссылке.

Вот пример моей тестовой интеграции с NewRelic. Детали отображаются на вкладке Plugins и сопровождаются прямой ссылкой в OverOps, что, прямо скажу, весьма удобно:

OverOps умеет фильтровать сторонние библиотеки на предмет исключения их из мониторинга. В самом интерфейсе это выглядит как-то так:

Еще из функциональных возможностей: присоединение исходного кода извне, фильтрация ошибок, если в них содержатся персональные данные (настраивается через регулярные выражения). Из небольших минусов: не умеют показывать тип объекта, если он был унаследован от базового типа, а сигнатура метода принимает базовый тип.

По типу инсталляции решения предоставляются все возможные сценарии: SaaS, Hybrid, On-Premise.

Сейчас уже, конечно, поздновато говорить о том, что в высокий сезон OverOps был бы очень кстати — ведь именно в периоды повышенной нагрузки есть большие шансы отловить разные ошибки, которые в другое время себя никак не проявляли. Но к следующим праздникам и релевантной им пиковой посещаемости все же стоит задуматься о тщательном мониторинге вашей ритейл-системы. Пожалуйста, обращайтесь с вопросами в комментариях. А если задача требует чуть более вдумчивого подхода, наш консалтинг он, как свет в окошке в пургу и вьюгу, — всегда появляется в нужный момент.

Автор статьи: Антон Касимов, архитектор систем управления

Комментарии (0)