Вход |  Регистрация

Все Тэги

Выбор APM решения

20.03.2015357 просм.

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

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

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

  1. Мониторинг продуктивной среды с профилированием приложений

Многие решения в подобных ситуациях создают недопустимую дополнительную нагрузку на продуктив, особенно если требуется 100% профилирование. Отсюда и возникают вопросы, на которые нужно получить ответы:

  • Можно ли получить полную видимость всех классов и методов?
  • Какой при этом будет дополнительная нагрузка на продуктивную среду?
  • Какие возможности масштабирования? Сможет ли один управляющий сервер справляться с тысячей сообщений от агентов, не влияя при этом на работу приложения?

 

  1. Приложения с сильно распределенной или сервис-ориентированной архитектурой (SOA)

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

  • Пользовательский интерфейс позволяет следить только за здоровьем серверов или показывает состояние распределенных транзакций?
  • Есть ли надежное автоматическое определение и визуализация связей между сервисами на различных уровнях? Измеряется ли и отображается время отклика на каждом этапе прохождения транзакции?
  • Какие подходы и технологии используются для отслеживания транзакций между уровнями?
  • Доступна ли диагностика на уровне кода, на каких этапах выполнения транзакций?

 

  1. Гибкая разработка с частыми релизами

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

  • Используется ли ручная инструментация? Если да, то сколько по времени занимает данный процесс?
  • Требуется ли повторная инструментация при выходе обновлений кода?
  • Есть ли возможность удобного сравнения производительности приложения после обновления кода и оперативного обнаружения источников проблем, если производительность упала?

 

  1. Динамическое окружение и плавающая нагрузка

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

  • Реализовано автоматическое изучение нормального поведения приложения или требуется задавать пороги вручную?
  • Учитывает ли поведенческий анализ тот факт, что нагрузка в разные дни и время суток отличается?
  • Существуют ли механизмы определения «нормальных» отклонений и автоматического принятия решений на основе поведенческого анализа?
  • Как поведет себя система мониторинга при динамических изменениях в среде?

 

  1. Для нас критично минимизировать среднее время разрешения проблем

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

  • Все ли элементы архитектуры и среды приложения поддерживаются? Если нет, то есть ли возможность это исправить, и сколько времени на это уйдет?
  • Если возникает проблема, реализован ли автоматический сбор диагностики или требуется запускать ручную сессию?
  • Собираются ли детальные данные по каждому случаю, вплоть до уровня кода?
  • Умеет ли решение отличать единичные аномалии от хронически плохой производительности? Как выделяются систематические проблемы?
  • Есть ли специфическая диагностика для различных случаев – ошибок, зависаний, медленного времени отклика, проблем с памятью и т.д.

 

  1. Требуется простое и удобное внедрение и использование

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

  • Можно ли самостоятельно в короткие сроки развернуть и запустить платформу мониторинга?
  • Насколько интуитивен пользовательский интерфейс? Требуется ли клиент или можно ли работать с системой из браузера?
  • Какие данные предоставляются при диагностике – требуются ли экспертные компетенции или существует автоматическое определение источников проблем?

 

  1. Ограниченный бюджет

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

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

 

Ответы на все эти вопросы помогут осознанно выбрать решение. О самих решениях APM мы периодически рассказываем в наших статьях. А о практическом опыте использования продуктов можно узнать у специалистов ALG Systems и в нашей DevOps Hub группе на Linkedin.

Метки: , , , ,

Добавить комментарий

Для отправки комментария вам необходимо авторизоваться.

Партнеры DevOpsHub и DevOpsWiki