Урок №1
Материал предоставлен командой DevOps компании ALG Systems.

В этом уроке мы перечислим и опишем ключевые моменты, на которые обязательно следует обращать внимание при выборе инструментов для мониторинга Java-платформы:

Низкая дополнительная нагрузка на продуктивную среду (overhead)

Практически все APM решения работают с Java-платформой с помощью агентов. Это означает необходимость установки .jar файла, который будет собирать метрики и передавать их на сервер мониторинга. Любые обработка и анализ метрик производятся уже на стороне сервера.

Требования к дополнительной нагрузке на платформу, которая создается агентом, должны быть очень жесткими. И не только в обычном режиме работы, но и под нагрузкой. На практике overhead до 3% является нормальным, но все, что выше – уже недопустимо.

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

Мониторинг и диагностика памяти JVM

Если говорить о «здоровье» JVM, то самой важной метрикой для мониторинга является, конечно же, куча. Как только начинаются проблемы с памятью, это ведет к ошибкам, зависаниям транзакций либо стремительному росту нагрузки на CPU для обслуживания сборок мусора.

Разумеется, следует смотреть не просто на размер кучи, но и на такие метрики, как:

• Наполненность кучи
• Частота и длительность сборок мусора (minor и major)
• Текущий размер пулов памяти (например, Eden, Survivor, и т.д.).

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

Время отклика backend серверов

Типичные корпоративные Java-приложения используют стандартные API для работы с бэкендами (базами, веб-сервисами, сервисами сообщений и т.д.).

От APM требуется автоматически распознавать такие вызовы, отслеживать обращения и время отклика. Кроме того, для баз данных требуется как минимум сохранение SQL-запросов и имен процедур. Без этих данных полезность инструмента на порядок меньше, да и нормального траблшутинга проблем с неэффективным кодом не получится.

Сквозной мониторинг транзакций

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

Видимость на уровне кода

Нередко проблемы возникают из-за неэффективного кода или ошибок в логике. И просто определить, что проблемы в коде, уже недостаточно. Менеджмент интересуют на причины, а результат, а разработчикам абстрактное задание ускорить код ничего не дает. Если же с помощью инструментов APM можно определить болевую точку транзакции (например, выполнения класса или метода, откуда был вызов), то решать любые вопросы становится на порядок проще.

Динамическое изменение конфигурации агента

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

Ну и наконец, не забывайте о том, что любому комплексному решению требуется качественная поддержка. Если запросы в службу саппорта уходят в никуда, либо тянутся месяцами, то подобный продукт не будет лучшим выбором. Ведь опять же – бизнес будет требовать результатов, а не объяснений, почему еще нужно подождать.

Команда ALG DevOps Team будет благодарна за ответы на следующие вопросы: