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

    Тестирование, несомненно, является одним из китов, на которых стоит разработка приложений. Как и любой характерный кит, тестирование может зафонтанировать багами и долго не останавливаться. Но главный вопрос заключается в достаточности тестового покрытия – все ли баги по написанным тест-кейсам удастся отловить? Возможно, некоторые появятся только под пользовательской нагрузкой. Для выявления оных, как правило, детонирует обращение пользователя и далее задействуется следующая цепная реакция: специалист 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 был бы очень кстати – ведь именно в периоды повышенной нагрузки есть большие шансы отловить разные ошибки, которые в другое время себя никак не проявляли. Но к следующим праздникам и релевантной им пиковой посещаемости все же стоит задуматься о тщательном мониторинге вашей ритейл-системы. Пожалуйста, обращайтесь с вопросами в комментариях. А если задача требует чуть более вдумчивого подхода, наш консалтинг он, как свет в окошке в пургу и вьюгу, – всегда появляется в нужный момент.

    Автор статьи: Антон Касимов, архитектор систем управления, компания «Инфосистемы Джет».
    Инфосистемы Джет
    163.61
    Системный интегратор
    Share post

    Comments 4

      0
      агент в момент возникновения исключения снимает heapdump

      HeapDump снимается при каждом исключении?
        0
        Не при каждом исключении. Т.е. при первом появлении такого исключения, конечно, снимают. А при следующих появлениях только считают. Как вендор пишет:

        For each exception or error, we take snapshot of the code and state only for some of the occurrences of this event. We basically sample it, according to a certain algorithm — we will always capture it when it first happens, but it happens 1M time in the first hour, we will slow down and take a certain number of samples.
        0
        Смотрел я этот продукт в свое время — дорогое решение. А повторить самому такое с JVMTI можно только используя агент на C/C++, очень сложно потом еще агрегаты считать и хранить да еще и сотни дашбордов для kibana рисовать…
          0
          Ну никто же не мешает договориться о дисконте :) Да, и у них оплата только по подписке, постоянных лицензий нет. Самостоятельная разработка? Да не стоит оно того, конечно

        Only users with full accounts can post comments. Log in, please.