Многие компании, при разработке высоконадёжных критически важных приложений, полагаются на серверы приложений Java 2, EnterpriseEdition (J2EE). И речь идет о приложениях с каталогами сервисов самообслуживания, управлением портфелем в реальном времени и поддержкой пользователей 24/7. В наше время без подобных вещей легко можно потерять клиентов и деньги. Как следствие, решения по мониторингу J2EE приложений должны агрегировать данные из разных источников, обладать современным дружественным интерфейсом и определять проблемы с производительностью до того, как у пользователя произойдёт задержка отклика или отключение.
Мы коротко расскажем о том, как J2EE управляет приложениями, опишем стандартные «горячие точки», за которыми стоит понаблюдать, и предложим решения для максимизации доступности приложений, с помощью осведомленности о потенциальных проблемах.
Общая информация
J2EE был разработан для предоставления расширяемой платформы для критически важных бизнес-приложений. Разработка многоуровневых J2EE приложений предоставляет столь необходимую масштабируемость, отказоустойчивость и разделение между пользовательским интерфейсом и бизнес-логикой приложения. Однако эта прикладная среда также добавляет сложностей и новых проблем тем, кто занимается максимизацией доступности и производительности. И группы разработчиков ПО находятся на разных стадиях интегрирования технологии J2EE.
Например, компании, специализирующиеся на системах управлении отношениями с клиентами (CRM), добавляют в свой софт интерфейсы на базе HTML. Зачастую это означает добавление сервера приложений J2EE в качестве хоста для сервлетов (Server side Java) и JSP (серверных страниц Java). И когда архитектор продукта решает, что приложению требуется большая степень управляемости, он уже может спроектировать его так, чтобы воспользоваться преимуществами сервера приложений J2EE, в частности сохранением данных и фреймворком транзакций. Сервер управляет ресурсами, которые использует приложение J2EE, включая память, связь с базами данных, пулы потоков и кэширование. После развертывания J2EE приложение состоит из нескольких слоев. Клиенты используют веб-браузеры для доступа к веб-серверу. Веб-сервер может обработать запрос независимо, а может передать его дальше на сервер приложений. Если необходимые данные занесены в локальный кэш, сервер приложений выдает ответ через веб-сервер клиенту. В противном случае, сервер приложений запрашивает удаленные базы данных и различные системы, чтобы собрать ответ на запрос пользователя.
Сбор данных
Для любого решения по мониторингу фундаментальными являются данные. Если системе недостаточно качественной информации, то предупреждений и оповещений просто не будет. Мониторам производительности для приложений J2EE необходимо агрегировать данные из разных ресурсов. Первым источником данных является сам сервер приложений. Кроме того, что он предоставляет платформу для приложений, сервер ещё и обеспечивает фреймворк управления. Недавние версии серверов приложений от всех основных производителей, включая BEA, IBM, Oracle и Sun, имеют стандартный фреймворк под названием Java Management Extensions (JMX).
JMX состоит из 3х уровней. На первом уровне находятся управляемые классы (MBean-ы). Они открывают конфигурационные данные и методы настроек для изменения параметров конфигурации. MBean-ы также предоставляют информацию о текущем использовании ресурсов. Например, при помощи MBean можно узнать максимальный размер кэша EJB (Enterprise Java Beans), текущий размер кэша, а также возможности по изменению максимального размера.
MBean-ы управляются MBean-сервером, который находится на 2м уровне фреймворка JMX. MBean сервер содержит реестр MBean-ов и предоставляет сервисы по управлению ими. В предыдущем примере удаленные приложения оперируют через MBean-сервер для проверки или управления размером кэша EJB.
Последний уровень состоит из JMX-адаптеров, которые помогают внешним приложениям получить доступ к MBean-ам. Этот уровень указан как часть стандарта JMX, но его реализация необязательна. Поэтому разработчики серверов приложений и программного обеспечения пишут адаптеры под свои особые нужды. Например, веб-консоль, используемая для контроля размера кэша EJB, будет использовать HTTP-адаптер для доступа к MBean-серверу.
С помощью JMX разработчики серверов приложений обеспечивают доступ к текущему использованию ресурсов и конфигурированию контейнеров EJB и сервлетов. Хоть это и стандартный фреймворк, разработчики серверов приложений вольны выбирать, какие атрибуты своих продуктов раскрывать. Ресурсы, обычно контролируемые через JMX, включают в себя использование EJB, транзакции, пулы потоков и сервлетов, пороговые значения JMS и объемы кэша.
Помимо различий между серверами приложений, существует значительный объем информации, имеющей отношение к приложению, которую не получить через JMX. Процесс, известный как инструментация, нужен для получения информации не предоставленной производителями, включая подробности об индивидуальных методах, которые составляют приложение. Есть два типа инструментации, используемых для получения данных на уровне методов. Первый закладывается архитектором приложения и используется программистом во время разработки приложения. После компиляции приложение открывает информацию о производительности согласно спецификациям архитектора.
Программные инструменты мониторинга обычно не имеют доступа к исходному коду приложения на стадии разработки. Решение по мониторингу, как правило, выбирается, когда приложение переходит на стадию нагрузочного тестирования перед развёртыванием. Добавление инструментария в исходный код на данном этапе внесет определённые риски в проект и может стать причиной значительной задержки по выпуску, пока вносятся изменения и проводится их тестирование. Вместо изменения исходного кода, инструменты мониторинга обычно применяют вторую форму инструментации – в байт-код скомпилированного приложения. При добавлении небольшого количества байт-кода к уже скомпилированным методам, система мониторинга получает доступ к необходимой информации о производительности.
Хотя JMX может использоваться для определения многих атрибутов EJB, этот фреймворк не может полностью отразить все, что происходит внутри EJB. Инструментация байт-кода применяется внутри класса, что позволяет обеспечить доступ на более глубокий уровень исполняемых данных, чем при использовании только JMX. После инструментации становятся доступными данные классов и методов, включая распределение времени отклика, счетчики использования и вызванные исключения.
По отдельности, JMX и инструментация байт-кода обеспечивают ценную информацию о сервере приложений J2EE и размещенных на нём приложениях. Используя данные из обоих источников, средства мониторинга могут давать точное представление о доступности и производительности J2EE приложений и оповещать администраторов о потенциальных проблемах.
