Декомпіляція 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 був би дуже до речі, адже саме в періоди підвищеної навантаження є великі шанси відловити різні помилки, які в інший час себе не проявляли. Але до наступних свят та релевантної їм пікової відвідуваності все ж варто задуматися про ретельному моніторингу вашої рітейл-системи. Будь ласка, звертайтеся з питаннями в коментарях. А якщо завдання вимагає трохи більше вдумливого підходу, наш консалтинг він, як світло у віконці в пургу і завірюху, – завжди з'являється в потрібний момент.

Автор статті: Антон Касимов, архітектор систем управління
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.