готовности Java-систем 1. Мониторинг ...Мониторинг...

© Copyright IBM Corporation 2009 Торговые маркиМониторинг работы Java-приложений: Часть 1. Мониторингпроизводительности и степени готовности Java-систем

Страница 1 из 35

Мониторинг работы Java-приложений: Часть1. Мониторинг производительности и степениготовности Java-системПодходы и принципы

Николас Уайтхедстарший технический архитекторADP

02.03.2009

Мониторинг производительности приложений во время их выполнения играет критическиважную роль при создании и сопровождении качественной программной системы. Впервой части серии из трех статей Николас Уайтхед расскажет о том, как эффективновыполнять низкоуровневый, детальный мониторинг производительности Java™-кода.Полученные данные могут содержать полезную информацию о работе системы, атакже пролить свет на узкие места и факторы, оказывающие влияние на стабильность ибыстродействие среды в целом.

Больше статей из этой серии

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

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

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ru/ibm/trademarks/

http://www.ibm.com/developerworks/ru/views/java/libraryview.jsp?search_by=Java+??????????

developerWorks® ibm.com/developerWorks/ru/

Мониторинг работы Java-приложений: Часть 1. Мониторингпроизводительности и степени готовности Java-систем


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

В первой части:

• рассказывается о свойствах систем для управления производительностью приложений(Application Performance Management Systems – APM);

• описываются распространенные, но нежелательные подходы к мониторингуприложений;

• описываются методы мониторинга производительности виртуальных Java-машин (JVM);• Предлагаются варианты эффективного инструментирования исходного кода

приложения

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

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

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

Распространенные недостатки мониторингаРедкое приложение не обладает вообще никакими средствами мониторинга. Однако напрактике часто встречаются следующие недостатки:

http://www.ibm.com/developerworks/library/j-rtm2/index.html


ibm.com/developerWorks/ru/ developerWorks®



Проблемы фрагментированного мониторинга

Мониторинг, осуществляющийся в условиях, когда ни одно представление системыне является полным, называется фрагментированным (siloed). Самые запутанныеи плохо поддающиеся диагностике проблемы, как правило, возникают в ситуациях,включающих несколько взаимосвязанных компонентов. В качестве простойиллюстрации представьте себе систему, развернутую на сервере Java-приложений,в состав которого (без ведома владельцев сервера) входит проблемный класс,реализующий пул JDBC-соединений, который не освобождает все открытыесоединения.

Анализируя данные своей системы мониторинга, владельцы приложения видят, чтосо стороны их сервера открыто 100 соединений с базой данных. В свою очередь,администратор базы данных (DBA) через консоль администрирования видит, что состороны данного компьютера открыто 120 соединений, причем их число стремительновозрастает. Для консолидированной APM-системы не должно составлять трудностейпостроить график, совмещающий обе эти картины. В момент, когда данные о числесоединений начинают расходиться, любой человек при взгляде на график должен, во-первых, немедленно понять, какое значение показателя является верным, а во-вторых,получить достаточно точное представление о причине проблемы.

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

• Черные ящики: само приложение либо один из внешних компонентов не позволяютосуществлять мониторинг своих внутренних процессов. Примером подобногочерного ящика может служить JVM. Например, специалисты, исследующие причинынеобъяснимой латентности внутри JVM, которая предоставляет только статистикуоперационной системы (загрузку процессора или объем памяти, занимаемойпроцессом), могут иметь трудности при выявлении проблем, связанных со сборкоймусора или синхронизацией потоков.

• Несовместимые или несвязные системы мониторинга: приложение можетвыполняться внутри крупного вычислительного центра, обращаясь к большомуколичеству общих ресурсов, таких как базы данных, высокоскоростные сети храненияданных (storage-area networks – SAN), а также системы передачи сообщений иразличное промежуточное программное обеспечение. Кроме того, компании частообладают сложной структурой, в которой каждая группа использует собственныесистемы мониторинга и APM (см. заметку «Проблемы фрагментированногомониторинга»). Если не обеспечить консолидированное представление каждого извнешних компонентов, то каждая группа будет иметь доступ только к небольшомуфрагменту общей картины работы приложения.Сравнение консолидированных и фрагментированных ARM-систем представлено нарисунке 1.




Рисунок 1. Сравнение фрагментированной и консолидированной APM-систем

• Построение отчетов и корреляций пост-фактум: в попытке решить проблемы,связанные с фрагментированным мониторингом, группа поддержки может периодическизапускать процессы сбора данных от различных источников, консолидироватьих, а затем строить сводные отчеты. Этот подход часто бывает неэффективен инепрактичен в условиях высокой частоты обновления данных, а отсутствие доступак консолидированным данным в режиме реального времени снижает быстротудиагностирования проблем. Кроме того, данные, полученные в результате пост-фактумагрегирования, могут быть недостаточно детальными, из-за чего могут возникатьтрудности с выявлением важных зависимостей. Например, из отчета может следовать,что время обращения к некоторому сервису за прошедший день в среднем составляло200 миллисекунд, но при этом ничто не будет говорить о том, что между 13:00 и 13:45часами время вызова превышало 3500 миллисекунд.

• Периодический мониторинг или мониторинг по требованию: существуют средствамониторинга, работа которых требует повышенных затрат ресурсов, поэтому они немогут (или не должны) выполняться постоянно. Таким образом, сбор данных происходитредко, либо только в случае обнаружения проблем. В результате ARM-системавыполняет лишь минимальный базовый мониторинг и оказывается не в состоянииоповестить вас о проблеме, пока та не приведет к отказу системы, а также может самаухудшить состояние системы.




• Не сохранение данных мониторинга: многие средства мониторинга строят полезнуюкартину производительности и степени готовности приложения, однако они либоне настроены, либо просто не поддерживают возможности сохранения данныхдля анализа за короткие и длительные промежутки времени. Зачастую данныео производительности, представленные вне временного контекста, оказываютсямалополезными (а то и вовсе бесполезными), так как непонятно, на основании чегоможно судить о том, являются показатели хорошими, плохими или критически плохими.Например, допустим, что уровень загрузки процессора составляет 45%. Если не знать,какое число характерно для периодов высокой или низкой нагрузки на систему впрошлом, то данный показатель будет значительно менее информативен, чем приналичии данных о том, что типичное значение уровня загрузки – x%, а предельное, прикотором обеспечивается допустимая производительность обслуживания клиентов – y%.

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

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

Атрибуты идеальной APM-системы

Отрицательным принципам, перечисленным выше, можно противопоставить наборследующих свойств, которыми обладает идеальная ARM-система, описываемая в даннойстатье:

• Тотальность: система осуществляет мониторинг всех внешних и внутреннихкомпонентов приложения.

• Детальность: система способна производить мониторинг крайне низкоуровневыхфункций.

• Консолидированность: все собранные показатели проходят через единую ARM-систему, строящую консолидированное представление.

• Постоянство: система осуществляет непрерывный мониторинг в режиме 24х7.• Эффективность: сбор данных о производительности приложения не оказывает

пагубного влияния на его быстродействие.• Работа в режиме реального времени: на основе собранных показателей могут быть

