Мы продолжаем нашу серию заметок, основанных на материалах книги «HP Performance Engineering Best Practices Series». И сегодня расскажем об самых типичных заблуждениях в области мониторинга производительности приложений и сетей.
Основную задачу мониторинга можно определить как сбор метрик, для дальнейшего анализа с целью идентификации источников и причин узких мест. Хотя данное утверждение обычно не оспаривается, существуют типичные заблуждения, которые могут увести от конечной цели.
Рассмотрим наиболее распространенные:
1. Достаточно проводить мониторинг базовых метрик ИТ-инфраструктуры
Инфраструктурный мониторинг занимается сбором и анализом метрик оборудования и ОС. На сегодня, широко распространен ряд продуктов, как платных, так и «бесплатных», которые занимают определенные ниши инфраструктурного мониторинга. Например, Nagios широко используется для мониторинга сетевой инфраструктуры, ZABBIX мониторит Linux, MySQL и Apache, предлагая при этом неплохую визуализацию. Среди платных корпоративных продуктов есть выбор на любой вкус – HP Operations, PRTG, SolarWinds, Microsoft SCOM, и т.д.
Несомненно, отслеживать базовые системные метрики (такие как CPU, память и диск) необходимо, однако эти показатели не предоставляют достаточной информации для настоящего понимания, есть ли у конечных пользователей вопросы к работе приложений. В наше время, зачастую основными причинами подобных вопросов являются проблемы с компонентами приложений, а не с элементами инфраструктуры.
Поэтому, хотя инфраструктурный мониторинг и является критичным, он не предоставляет аккуратной или полной картины действительной работы приложений. Для подобных целей уже используют другой класс продуктов – Quest Foglight, HP Diagnostics, BSM.
2. Достаточно проводить мониторинг процессов или сервисов приложения
Увы, это не так. Современные приложения, как комплексные, J2EE, .NET, так и кастомизированные SOA приложения, задействуют множество систем и различные технологии. Для полного понимания, правильно ли работает приложение, требуется детальный мониторинг и диагностика компонентов, что позволит вникнуть в сложные взаимодействия различных сервисов.
Тот же HP Diagnostics позволяет начать анализ бизнес процессов с точки зрения конечного пользователя, а затем углубиться в компоненты приложений и слои инфраструктуры. Это позволит быстро устранить проблемы с наибольшим влиянием на бизнес, а также остаться в рамках SLA. А Quest Foglight детализирует архитектуру как Java, так и .NET приложений до уровня классов, и отслеживает их работу в вплоть до уровня обработки конкретных HTTP запросов.
3. Мониторинг всех доступных параметров системы или приложения является лучшим подходом
Сбор слишком большого объема данных приводит к усложнению анализа, что может затруднить обнаружение реальных проблем с производительностью. Но ведь 100% покрытие вовсе не обязательно и к этому не стремятся. Известное правило 80/20 – «в 80% проблем обычно виноваты 20% компонент системы или приложения» – справедливо и для мониторинга производительности.
По сути, необходимо отчетливо понимать, какие системы относятся к критическим бизнес функциям, а какие нет, и сосредоточиться на мониторинге ключевых систем и компонент. И если собственных компетенций не хватит, то на помощь придут консультанты, интеграторы, сообщества.
4. Все нагрузочные тесты можно выполнить, используя один и тот же набор метрик
Признаем, некоторые метрики могут применяться в большинстве нагрузочных тестов. Но если мы говорим о качественном мониторинге производительности, а не тестах для проформы (например, чтобы быстро пройти тестировочную часть проекта внедрения), то требуются различные наборы измерений, в зависимости от типа выполняемого теста.
Бизнес приложения часто используют несколько технологических платформ. Как правило, это система виртуализации, обязательно операционная система, и база данных. Естественно, для всех этих платформ необходимо отслеживать уровень нагрузки.
Например, в случае ОС, это загрузка CPU, RAM, Disk IO, и сетевой трафик. С другой стороны, если приложение написано на платформе J2EE и выполняется на сервере приложений, то необходимо отслеживать основные параметры JVM (такие, как garbage collection или GC), и метрики, специфичные для J2EE архитектуры, включая состояние connection pool, session beans и entity beans cache, ну и конечно же время обработки HTTP запросов.
5. Обычно достаточно только мониторинга веб-сервера
При мониторинге сложных современных приложений, для получения реалистичной картины производительности важно понимать их архитектуру. Стандартное веб-приложение состоит, по крайней мере, из веб-сервера, сервера приложений, и сервера баз данных, в большинстве случаев размещенных на нескольких физических машинах и даже с различным физическим месторасположением. С распространением SOA, все больше инфраструктур и сервисов может быть задействовано для генерации ответов конечному пользователю. Потому очень важно осуществлять мониторинг всех задействованных серверов, особенно серверов баз данных.
Возьмем, например, «толстое» клиентское приложение, или приложение Web 2.0, в котором широко используются AJAX и Javascript. «Толстые» приложения, все чаще и чаще, развертываются в режиме терминального доступа. Загрузка на процессор, генерируемая ими, тоже становится фактором производительности системы, как показали наши проекты.
У нас был интересный случай, когда с помощью профайлера, встроенного в Microsoft VisualStudio, мы обнаружили, что WinForms приложение на .NET 4.5 начинало есть CPU при пересчете и отрисовке одной из экранных форм приложения. Это проявилось только после того, как приложение развернули на терминальном сервере.
В наших следующих заметках продолжим рассказ о мониторинге производительности приложений и нагрузочном тестировании с помощью программных продуктов HP.
