Введение

В этой статье я собираюсь представить вам Lightrun, очень полезный инструмент, который я обнаружил недавно при разработке RevoGain, помогающий мне отлаживать проблемы, возникающие в продакшене.

Lightrun не похож ни на один другой инструмент, который я использовал раньше, поскольку он позволяет нам динамически вставлять записи в журнал во время выполнения, делать снимки и даже вводить метрики без изменения вашего производственного кода.

Это особенно полезно при расследовании сообщённых клиентами проблем, поскольку мы можем выяснить причину проблемы, в то время как пользователь выполняет действия, которые могут воспроизвести проблему. Круто, правда?

Начало работы с Lightrun

Настройка Lightrun очень проста и займет у вас менее 5 минут:

  • Шаг 1. Установите подключаемый модуль Lightrun IntelliJ IDEA, который работает как с редакцией Ultimate, так и с редакцией Community.

  • Шаг 2. Создайте учетную запись на платформе приложения Lightrun.

  • Шаг 3. Установите агент Lightrun JVM, который будет использоваться для самоанализа нашего приложения. На платформе Lightrun App вы можете найти инструкции по настройке агента в зависимости от ваших требований к системе разработки и производственной системе.

  • Шаг 4. Настройте приложение для использования агента Lightrun JVM.

В моем случае, поскольку RevoGain является приложением Spring Boot, я могу использовать агент в своей локальной среде Windows, например так:

java -agentpath:%USER_HOME%/agent/lightrun_agent.dll ^
     -jar revogain-%REVOGAIN_VERSION%.jar

И для производственной системы я могу использовать эту команду Linux:

java -agentpath:~/agent/lightrun_agent.so -jar revogain-$REVOGAIN_VERSION$.jar

Динамически журнал Lightrun

Очень распространенная проблема с парсингом торговых отчетов — это когда торговый баланс не сходится. Это может произойти из-за операций, которые еще не поддерживаются, или из-за того, что: либо файл оператора, либо логика парсинга повреждены.

Для отладки таких проблем требуется наличие торгового отчета, но, к сожалению, не все клиенты готовы предоставить ее нам для локальной отладки. Таким образом, в этих конкретных случаях добавление динамической записи в журнал поможет нам обнаружить проблему, пока пользователь анализирует свои отчеты.

Итак, добавим динамическую запись в журнал, отображающую рассчитанный торговый баланс для конкретного пользователя:

Текстовое поле Format определяет сообщение, которое будет зарегистрировано. Заполнитель {calculatedBalance} будет заменен значением локальной переменной calculatedBalance при выполнении рассматриваемого метода.

Текстовое поле Condition позволяет нам определить критерии фильтрации, такие чтобы сообщение регистрировалось только в том случае, когда предоставленное условие оценивается как true. В нашем случае мы хотим отобразить это сообщение только для пользователя со значением идентификатора 1, как показано на снимке экрана всплывающего окна детального журнала.

Таким образом, это сообщение журнала будет напечатано только для пользователя со значением id равным 1, а для других пользователей оно будет проигнорировано.

Сообщения журнала Lightrun печатаются в журнале приложения, но мы также можем передать их в нашу IDE.

Затем мы можем попросить пользователя импортировать новый торговый отчет, и записи журнала calculatedBalance будут напечатаны в консоли Lightrun следующим образом:

Великолепно!

Посмотрите, как рассчитывается баланс на основе торговой операции, которую мы парсим в отчете. Если рассчитанный баланс не соответствует значениям баланса, указанным в отчете, мы можем указать клиенту причину проблемы, чтобы он также мог ее проверить.

Без Lightrun мы не можем просто отладить производственную систему без остановки всего сервера, что повлияет на его доступность.

И это еще не все. Lightrun позволяет нам делать моментальные снимки (snapshots), как мы увидим в следующем разделе.

Моментальные снимки среды выполнения Lightrun

Еще одна интересная функция, предлагаемая Lightrun, — это возможность получения моментальных снимков времени выполнения, которые содержат как трассировку стека, так и переменные, имеющийся на момент создания моментального снимка.

Поскольку пользователи RevoGain ограничены странами, в которых в настоящее время работает внешний платежный процессор FastSpring, мы хотим исследовать случаи, когда страна пользователя не может быть определена, и по этой причине мы собираемся использовать следующий снимок Lightrun.

Текстовое поле Condition используется для активации моментального снимка только в том случае, если локальная переменная country равна null, что означает, что местоположение не может быть получено.

При попытке доступа к приложению с IP-адреса GeoLocationService, который не может быть обработан, мы видим, как Lightrun удается захватить контекст в памяти в момент создания снимка:

Обратите внимание на объект geoLocationDTO, который был захвачен в тот момент, когда объект country не мог быть разрешен.

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

Динамические метрики Lightrun

И мы также можем динамически добавлять метрики, не изменяя исходный код, который мы отслеживаем. Например, я использую эту функцию, чтобы выяснить, сколько времени требуется для проверки адресов электронной почты с помощью Stop Forum Spam API.

Проверка адреса электронной почты необходима потому, что в Интернете работает множество ботов, пытающихся заразить наши приложения бесполезными учетными записями, которые занимают место в базе данных.

Добавить метрику продолжительности с помощью Lightrun очень просто, и, как и в случае с динамическими журналами и моментальными снимками времени выполнения, мы можем сделать это непосредственно из IntelliJ IDEA:

Теперь каждый раз, когда пользователь регистрируется, вызов метода isSpam будет перехватываться и отслеживаться Lightrun, и мы хотим распечатать длительность вызовов в консоли Lightrun:

Потрясающе, правда?

Заключение

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

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

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

Для этой статьи я использовал уровень бесплатного пользования Lightrun, который ограничен 3 агентами. Однако, поскольку RevoGain представляет собой гигантский монолит, для меня это не проблема.

Если вы используете микросервисную архитектуру и хотите развернуть более 3 агентов, вам придется использовать версию Professional.

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


  1. Heliki
    24.04.2022 19:40
    +1

    Хотелось бы еще знать, сколько это все стоит, учитывая, что возможность on-premise инсталляции входит только в пакет Professional, цены на который на сайте не указаны.


  1. bystr1k
    25.04.2022 14:38

    А чем этот плагин отличается от базового брейкпоинта в идее? Там ведь тоже можно подключиться к удаленной jvm, поставить брейкпоинт на нужную строчку и вывести в лог нужную информацию (без остановки апп), так же с фильтрами и прочим

    И следующий вопрос - насколько сильно это бьет по перформансу работающего приложения? Вот так вот выводить строчки в лог ( да еще с учетом фильтров) - это не бесплатно же