построены графики, отчеты, а также выданы предупреждения в режиме реальноговремени.




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

Перед тем как углубиться в детали реализации, стоит обратиться к некоторым общимаспектам APM-систем.

Базовые понятия APM-систем

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

Источник данных о производительности

Источник данных о производительности (Performance Data Source - PDS) предоставляетинформацию о быстродействии или уровне готовности компонента приложения,позволяющую делать выводы о его работоспособности. Например, сервисы JMX(Java Management Extensions), как правило, предоставляют обширный набор данныхо работоспособности JVM. Подобная информация о большинстве реляционных базданных доступна через SQL-интерфейс. Оба этих источника данных являются примераминепосредственных PDS, т.е., другими словами, данные передаются непосредственночерез них. Другой разновидностью PDS являются косвенные источники, данные которыхвычисляются на основе выполнения намеренного или случайного действия. Например,производительность сервера службы сообщений Java (JMS) может измеряться на основевремени отправки и получения периодически генерируемых тестовых сообщений.

Косвенные источники (их экземпляры еще называют синтетическими транзакциями)бывают очень полезны, так как они могут измерять производительность несколькихкомпонентов или вызовов, проходящих через различные слои системы, точно моделируядействия, которые будут происходить при эксплуатации. Кроме того, синтетическиетранзакции незаменимы для мониторинга работоспособности системы в периодыотносительно малой нагрузки, когда данных, поступающих от непосредственных источников,оказывается недостаточно.

Сбор данных и объекты-коллекторы

Сбор данных – это процесс получения информации о производительности или степениготовности приложения от PDS. При работе с непосредственным PDS объект-коллектор(далее просто коллектор), как правило, реализует програмнные интерфейсы, необходимыедля доступа к данным. Например, для получения статистической информации с сетевогопринтера коллектор должен использовать протоколы Telnet или SNMP (простой протоколуправления сетью). В случае работы с косвенным PDS коллектор выполняет необходимыедействия и производит измерения для получения необходимых данных.




Трассировка и трассировщики

Трассировка – это процесс передачи измерений от коллектора в ядро APM-системы. Многиекоммерческие и открытые APM-системы предоставляют программные интерфейсы для этойцели. В качестве примеров к данной статье я реализовал интерфейс Java-трассировщикаобщего назначения, который мы более подробно рассмотрим в следующем разделе.

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

Рисунок 2. Место сбора и трассировки данных в общей архитектуре APM-системы

На рисунке 2 также показана часть сервисов, которые, как правило, предоставляются APM-системами:

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

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

• Хранение истории данных: поддержка хранилища данных, в котором содержитсяпервичная или суммарная информация. Благодаря этому средства визуализации ипостроения отчетов могут выдавать результаты за конкретный временной интервал.

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




позволяющие специалистам службы поддержки передавать события в системы для ихобработки.

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

Интерфейс для трассировки ITracerЯзык Java хорошо подходит для реализации коллекторов по следующим причинам:

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

• Отличная производительность в большинстве ситуаций (хотя она и зависит отрасполагаемых ресурсов).

• Поддержка параллельного выполнения и асинхронных вызовов.• Поддержка большого набора коммуникационных протоколов.• Большое число сторонних API, таких как реализации JDBC, SNMP и проприетарных

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

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

При этом необходимо помнить, что ваши Java-коллекторы должны быть совместимы спрограммными интерфейсами трассировки, которые предоставляются вашей APM-системой.Некоторые из перечисленных выше факторов продолжают играть важную роль, даже есливаш механизм трассировки не предоставляет Java-интерфейсов. Однако в случае, еслицелевые источники данных выполнены в виде Java-сервисов (таких как, например, JMX), ацелевое приложение написано не на Java, понадобятся промежуточные интерфейсы, такиекак IKVM, который представляет собой компилятор Java-кода для платформы .NET (см.Ресурсы).

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




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

На рисунке 3 представлена UML-диаграмма классов, относящихся к интерфейсуorg.runtimemonitoring.tracing.ITracer.

Рисунок 3. ИнтерфейсITracer и класс-фабрика

Имена и категории при трассировкеОсновной задачей ITracer является передача результатов измерений и ассоциированногос ними имени в центральную APM-систему. Это реализуется при помощи методов trace,каждый из которых соответствует своему типу измерений. Все методы принимают на входпараметр String[] name, в котором хранятся контекстные компоненты составного имениизмерения. Структура данного имени определяется используемой APM-системой. В немуказывается как пространство имен, так и название самой метрики, значение которойпередается APM-системе. Таким образом, структура составного имени, как правило,включает как минимум два компонента: корневую категорию и описание измерения. Класс,реализующий интерфейс ITracer, должен уметь преобразовывать переданный строковыймассив в составное имя. Примеры двух соглашений о структуре составных имен приведеныв таблице 1.

Таблица 1. Примеры составных именСтруктура имени Пример составного имени

Простая со слэш-разделителями Hosts/SalesDatabaseServer/CPU Utilization/CPU3

JMX MBean ObjectName com.myco.datacenter.apm:type=Hosts,service=SalesDatabaseServer,group=CPUUtilization,instance=CPU3




Укороченный пример использования методов трассировки через данный интерфейсприведен в листинге 1.

Листинг 1. Пример вызова методов трассировкиITracer simpleTracer = TracerFactory.getInstance(sprops);ITracer jmxTracer = TracerFactory.getInstance(jprops);..simpleTracer.trace(37, "Hosts", "SalesDatabaseServer", "CPU Utilization", "CPU3", "Current Utilization %");jmxTracer.trace(37, "com.myco.datacenter.apm", "type=Hosts", "service=SalesDatabaseServer", "group=CPU Utilization", "instance=CPU3", "Current Utilization %"););

Типы трассируемых данныхДанный интерфейс поддерживает трассировку результатов измерений, описываемыхследующими типами данных:

• int• long• java.util.Date• String

Сама APM-система может поддерживать другой набор типов данных для собираемойинформации.

Режимы трассировкиЗначения, относящиеся к одному типу (например, long), могут интерпретироваться взависимости от того, какие типы данных поддерживаются APM-системой. Имейте в виду,что каждая система APM может по-своему именовать одни и те же режимы трассировки. ВITracer используется универсальная схема именования.

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

Для решения этой проблемы необходимо выбирать интервалы, длительность которыхсоответствует предельно низкой, но допустимой детальности мониторинга. Например,один час – это слишком долго, 200 миллисекунд – слишком мало, а 30 секунд можетбыть в самый раз. При этом можно по-прежнему считать, что трассировка происходитпри каждом вызове воображаемой операции, однако в конце каждого интервала будутполучены следующие данные:




• Средняя длительность операции за интервал• Максимальная длительность операции за интервал• Минимальная длительность операции за интервал• Число выполнений за интервал• Точные временные границы интервала

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

В ITracer поддерживаются следующие режимы трассировки:

• Усредненная в интервале: методы trace(long value, String[] name) и trace(intvalue, String[] name) служат для трассировки усредненных значений в заданноминтервале (см. заметку "Интервалы"). Это означает, что каждое измерение учитываетсяпри подсчете среднего значения для текущего интервала. При начале нового интервалатекущее среднее значение сбрасывается в ноль.

