APM решения уже давно не являются чем-то экзотическим, множество компаний предлагает свои платформы и сервисы. А вот решения, которое может удовлетворить любые требования, пока нет, да и вряд ли такое возможно.
В каждом конкретном случае требуется выбирать индивидуально, с учетом поставленных задач и бизнес-требований, продуктивной среды и используемых технологий, выделяемого бюджета.
То, что отлично подходит одной организации, в другой может вызвать только разочарование. Важно правильно расставить приоритеты и требовать от производителей однозначных ответов на свои вопросы. Но ведь надо еще понимать, какие вопросы собственно задавать! И мы решили рассмотреть практические примеры того, о чем и в каких ситуациях необходимо спрашивать.
- Мониторинг продуктивной среды с профилированием приложений
Многие решения в подобных ситуациях создают недопустимую дополнительную нагрузку на продуктив, особенно если требуется 100% профилирование. Отсюда и возникают вопросы, на которые нужно получить ответы:
- Можно ли получить полную видимость всех классов и методов?
- Какой при этом будет дополнительная нагрузка на продуктивную среду?
- Какие возможности масштабирования? Сможет ли один управляющий сервер справляться с тысячей сообщений от агентов, не влияя при этом на работу приложения?
- Приложения с сильно распределенной или сервис-ориентированной архитектурой (SOA)
Поиск и устранение источников проблем в подобной ситуации обычно затруднен. И если APM решение не сможет непрерывно отслеживать транзакции между всеми уровнями, оно ничем не поможет.
- Пользовательский интерфейс позволяет следить только за здоровьем серверов или показывает состояние распределенных транзакций?
- Есть ли надежное автоматическое определение и визуализация связей между сервисами на различных уровнях? Измеряется ли и отображается время отклика на каждом этапе прохождения транзакции?
- Какие подходы и технологии используются для отслеживания транзакций между уровнями?
- Доступна ли диагностика на уровне кода, на каких этапах выполнения транзакций?
- Гибкая разработка с частыми релизами
Некоторые APM решения требуют ручной инструментации кода при выходе новых релизов в продуктивную среду. Это требует много усилий, времени, увеличивается вероятность ошибочных действий.
- Используется ли ручная инструментация? Если да, то сколько по времени занимает данный процесс?
- Требуется ли повторная инструментация при выходе обновлений кода?
- Есть ли возможность удобного сравнения производительности приложения после обновления кода и оперативного обнаружения источников проблем, если производительность упала?
- Динамическое окружение и плавающая нагрузка
Механизмы детектирования проблем могут вызывать ложные тревоги в подобной среде, если они основываются на статических настройках и вручную заданных порогах срабатывания.
- Реализовано автоматическое изучение нормального поведения приложения или требуется задавать пороги вручную?
- Учитывает ли поведенческий анализ тот факт, что нагрузка в разные дни и время суток отличается?
- Существуют ли механизмы определения «нормальных» отклонений и автоматического принятия решений на основе поведенческого анализа?
- Как поведет себя система мониторинга при динамических изменениях в среде?
- Для нас критично минимизировать среднее время разрешения проблем
Важно понимать, как собирается диагностическая информация и какого она качества. Кроме того, нужно быть готовым к тому, что некоторые предлагаемые решения не умеют отслеживать нестандартные вещи, например распределенный кэш, объектно-реляционное отображение или NoSQL базу данных. В результате могут образоваться слепые зоны, затрудняющие поиск источников проблем.
- Все ли элементы архитектуры и среды приложения поддерживаются? Если нет, то есть ли возможность это исправить, и сколько времени на это уйдет?
- Если возникает проблема, реализован ли автоматический сбор диагностики или требуется запускать ручную сессию?
- Собираются ли детальные данные по каждому случаю, вплоть до уровня кода?
- Умеет ли решение отличать единичные аномалии от хронически плохой производительности? Как выделяются систематические проблемы?
- Есть ли специфическая диагностика для различных случаев – ошибок, зависаний, медленного времени отклика, проблем с памятью и т.д.
- Требуется простое и удобное внедрение и использование
Часто занятость сотрудников и ограничения бюджета не позволяют выделить кого-то специально для обслуживания еще одной системы (APM), инструментации кода, построения дашбордов, изучения алертов и т.п.
- Можно ли самостоятельно в короткие сроки развернуть и запустить платформу мониторинга?
- Насколько интуитивен пользовательский интерфейс? Требуется ли клиент или можно ли работать с системой из браузера?
- Какие данные предоставляются при диагностике – требуются ли экспертные компетенции или существует автоматическое определение источников проблем?
- Ограниченный бюджет
Для получения прозрачной общей стоимости владения необходимо учитывать стоимость как самого продукта, так и требуемых людских и инфраструктурных ресурсов. Иногда имеет смысл рассматривать вариант работы по сервисной модели обслуживания.
- Какая изначальная стоимость лицензий, включая различные агенты, управляющие сервера и т.п.?
- Какие физические ресурсы потребуются для полного развертывания системы мониторинга?
- Нужны ли отдельные компетенции для конфигурирования и инструментации, сколько времени в год на это ориентировочно уходит?
- Есть ли отдельная стоимость поддержки и обновлений продукта?
Ответы на все эти вопросы помогут осознанно выбрать решение. О самих решениях APM мы периодически рассказываем в наших статьях. А о практическом опыте использования продуктов можно узнать у специалистов ALG Systems и в нашей DevOps Hub группе на Linkedin.
