В чем цель идеальной системы управления производительностью приложений (Application Performance Management, APM)? Означает ли это доступность в 99.999%? Или что-то еще? На самом деле могут быть различные цели в зависимости от различных потребностей бизнеса, и APM может даже зависеть от собственно приложений.

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

• Доступность в минимум  99.999% с минимальным временем определения причины инцидента (Mean Time To Know, MTTK) и временем исправления проблемы (Mean Time To Repair, MTTR).
• Время отклика меньше, чем 50 миллисекунд  для 95% запросов приложения.
• Изоляция проблем конечного пользователя в пределах трех минут.

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

• Отслеживание и определение трендов наиболее популярных типов поведения (например, объем трафика)
• Исторический тренд как ресурсы потребляются серверами и приложениями, необходимыми для обслуживания пользователей.
• Возможность отслеживать опыт конечного пользователя (End User Experience, EUE) и управление опытом пользователя (User Experience Management, UEM)*. Терминология Gartner.
• Тренды доступности приложений. Эта возможность включает в себя детали того, как высчитывается время доступности.
• Долговременные записи времени отклика каждой конечной системы для использования различными функциями в режиме день/неделя/месяц.
• Тренды количества подключенных пользователей.
• Тренд трафика и задержки транзакций между серверами в виртуальной среде.
• Связывание трафика пользователя с пользовательским  именем.
• Открытый интерфейс для аналитических систем к собранной информации.

Можно ли ваши приложения контролировать?
Что означает, что приложение позволяет себя контролировать? Как мы можем осуществлять мониторинг, чтобы убедиться, что они корректно работают и обслуживают 100% пользователей? Что, если соединение закроется и как мы это обнаружим? Что, если процесс "подвиснет", как мы узнаем об этом? Есть несколько вопросов, которые необходимо задать о приложении, которое мы предполагаем контролировать:

• Под управлением какой ОС работает приложение?
• Может оно работать в среде VMware?
• Используется кластеризация серверов?
• Как много процессов поддерживает каждый сервер, какие это процессы и в чем их функции/взаимоотношения?
• Поддерживает приложение логи? Могут они отсылаться как syslogs?
• Будет использоваться SAN?
• Приложение на базе WEB или традиционное?
• Использует приложение TCP/IP или UDP/IP?

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

• NetFlow использует IP SLA для тестирования транзакций (например, URL).
• Маршрутизаторы Cisco могут конфигурироваться для экспорта метрик производительности со скоростью соединения каждой конечной системы.
• В большинстве случаев syslog и event logs могут экспортироваться с помощью IPFIX, который коррелируется с традиционным NetFlow.
• VMware и виртуальные коммутаторы поддерживают экспорт NetFlow и зонды NetFlow, при необходимости.