• Закрепленная (sticky): методы traceSticky(value long, String[] name) иtraceSticky(value int, String[] name) служат для трассировки закрепленныхзначений. В отличие от усредненных метрик, при данной трассировке значения могутсохраняться в течение нескольких интервалов. Например, если вызвать метод длятрассировки значения 5 и не вызывать его затем в течение суток, то значение метрикиостанется равным 5, пока не будут переданы новые данные.

• Дельта-трассировка: методы дельта-трассировки получают на вход число, однакорезультатом, передаваемым в APM-систему, является разница (дельта) между текущими предыдущим результатами измерения. Данный тип также называют скоростнойтрассировкой, что отражает область ее применения. Например, допустим, чтоподсчитывается общее число подтвержденных транзакций. Данный показательмонотонно возрастает и, скорее всего, его абсолютное значение не будет представлятьинтереса. Гораздо полезнее знать скорость, с которой он возрастает. Для этогопоказания об абсолютном числе транзакций снимаются с фиксированной частотой,при этом значения дельты соседних измерений характеризуют скорость возрастания.Дельта-трассировка делится на два подтипа: усредненная в интервале и закрепленная,хотя первая из них используется достаточно редко. При использовании дельта-трассировки важно различать показатели, которые могут только монотонно возрастать,от тех, которые могут убывать. Значения, которые оказываются меньше предыдущих,должны либо игнорироваться, либо приводить к сбросу дельты.

• Инцидентная трассировка: данный режим представляет собой простую,неагрегируемую метрику, которая подсчитывает, сколько раз то или иное событиепроизошло за указанный интервал времени. Метод traceIncident(String[] name) непринимает на вход значение, поскольку и коллектор, и трассировщик могут не знатьобщее число возникновений в конкретный момент времени. Поэтому каждый вызовсчитается сигналом о единичном возникновении события. Кроме того, есть методtraceIncident(int value, String[] name), который увеличивает значение счетчика назначение параметра value. Таким образом, не приходится вызывать первый метод вцикле в случае, если надо зарегистрировать несколько событий.

• Умная трассировка - это параметризованный вариант трассировки, позволяющийиспользовать трассировку в одном из перечисленных выше режимов в зависимости




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

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

Принципы работы коллекторов

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

• Опрашивание: коллектор вызывается через регулярные промежутки времени иопрашивает текущие значения метрики (или набора метрик), соответствующей данномуPDS. Например, коллектор может вызываться ежеминутно для чтения показателейзагрузки процессора или общего числа подтвержденных транзакций через JMX-интерфейс. Целью этой схемы является периодический подсчет значений целевойметрики. Таким образом, после вызова коллектора значение метрики передается вAPM-систему, и оно считается неизменным до следующего опроса. Вследствие этогоколлекторы, работающие по данной схеме, как правило, используют закрепленныевиды трассировки. В результате в отчетах APM-системы данное значение будетпоказано как неизменное между вызовами коллектора. Этот принцип иллюстрируетсяна рисунке 4.

Рисунок 4. Схема работы опрашивающего коллектора

• Прослушивание: эта схема работы соответствует паттерну «наблюдатель».Коллектор регистрируется в PDS в качестве слушателя событий. При наступлениисобытия выполняется метод коллектора, представляющий собой функцию обратноговызова. Результат работы данного метода будет передан трассировщику. Методыобратного вызова могут возвращать различные результаты, но в любом случае можноосуществлять инцидентную трассировку, подсчитывающую число наступлений события.Данная схема работы показана на рисунке 5.




Рисунок 5. Схема работы коллектора-слушателя

• Перехват: при данной схеме работы коллектор внедряется в виде перехватчикаобращений вызывающей стороны к целевому объекту. Таким образом, каждыйвызов перехватывается коллектором, который производит измерения и передаетих трассировщику. В случае, если взаимодействие производится по схеме запрос/ответ, коллектор может измерять число запросов, время ответа, а также отслеживатьинформационное наполнение запросов или ответов. Примером такого коллектораможет служить прокси-сервер HTTP, способный выполнять следующие измерения:

• число запросов. При необходимости подсчет может вестись раздельно по типам(GET, POST и т.д.) или по универсальным идентификаторам ресурсов (URI);

• время ответов на запросы;• размер запросов и ответов.

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

Рисунок 6. Схема работы коллектора-перехватчика




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

Мониторинг JVM

JVM сама по себе является подходящей системой для мониторинга. Мы начнем споказателей производительности, характерных для всех JVM, а затем перейдем квнутренним компонентам JVM, которые, как правило, используются в корпоративныхприложениях. За небольшим исключением, экземпляры Java-приложений представляютсобой процессы, выполняющиеся внутри операционной системы (ОС), поэтому некоторыеаспекты мониторинга JVM удобнее всего рассматривать именно в разрезе используемой ОС(эти вопросы будут освещены в третьей статье серии).

До выхода пятой версии стандартной редакции платформы Java (Java SE 5) стандартныесредства JVM внутренней диагностики, способные эффективно и безотказно собиратьданные, были достаточно ограничены. В настоящее время ряд возможностей мониторингапредоставляется через стандартный интерфейс java.lang.management, поддерживаемыйвсеми JVM, реализующими Java SE версии 5 и выше. Некоторые реализации JVMпредоставляют дополнительные проприетарные метрики, но доступ к ним осуществляетсяаналогично стандартным интерфейсам. Ниже будут рассматриваться стандартныепоказатели производительности, доступные через объекты MXBeans – JMX-объектыMBeans (см. Ресурсы), размещенные внутри виртуальной машины и выставляющие наружуинтерфейсы для управления и мониторинга. Основными из них являются следующие:

• ClassLoadingMXBean: мониторинг системы загрузки классов.• CompilationMXBean: мониторинг системы компиляции.• GarbageCollectionMXBean: мониторинг работы сборщиков мусора JVM.• MemoryMXBean: мониторинг кучи и остальной памяти JVM.• MemoryPoolMXBean: мониторинг пулов памяти, выделенных JVM.• RuntimeMXBean: мониторинг системы времени выполнения. Данный объект

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

• ThreadMXBean: мониторинг системы управления потоками.

JMX-коллектор работает следующим образом: сначала он получает ссылку на объектMBeanServerConnection, который способен считывать значения атрибутов объектов MBeans,развернутых внутри JVM. Получив значения атрибутов, коллектор трассирует их при помощиреализации интерфейса ITracer. Главным моментом при использовании данного коллектораявляется вопрос о его размещении. Существуют два варианта: локальное развертывание иудаленное развертывание.





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

При локальном развертывании как сам коллектор, так и планировщик, отвечающий завызов коллектора, размещаются внутри целевой JVM. JMX-коллектор обращается кобъектам MXBean через экземпляр PlatformMBeanServer, который представляет собойстатический объект MBeanServerConnection внутри JVM. При удаленном развертыванииколлектор запускается в отдельном процессе и соединяется с целевой JVM средствамиJMX Remoting или его разновидности. Этот подход может быть менее эффективен, чемлокальное развертывание, однако он не требует размещения дополнительных компонентоввнутри JVM. Для соединения с JVM при помощи JMX Remoting достаточно развернуть в нейкомпонент RMIConnectorServer или включить поддержку внешних соединений (см. Ресурсы).Более подробное обсуждение средств JMX Remoting выходит за рамки этой статьи.

