Многих современные Java-приложения включают сложный набор распределенных и зависящих друг от друга компонентов, а также обладают динамической структурой. Поэтому производительность и степень готовности приложения потенциально зависят от множества внешних факторов. Подобные зависимости практически невозможно свести на нет, либо точно смоделировать в тестовом окружении перед вводом в эксплуатацию. А значит, при работе приложения могут происходить всякие неожиданности. Тем не менее можно облегчить последствия и сократить длительность нежелательных событий путем создания и сопровождения системы для всеобъемлющего мониторинга среды, в которой выполняется ваше приложение.
В данной серии из трех статей рассматриваются некоторые принципы и подходы к реализации подобной системы. Сами принципы, а также некоторая часть используемой терминологии имеют общий характер. В сочетании с примерами кода и иллюстрациями они помогут вам сформировать концептуальное представление о мониторинге производительности приложений. Подобная картина подчеркивает необходимость решения данной задачи и помогает в выборе этого решения (коммерческого, с открытым исходным кодом или расширением существующей системы) либо, для особо мотивированных читателей, может служить руководством по разработке такового.
В первой части:
рассказывается о свойствах систем для управления производительностью приложений (Application Performance Management Systems – APM);
описываются распространенные, но нежелательные подходы к мониторингу приложений;
описываются методы мониторинга производительности виртуальных Java-машин (JVM);
Предлагаются варианты эффективного инструментирования исходного кода приложения
Вторая часть будет посвящена методам инструментирования Java-классов и ресурсов приложения без необходимости внесения изменений в исходный код. В третьей части будут рассматриваться вопросы мониторинга ресурсов, размещенных за пределами JVM, в том числе хост-компьютеры и их операционные системы, а также удаленные сервисы, такие как базы данных и системы передачи сообщений. В завершающей части статьи будут обсуждаться дополнительные аспекты, связанные с ARM, такие как вопросы управления данными и их визуализация, построение отчетов и сигнализирование.
В начало
Распространенные удачные и неудачные варианты реализации APM-систем
Чтобы в дальнейшем избежать недоразумений, сразу оговоримся, что, хотя большая часть материала, относящегося к Java, выглядит схоже с профилированием производительности кода и приложений, это не является главной темой статьи. Профилирование – это крайне важный процесс, предваряющий развертывание приложения, который позволяет убедиться (или разубедиться) в том, что ваш Java-код хорошо масштабируется, быстр, эффективен и во всех отношениях прекрасен. Однако после развертывания приложения произойти может все что угодно, поэтому никакие гарантии профайлера, отработавшего на этапе разработки, не смогут оградить вас от возможных проблем на этапе эксплуатации.
Темой данной статьи является реализация некоторых аспектов профилирования на этапе эксплуатации, а также сбор данных в реальном времени при выполнении приложения и всех внешних компонентов, от которых оно зависит. Эти данные представляют собой серии численных результатов измерений, охватывающих обширный круг компонентов с целью формирования подробной картины о состоянии системы в целом. Кроме того, поддерживая историю подобных измерений, можно вывести точные базовые показатели системы, которые помогают заключить, что среда функционирует нормально, либо указывают на причину и масштаб конкретных проблем.
Распространенные недостатки мониторинга
Редкое приложение не обладает вообще никакими средствами мониторинга. Однако на практике часто встречаются следующие недостатки:
Проблемы фрагментированного мониторинга
Мониторинг, осуществляющийся в условиях, когда ни одно представление системы не является полным, называется фрагментированным (siloed). Самые запутанные и плохо поддающиеся диагностике проблемы, как правило, возникают в ситуациях, включающих несколько взаимосвязанных компонентов. В качестве простой иллюстрации представьте себе систему, развернутую на сервере Java-приложений, в состав которого (без ведома владельцев сервера) входит проблемный класс, реализующий пул JDBC-соединений, который не освобождает все открытые соединения.
Анализируя данные своей системы мониторинга, владельцы приложения видят, что со стороны их сервера открыто 100 соединений с базой данных. В свою очередь, администратор базы данных (DBA) через консоль администрирования видит, что со стороны данного компьютера открыто 120 соединений, причем их число стремительно возрастает. Для консолидированной APM-системы не должно составлять трудностей построить график, совмещающий обе эти картины. В момент, когда данные о числе соединений начинают расходиться, любой человек при взгляде на график должен, во-первых, немедленно понять, какое значение показателя является верным, а во-вторых, получить достаточно точное представление о причине проблемы.
Мертвые зоны: некоторые компоненты, от которых зависит приложение, не подвергаются мониторингу, либо данные мониторинга недоступны. Например, мониторинг может осуществляться над базой данных, а не над сетью, по которой происходит обращение. В этом случае может быть проблематично обнаружить сбои в работе сети, так как специалисты по устранению проблем будут заняты исследованием производительности базы данных и симптомов сервера приложений.
Черные ящики: само приложение либо один из внешних компонентов не позволяют осуществлять мониторинг своих внутренних процессов. Примером подобного черного ящика может служить JVM. Например, специалисты, исследующие причины необъяснимой латентности внутри JVM, которая предоставляет только статистику операционной системы (загрузку процессора или объем памяти, занимаемой процессом), могут иметь трудности при выявлении проблем, связанных со сборкой мусора или синхронизацией потоков.
Несовместимые или несвязные системы мониторинга: приложение может выполняться внутри крупного вычислительного центра, обращаясь к большому количеству общих ресурсов, таких как базы данных, высокоскоростные сети хранения данных (storage-area networks – SAN), а также системы передачи сообщений и различное промежуточное программное обеспечение. Кроме того, компании часто обладают сложной структурой, в которой каждая группа использует собственные системы мониторинга и APM (см. заметку «Проблемы фрагментированного мониторинга»). Если не обеспечить консолидированное представление каждого из внешних компонентов, то каждая группа будет иметь доступ только к небольшому фрагменту общей картины работы приложения.