Пример JMX-коллектораJMX-коллектор, использующийся в качестве примера в данной статье (полностью исходныйкод приведен в разделе Загрузка), содержит три различных метода для получения ссылки наэкземпляр MBeanServerConnection. Коллектор обладает следующими функциями:

• Получение экземпляра MBeanServerConnection для соединения с объектом MBeanServer,являющимся локальным для данной JVM. Соединение осуществляется при помощиметода java.lang.management.ManagementFactory.getPlatformMBeanServer().

• Получение экземпляра MBeanServerConnection для соединения свторичным объектом MBeanServer, также являющимся локальнымдля данной JVM. Соединение осуществляется при помощи методаjavax.management.MBeanServerFactory.findMBeanServer(String agentId). Заметим, чтов одной JVM могут быть размещены несколько объектов MBeanServer. Более сложныесистемы, например, серверы Java EE (Enterprise Edition), в дополнение к основномуобъекту MBeanServer, как правило, содержат дополнительный экземпляр, относящийся кконкретному приложению (см. заметку "Кросс-регистрация объектов MBean").

• Получение ссылки на удаленный объект MBeanServerConnection припомощи стандартного интерфейса RMI (для адресации служит классjavax.management.remote.JMXServiceURL).

Сокращенный вариант метода collect() класса JMXCollector приведен в листинге 2. Методслужит для сбора и трассировки данных об управлении потоками и использует объектThreadMXBean. Полная версия метода приведена здесь.

Листинг 2. Фрагмент метода collect() JMX-коллектора, в которомиспользуется объект ThreadMXBean..objectNameCache.put(THREAD_MXBEAN_NAME, new ObjectName(THREAD_MXBEAN_NAME));.

http://www.ibm.com/developerworks/java/library/j-rtm1/sidefile.html




.public void collect() { CompositeData compositeData = null; String type = null; try { log("Starting JMX Collection"); long start = System.currentTimeMillis(); ObjectName on = null;.. // Мониторинг потоков on = objectNameCache.get(THREAD_MXBEAN_NAME); tracer.traceDeltaSticky((Long)jmxServer.getAttribute(on,"TotalStartedThreadCount"), hostName, "JMX", on.getKeyProperty("type"), "StartedThreadRate"); tracer.traceSticky((Integer)jmxServer.getAttribute(on, "ThreadCount"), hostName, "JMX", on.getKeyProperty("type"), "CurrentThreadCount");.. // Выполнено long elapsed = System.currentTimeMillis()-start; tracer.trace(elapsed, hostName, "JMX", "JMX Collector", "Collection", "Last Elapsed Time"); tracer.trace(new Date(), hostName, "JMX", "JMX Collector", "Collection", "Last Collection"); log("Completed JMX Collection in ", elapsed, " ms."); } catch (Exception e) { log("Failed:" + e); tracer.traceIncident(hostName, "JMX", "JMX Collector", "Collection", "Collection Errors"); }}

В листинге 2 выполняется трассировка показателей TotalThreadsStarted (число запущенныхпотоков) и CurrentThreadCount (текущее число потоков). Поскольку данный коллекторработает по схеме опрашивания, используется закрепленный режим трассировки. Однакопоказатель TotalThreadsStarted монотонно увеличивается, так что основной интереспредставляет не абсолютное значение, а скорость, с которой создаются новые потоки.Поэтому при трассировке используется вариант DeltaSticky (закрепленная дельта-трассировка).

Дерево метрик, построенное APM-системой по данным, собранным этим коллектором,показано на рисунке 7.




Рисунок 7. Отображение дерева показателей в интерфейсе APM-системы

Некоторые аспекты работы JMX-коллектора не показаны в листинге 2 (тем не менееони представлены в полной версии исходного кода). К ним относится регистрацияпланировщика, который каждые 10 секунд вызывает метод collect() коллектора.

В листинге 2 режим трассировки и типы трассируемых данных зависят от источника данных.Примеры приведены ниже.

• Показатели TotalLoadedClasses (общее число загруженных классов) иUnloadedClassCount (число выгруженных классов) трассируются в режимефиксированной дельта-трассировки, так как они монотонно возрастают, и дельтыоказываются полезнее для мониторинга загрузки/выгрузки классов, чем абсолютныезначения.

• Показатель ThreadCount (число потоков) может как возрастать, так и уменьшаться,поэтому он трассируется в режиме закрепленной трассировки.

• Показатель Collection Errors трассируется в режиме инцидентной интервальнойтрассировки. Он увеличивается каждый раз при возникновении исключения во времясборки мусора.

Имена целевых JMX-объектов MXBean (экземпляры ObjectName) не меняются в течениевсего времени работы JVM, поэтому коллектор кэширует их в целях повышенияэффективности, используя константы, определенные в классе ManagementFactory.

Точные имена двух объектов MXBean, а именно GarbageCollector и MemoryPool, в общемслучае не могут быть известны заранее, но их можно определить по образцу. Для этогово время первого запуска коллектора выполняется запрос к MBeanServerConnection наполучение всех объектов MBean, имена которых соответствуют образцу. Далее полученныетаким образом объекты MBean сохраняются в кэше, что помогает избежать повторныхзапросов.

Атрибуты объектов MBean, опрашиваемые коллектором, не всегда бывают простыхчисленных типов. Например, целевые атрибуты объектов MemoryMXBean и MemoryPoolMXBean




имеют тип CompositeData, содержащий набор пар "ключ-значение". Объекты MXBean,доступные через интерфейс JVM java.lang.management, следуют модели открытых типовJMX, которая говорит о том, что атрибуты не должны иметь типы данных, специфичные дляконкретного языка (т.е. в Java должны использоваться такие типы, как java.lang.Boolean илиjava.lang.Integer). Составные типы, подобные javax.management.openmbean.CompositeType,должны декомпозироваться на пары «ключ-значение», состоящи из данных простыхтипов. Полный перечень допустимых простых типов содержится в статическом полеjavax.management.openmbean.OpenType.ALLOWED_CLASSNAMES. Таким образом, модельподдерживает определенный уровень типового абстрагирования, благодаря которому JMX-клиенты не зависят от нестандартных классов, а также могут быть разработаны не на Java,поскольку открытые типы сравнительно просты. Более подробная информация о моделиоткрытых типов JMX (JMX Open Types) приведена в разделе Ресурсы.

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

Если коллектор открывает одно соединение и использует его при сборе всей необходимойинформации, то следует предусмотреть возможность его обрыва. Другими словами,необходимы средства обнаружения обрыва соединения и его восстановления. НекоторыеAPI для сбора данных предоставляют объекты-слушатели, которые могут уведомлятьколлектор о необходимости прервать работу, освободить ресурсы, а затем открыть новоесоединение. Также возможны ситуации, в которых коллектор пытается соединиться систочником данных, который недоступен (например, проводятся технические работы и т.д.).В таких случаях коллектор должен периодически опрашивать состояние источника. Крометого, имеет смысл оценивать время установки соединения и сокращать интенсивность сбораданных при падении скорости отклика. Таким образом можно снизить нагрузку на целевуюJVM, которая могла подвергаться чрезмерно активному мониторингу.

В данных примерах не реализованы два дополнительных способа повышенияпроизводительности JMX-коллектора и снижения нагрузки с его стороны на целевую JVM.Первый способ применим в ситуации, когда коллектор обращается к нескольким атрибутамодного объекта MBean. Вместо того, чтобы обращаться к ним поочередно, вызываякаждый раз метод getAttribute(ObjectName name, String attribute), можно получитьзначения сразу нескольких атрибутов при помощи метода getAttributes(ObjectName name,String[]. Разница может быть незаметна при локальном развертывании коллектора, но приудаленной работе расход ресурсов будет значительно снижен за счет сокращения числасетевых обращений. Второй способ заключается в снижении нагрузки на пулы памяти,доступные через JMX, за счет замены схемы опрашивания на схему прослушивания.Объект MemoryPoolMXBean позволяет задать пороговое значение степени использованияпула, после превышения которого он автоматически уведомит коллектор, который, в своюочередь, сможет передать значение трассировщику. Пороговое значение можно постепенноувеличивать по мере возрастания активности использования пула. У этого подхода естьодин недостаток: детализация картины использования памяти может пострадать, если




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

Наконец, в примере не показано, как можно измерять интервалы, а также полное времяработы сборщика мусора. На основе этих двух показателей при помощи несложныхарифметических подсчетов можно вывести продолжительность активности сборщикав процентном выражении. Это достаточно полезный показатель, так как сборка мусоранеизбежна (по крайней мере, на текущий момент) для большинства приложений. Посколькучисло и длительность работы коллектора известны, процент времени, в течение которогосборщик мусора был активен, может пролить свет на наличие или отсутствие проблемпри работе JVM. Несмотря на то, что точный процент зависит от приложения, общееправило гласит, что периоды активности сборщика мусора не должны превышать 10% за 15-минутный интервал работы системы.

Внешнее конфигурирование коллекторовВ целях наглядности описания процесса сбора данных JMX-коллектор, показанный влистинге 2, был значительно упрощен. При реальном мониторинге жесткое описаниепроцессора сбора информации непосредственно в коде коллектора является фактором,серьезно ограничивающим его возможности. В идеале коллектор должен реализовыватьлогику обращения к данным, в то время как указания того, какую именно информациюсобирать, должны поступать извне, в виде настроек. Подобный дизайн значительноповышает гибкость и удобство использования коллектора. Максимальная гибкостьдостигается в случае, если коллектор позволяет задавать следующие параметры извне:

• директиву для получения ссылки на фабрику соединений с PDS. Коллектору долженбыть предоставлен интерфейс и набор параметров для соединения с PDS;

• частоту сбора данных;• частоту, с которой будут предприниматься попытки восстановления соединения;• целевой объект MBean для сбора данных, либо шаблон для подстановки имени

объекта;• составное имя трассировки для каждого показател, либо указания о том, куда должны

трассироваться данные. Кроме того, необходимо задавать тип трассируемых данных.

Пример фрагмента, содержащего настройки JMX-коллектора, приведен в листинге 3.

Листинг 3. Фрагмент внешнего файла, содержащего конфигурационнуюинформацию для JMX-коллектора<?xml version="1.0" encoding="UTF-8"?><JMXCollector> <attribute name="ConnectionFactoryClassName"> collectors.jmx.RemoteRMIMBeanServerConnectionFactory </attribute> <attribute name="ConnectionFactoryProperties"> jmx.rmi.url=service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector </attribute> <attribute name="NamePrefix">AppServer3.myco.org,JMX</attribute> <attribute name="PollFrequency">10000</attribute> <attribute name="TargetAttributes">




<TargetAttributes> <TargetAttribute objectName="java.lang:type=Threading" attributeName="ThreadCount" Category="Threading" metricName="ThreadCount" type="SINT"/> <TargetAttribute objectName="java.lang:type=Compilation" attributeName="TotalCompilationTime" Category="Compilation" metricName="TotalCompilationTime" type="SDINT"/> </TargetAttributes> </attribute></JMXCollector>

Обратите внимание, что каждый элемент TargetAttribute содержит атрибут type, в которомзадается значение аргумента, передаваемого умному трассировщику. Значения SINT и SDINTсоответственно означают обычную и дельта-трассировку данных типа int в закрепленномрежиме.

Мониторинг ресурсов приложения через JMXДо этого момента мы рассматривали JMX-мониторинг только стандартных ресурсовJVM. Однако многие платформы, в частности Java EE, позволяют собирать показатели,относящиеся к конкретному приложению, через JMX. Набор показателей зависит откомпании, которой принадлежит реализация платформы. Классическим примером можетслужить такой показатель как степень использования источника данных (DataSource).DataSource представляет собой сервис, поддерживающий пул соединений с внешнимресурсом (как правило, с базой данных) и ограничивающий число параллельных соединенийс целью защиты ресурса от проблемных и перегруженных приложений. Мониторингисточников данных является критически важной частью общего плана мониторинга.Благодаря абстрактному слою JMX данный процесс оказывается аналогичным томумониторингу ресурсов JVM, который мы рассматривали выше.

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

• Число доступных соединений: текущее число соединений в пуле, которые могут бытьпредоставлены приложению.

• Число соединений: число физических соединений с базой данных среди всехсоединений в пуле.

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

• Число используемых соединений: число соединений, которые в настоящее времяиспользуются приложением.

• Число созданных соединений: общее число соединений, которые были созданывнутри данного пула.

• Число ликвидированных соединений: общее число соединений данного пула,которые были уничтожены.

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




неизменными, поэтому необходимо искусственно создать определенную нагрузку наисточник данных. Метод collect(), осуществляющий сбор информации о работе DataSource,приведен в листинге 4.

Листинг 4. Коллектор, собирающий данные об использовании DataSource

public void collect() { try { log("Starting DataSource Collection"); long start = System.currentTimeMillis(); ObjectName on = objectNameCache.get("DS_OBJ_NAME"); AttributeList attributes = jmxServer.getAttributes(on, new String[]{ "AvailableConnectionCount", "MaxConnectionsInUseCount", "InUseConnectionCount", "ConnectionCount", "ConnectionCreatedCount", "ConnectionDestroyedCount" }); for(Attribute attribute: (List<Attribute>)attributes) { if(attribute.getName().equals("ConnectionCreatedCount") || attribute.getName().equals("ConnectionDestroyedCount")) { tracer.traceDeltaSticky((Integer)attribute.getValue(), hostName, "DataSource", on.getKeyProperty("name"), attribute.getName()); } else { if(attribute.getValue() instanceof Long) { tracer.traceSticky((Long)attribute.getValue(), hostName, "DataSource", on.getKeyProperty("name"), attribute.getName()); } else { tracer.traceSticky((Integer)attribute.getValue(), hostName, "DataSource",on.getKeyProperty("name"), attribute.getName()); } } } // Выполнено long elapsed = System.currentTimeMillis()-start; tracer.trace(elapsed, hostName, "DataSource", "DataSource Collector", "Collection", "Last Elapsed Time"); tracer.trace(new Date(), hostName, "DataSource", "DataSource Collector", "Collection", "Last Collection"); log("Completed DataSource Collection in ", elapsed, " ms."); } catch (Exception e) { log("Failed:" + e); tracer.traceIncident(hostName, "DataSource", "DataSource Collector", "Collection", "Collection Errors"); }}

Дерево показателей, построенное по результатам работы коллектора DataSource, показанона рисунке 8.




Рисунок 8. Дерево показателей использования DataSource

Мониторинг компонентов внутри JVMКросс-регистрация объектов MBeanМногие реализации поддерживают регистрацию объектов MBean в различныхобъектах MBeanServer внутри одной JVM. Например, объекты MXBean, относящиесяк java.lang MXBean, зарегистрированы в агенте платформы (или MBeanServerJVM), в то время как объекты, относящиеся к DataSource, в JBoss зарегистрированыв MBeanServer jboss. При удаленном мониторинге подобная ситуация можетпривести к увеличению накладных расходов и усложнить конфигурирование, так какпридется устанавливать соединения с каждым объектом MBeanServer. Кроме того,предоставление самой возможности для соединения с объектами MBeanServer состороны платформы также ведет к снижению производительности. В этих случаях,как правило, не представляет сложностей произвести кросс-регистрацию объектовMBean таким образом, чтобы осуществлять мониторинг всех необходимых объектовчерез единый интерфейс MBeanServer. В архиве с исходным кодом примеров кстатье приводится скрипт (Bean shell) под названием map-platform-mxbeans.bsh. Есливыполнить данный скрипт в сервере JBoss, то все платформенные объекты MXBeanбудут также зарегистрированы в объекте MBeanServerJBoss.

В этом разделе описываются способы мониторинга компонентов приложения, сервисов,классов и методов. Наиболее интересными показателями являются следующие.

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

ошибках.• Продолжительность вызова: среднее, минимальное или максимальное время работы

сервиса или метода за заданный интервал.• Степень параллелизма вызовов: число активных потоков, параллельно вызывающих

сервис или метод.

Благодаря возможностям объекта ThreadMXBean, которые поддерживаются некоторымиреализациями Java SE, начиная с версии 5, можно получать значения следующихпоказателей:

• Системное и пользовательское время работы CPU: процессорное время,затраченное на вызов метода.




• Число ждущих потоков и общее время ожидания: число потоков и общее время,которое потоки провели в режиме ожидания вызова метода или сервиса. Времяожидания отсчитывается с момента выставления флага состояния WAITING илиTIMED_WAITING. Находясь в режиме ожидания, поток ожидает определенного действия состороны параллельно выполняющегося потока.

• Число заблокированных потоков и общее время блокировок: число потокови общее время, за которое потоки были заблокированы (флаг состояния BLOCKED)при вызове метода или сервиса. Поток является заблокированным во времяожидания монитора либо ожидания входа (первоначального или повторного) всинхронизированную секцию кода.

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

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

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

• Перехват: мониторинг может осуществляться точно и эффективно путем внедренияперехватчика всех вызовов целевых классов. При этом удается избежать изменениякак исходного, так и байт-кода классов. Данный подход часто оказывается пригоднымк использованию благодаря тому, что множество платформ Java и Java EE обладаютследующими свойствами:

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

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

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




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

• Оборачивание классов: это процесс создания классов-оберток над целевымиклассами. Обертки реализуют ту же функциональность, что и сами классы, но при этомвключают код для сбора показателей о производительности.

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

Асинхронное инструментированиеАсинхронность играет фундаментальную роль при инструментировании классов. Впредыдущем разделе рассматривалась схема опрашивания для сбора данных. Качественнореализованный сбор данных при помощи опрашивания не должен добавлять накладныхрасходов и оказывать влияние на быстродействие приложения. Инструментирование жевсегда приводит к изменению кода и, как следствие, влияет на его исполнение. Главнымпринципом любого типа инструментирования должно быть "не навреди". Другими словами,необходимо максимально снизить накладные расходы. В то время как минимальныепотери, связанные непосредственно с измерениями, исключить практически невозможно,совершенно необходимо, чтобы последующие действия (трассировка) выполнялисьасинхронно. Существует несколько распространенных вариантов реализации асинхроннойтрассировки. Общая схема приведена на рисунке 9.

Рисунок 9. Схема асинхронной трассировки данных





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

Инструментирование исходного кода Java-классов

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

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

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

• Абстрактные API трассировки аналогичны API журналирования (logging), подобнымlog4j. И те, и другие предоставляют следующие возможности:

• управление детальностью вывода на этапе выполнения приложения:уровни детальности классов log4j, добавляющих записи в журнал, задаютсяперед запуском приложения, но могут быть изменены во время выполнения.Аналогичным образом API трассировки должны предоставлять средства на основеиерархии наименований для управления трассируемыми показателями.

• настройка вывода: журналирование данных в log4j реализуется через объекты-логгеры, которые, в свою очередь, передают данные объектам, осуществляющимнепосредственно вывод (так называемым appender’ам). Последние могут бытьнастроены для записи данных в различные выходные потоки, в частностифайлы, сокеты или сообщения e-mail. Хотя подобное разнообразие типов выводане является обязательным для API трассировки, интерфейсы должны бытьабстрагированы от проприетарных, либо специфичных для конкретной APMкомпонентов. Это позволяет избежать необходимости внесения изменений висходный код при помощи управления настройками.

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




Контекстная трассировка

Контекстная трассировка в высокой степени определяется конкретным приложением.Мы рассмотрим упрощенный пример класса для обработки платежной ведомости иего метод processPayroll(long clientId). Задачей метода является расчет заработнойплаты для каждого сотрудника компании-клиента. Разумеется, существует ряд способовинструментирования данного метода, однако очевидно, что время его вызова будетвозрастать в зависимости от числа сотрудников. Поэтому временные показатели работыметода processPayroll окажутся вырванными из контекста, если не знать, сколькосотрудников было обработано при каждом запуске. Допустим, за выбранный промежутоквремени средняя продолжительность вызовов метода processPayroll составила xмиллисекунд. Основываясь только на этом значении, невозможно утверждать, насколькоэтот показатель плох или хорош, так как число сотрудников неизвестно. Если заработнаяплата рассчитывалась только для одного сотрудника, то показатель, вполне вероятно, плох,а если для 150 – то он может быть просто великолепен. Упрощенный пример реализацииданного метода приведен в листинге 5.

Листинг 5. Пример метода, требующего контекстной трассировки

public void processPayroll(long clientId) { Collection<Employee> employees = null; // Выбрать список сотрудников //... //... // Произвести расчет для каждого сотрудника for(Employee emp: employees) { processEmployee(emp.getEmployeeId(), clientId); }}

Основной проблемой здесь является то, что все вызовы, происходящие внутри методаprocessPayroll(), недоступны для инструментирования. Таким образом, если вам удалосьинструментировать метод processPayroll (и даже processEmployee), то все равно нет никакойвозможности для трассировки числа сотрудников, т.е. показателя, который в этом случаеявляется контекстом для данных о производительности метода. В листинге 6 показангрубый, жестко описанный в коде (а также весьма неэффективный) вариант того, как можнополучить контекстные данные в этой ситуации.




Листинг 6. Пример реализации контекстной трассировки

public void processPayrollContextual(long clientId) { Collection<Employee> employees = null; // Выбрать список сотрудников employees = popEmployees(); // Произвести расчет для каждого сотрудника int empCount = 0; String rangeName = null; long start = System.currentTimeMillis(); for(Employee emp: employees) { processEmployee(emp.getEmployeeId(), clientId); empCount++; } rangeName = tracer.lookupRange("Payroll Processing", empCount); long elapsed = System.currentTimeMillis()-start; tracer.trace(elapsed, "Payroll Processing", rangeName, "Elapsed Time (ms)"); tracer.traceIncident("Payroll Processing", rangeName, "Payrolls Processed"); log("Processed Client with " + empCount + " employees.");}

Главную роль в листинге 6 играет метод tracer.lookupRange. Диапазоны (ranges) – этоколлекции, которым присвоены строковые имена, соответствующие названиям численныхинтервалов. Каждая коллекция ассоциируется со своим интервалом. Таким образом, вместопростой трассировки продолжительности вызова метода в листинге 6 происходит поисксоответствующего интервала, в который попадает текущее число сотрудников. Далеерезультаты группируются по близким значениям числа сотрудников. Дерево показателей,построенное APM-системой по собранным данным, показано на рисунке 10.

Рисунок 10. Продолжительность расчета заработной платы в разрезедиапазонов

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




Рисунок 11. Графики продолжительности расчета с учетом числасотрудников

В конфигурации трассировщика можно задавать URL файла свойств, в котором определеныдиапазоны и пороговые значения (о последних речь пойдет ниже). Данные свойстваобрабатываются при создании трассировщика. Они содержат данные, на которые опираетсяреализация метода tracer.lookupRange. Пример конфигурационного описания диапазоновпод именем Payroll Processing показан в листинге 7. В данном примере используетсяXML-представление объекта java.util.Properties, поскольку оно более терпимо киспользованию нестандартных символов.

Листинг 7. Пример конфигурирования диапазонов<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"><properties> <comment>Payroll Process Range</comment> <entry key="L:Payroll Processing">181+ Emps,10:1-10 Emps,50:11-50 Emps, 80:51-80 Emps,120:81-120 Emps,180:121-180 Emps</entry></properties>

Использование диапазонов, определенных во внешнем файле, исключает необходимостьчастого внесения изменений в исходный код приложения из-за меняющихся требованийлибо соглашений об уровне сервиса (service level agreements – SLA). Для того чтобымодифицировать используемые диапазоны и пороговые значения, достаточно простоотредактировать внешний файл, а не само приложение.

Контроль пороговых значений и соответствие SLAБлагодаря гибкости контекстной трассировки, конфигурируемой извне, можно осуществлятьболее точное и детальное измерение пороговых значений производительности. Диапазоныопределяют численные интервалы, в соответствии с которыми измерения разбиваются накатегории. Пороговые значения позволяют сделать следующий шаг в классифицированиисделанных измерений, заключающийся в их оценке по отношению к диапазону. Одним израспространенных вариантов анализа собранных данных является определение "удачных"и "неудачных" операций, причем "неудачными" считаются те операции, которые не быливыполнены в течение установленного промежутка времени. Накапливание подобнойинформации может быть необходимо для построения общего отчета о рабочем состоянии иресурсах системы, а также для оценки соответствия системы соглашениям SLA.

В рамках той же системы расчета заработной платы рассмотрим внутреннюю системуоценки времени выполнения расчета. Все вызовы метода классифицируются по шкалеOk (нормальное выполнение), Warn (настораживающе медленное выполнение) и Critical(критически медленное выполнение) в соответствии с диапазонами, в которые попадаетчисло обработанных при вызове сотрудников. Процесс подсчета вызовов, выходящихза пределы пороговых значений, концептуально просто. Все что нужно – это указатьтрассировщику предельные значения времени выполнения для каждого диапазона икаждого пункта в шкале оценок. Далее необходимо вызывать метод tracer.traceIncidentдля трассировки классифицированного времени выполнения расчета, а затем (дляупрощения отчета) трассировать общее время. В таблице 2 показаны пороговые значения,установленные соглашениями SLA.

Таблица 2. Пороговые значения быстродействия расчета заработнойплаты

Число сотрудников Ok (мс) Warn (мс) Critical (мс)

1-10 280 400 >400

11-50 850 1200 >1200

51-80 900 1100 >1100

81-120 1100 1500 >1500

121-180 1400 2000 >2000

181+ 2000 3000 >3000

В API ITracer реализуется трассировка на основе пороговых значений, которые определеныв том же XML-файле свойств, что и диапазоны. Пороговые значения отличаютсяот диапазонов в двух аспектах. Во-первых, ключевое значение, использующееся вопределении порогового значения, представляет собой регулярное выражение. Притрассировке численного значения ITracer проверяет соответствие данного выражениясоставному имени метрики. В случае соответствия результат измерения оценивается пошкале "Оk, Warn, Critical", и добавляется дополнительный вызов tracer.traceIncident. Во-вторых, описание порогов заключается в задании всего двух значений (оценку Criticalполучают измерения, превышающие пороговое значение Warn). В листинге 8 показанозадание пороговых значений продолжительности расчета заработной платы, которыеустановлены описанными выше соглашениями SLA.

Листинг 8. Конфигурирование пороговых значений для процесса расчетазаработной платы<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"><properties>  <entry key="Payroll Processing.*81-120 Emps.*Elapsed Time \(ms\)">1100,1500</entry> <entry key="Payroll Processing.*1-10 Emps.*Elapsed Time \(ms\)">280,400</entry> <entry key="Payroll Processing.*11-50 Emps.*Elapsed Time \(ms\)">850,1200</entry> <entry key="Payroll Processing.*51-80 Emps.*Elapsed Time \(ms\)">900,1100</entry> <entry key="Payroll Processing.*121-180 Emps.*Elapsed Time \(ms\)">1400,2000</entry> <entry key="Payroll Processing.*181\+ Emps.*Elapsed Time \(ms\)">2000,3000</entry></properties>




На рисунке 12 показано дерево показателей расчета в разрезе используемых пороговыхзначений.

Рисунок 12. Дерево показателей скорости расчета с учетом пороговыхзначений

Как видно из рисунка 13, собранные данные могут отображаться в виде круговойдиаграммы.

Рисунок 13. SLA-статистика по быстродействию расчета заработнойплаты в диапазоне 1-10 сотрудников

При такой схеме работы важно, чтобы операции поиска диапазона и присвоения оценок порезультатам проверки пороговых значений были реализованы максимально эффективно,так как они выполняются в том же потоке, что и рабочий код. В реализации ITracer именаметрик сохраняются в потокобезопасных ассоциативных массивах (Map) при первойтрассировке соответствующих показателей (при этом используются разные массивы для




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

Заключение к первой статье

В первой части серии были описаны некоторые из распространенных, но неудачныхподходов к мониторингу, а также представлен ряд возможностей, которыми должныобладать качественные APM-системы. Кроме того, были рассмотрены базовые принципысбора информации о производительности и предложен интерфейс ITracer, которыйбудет использоваться и в следующих частях серии. В статье демонстрировались методымониторинга состояния JVM и сбора общих показателей через интерфейс JMX. Наконец,были представлены эффективные варианты инструментирования исходного кода,минимизирующие необходимость внесения изменений в классы приложения. Вы увидели,как при помощи инструментирования можно собирать непосредственную статистику побыстродействию вызовов и контекстную статистику, а также как на основе этих данныхстроить отчеты о соответствии приложения соглашениям SLA. В следующей статьебудут рассмотрены методы инструментирования Java-приложений, не требующиемодифицирования исходного кода. Речь пойдет о перехватах вызовов, классах-обертках идинамическом инструментировании байт-кода.

Переходите к чтению второй статьи.






Загрузка

Описание Имя РазмерИсходный код примеров к статье j-rtm1.zip 316 KБ

http://www.ibm.com/developerworks/apps/download/index.jsp?contentid=373588&filename=j-rtm1.zip&method=http&locale=




РесурсыНаучиться

• Оригинал статьи: Java run-time monitoring, Part 1: Run-time performance and availabilitymonitoring for Java systems. (EN)

• Прочитайте всю серию "Мониторинг выполнения Java-приложений".• Посетите официальную страницу JMX: "Технология Java Management Extensions". (EN)• Прочитайте обзор возможностей технологии Java Management Extensions. (EN)• Обратитесь к Java-документации по базовым классам JMX: пакет javax.management.

(EN)• Ознакомьтесь с Java-документацией по интерфейсам мониторинга и управления JMX:

пакет java.lang.management. (EN)• Прочитайте Java-документацию по классу RMIConnectorServer. (EN)• Обратитесь к руководству "Коннекторы JMX", в котором описываются методы доступа к

стандартным и динамическим объектам MBean через коннекторы RMI. (EN)• Ознакомьтесь с примерами работы с JMX, в том числе с примерами использования

JMX-коннекторов и реализаций системы безопасности JMX. (EN)• Обратитесь к Java-документации "Открытые объекты MBean", в которой описывается

спецификация открытых типов JMX. (EN)• Прочитайте статью "Инструментирование приложений при помощи JMX" (Брайан Гетц,

developerWorks, сентябрь 2006 г.), в которой рассказывается о том, как, используя JMX,можно заглянуть внутрь ваших приложений.

• Ознакомьтесь со статьей "Мониторинг и диагностика быстродействия в JavaSE 6" (Крэйг Кегли и Грег Робертс, developerWorks, сентябрь 2007 г.), в которойописываются средства мониторинга и управления, появившиеся в Java SE 6. (EN)

• Прочитайте отличную серию из трех статей "От черных ящиков к корпоративнымприложениям, часть 1: Управление в стиле JMX 1.1" (Син Ли, developerWorks, сентябрь2002 г.), описывающую технологию JMX. (EN)

• Обратитесь к магазину технической литературы, в котором представлены книги наданную и другие темы. (EN)

• Сотни статей по всем аспектам программирования на Java можно найти на сайтеdeveloperWorks, в разделе Технология Java.

Получить продукты и технологии

• IKVM: виртуальная машина с открытым исходным кодом для компиляции байт-кодаJava в байт-код .NET. С ее помощью упрощается использование JMX в .NET-языках.(EN)

• Узнайте больше о системе IBM для мониторинга производительности, посетивинформационный центр продукта IBM® Tivoli® Monitoring for Transaction Performance.(EN)

• CA/Wily Introscope: коммерческая система для управления производительностью Java иWeb-приложений. (EN)

• JINSPIRED JXInsight: коммерческая система для мониторинга производительности,диагностики, анализа транзакций и общего управления приложениями. (EN)

http://www.ibm.com/developerworks/java/library/j-rtm1/index.html?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/java/library/j-rtm1/index.html?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/ru/views/java/libraryview.jsp?search_by=Java+??????????

http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/

http://java.sun.com/j2se/1.5.0/docs/guide/jmx/overview/JMXoverviewTOC.html

http://java.sun.com/j2se/1.5.0/docs/api/javax/management/package-summary.html

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/package-summary.html

http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/rmi/RMIConnectorServer.html

http://java.sun.com/j2se/1.5.0/docs/guide/jmx/tutorial/connectors.html#wp1049097

http://java.sun.com/j2se/1.5.0/docs/guide/jmx/examples.html

http://java.sun.com/j2se/1.5.0/docs/api/javax/management/openmbean/package-summary.html

http://www.ibm.com/developerworks/ru/library/j-jtp09196/

http://www.ibm.com/developerworks/java/library/j-java6perfmon/?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/java/library/j-java6perfmon/?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/java/library/j-jmx1/?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/java/library/j-jmx1/?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/apps/SendTo?bookstore=safari

http://www.ibm.com/developerworks/ru/java

http://www.ikvm.net/

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?toc=/com.ibm.itmtp.doc/toc.xml

http://www.wilytech.com/solutions/products/Introscope.html

http://www.jinspired.com/products/jxinsight




• PerformaSure: коммерческая система для диагностики проблем производительности ипрофилирования транзакций. (EN)

• Скачайте ознакомительные версии продуктов IBM и опробуйте инструменты разработкиприложений, а также связующее программного обеспечение IBM семейств DB2®,Lotus®, Rational®, Tivoli и WebSphere®. (EN)

Обсудить

• Читайте блоги developerWorksи становитесь членом нашего сообщества. (EN)

http://www.quest.com/performasure/

http://www.ibm.com/developerworks/downloads/?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/blogs/?S_TACT=105AGX99&S_CMP=CP

http://www.ibm.com/developerworks/community




Об авторе

Николас Уайтхед

Николас Уайтхед (Nicholas Whitehead) занимает должность старшеготехнического архитектора в подразделении ADP под названием Small BusinessServices в Флорхэм Парк, штат Нью-Джерси. Он имеет более чем десятилетнийопыт разработки Java-приложений в таких областях, как инвестиционнаябанковская деятельность, электронная коммерция и коммерческое программноеобеспечение. Накопленный опыт развертывания и поддержки приложений (втом числе созданных собственноручно) подтолкнул его к изучению и реализациисистем мониторинга производительности.

© Copyright IBM Corporation 2009(www.ibm.com/legal/copytrade.shtml)Торговые марки(www.ibm.com/developerworks/ru/ibm/trademarks/)

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ru/ibm/trademarks/

готовности Java-систем 1. Мониторинг ...Мониторинг...

Documents

Transcript of готовности Java-систем 1. Мониторинг ...Мониторинг...