Статью подготовил Dmitriy Andrichenko | Sales Executive, Russia & CIS | Flowmon Networks
Приветствуем Вас на странице нашей новой статьи, посвященной решению задач контроля производительности распределенных сетевых приложений и баз данных. Данная статья является продолжением цикла публикаций, посвященных решениям компании Flowmon Networks и, в частности, продолжением обзора «Сетевой мониторинг и выявление аномальной сетевой активности» с применением технологий безсигнатурного анализа.
Итак, начнем, но в начале скажем пару слов о компании Flowmon Networks и проблематике вопроса.
Для тех, кому лень читать, в ближайшее время состоится вебинар по решениям Flowmon Networks.
Flowmon Networks, a.s.
Flowmon Networks – европейский ИТ производитель, отмеченный в квадратах и отчетах Gartner, специализирующийся на разработке инновационных решений для сетевого мониторинга, информационной безопасности, защите от DDoS, а также теме нашей сегодняшней статьи – контролю производительности сетевых приложений и баз данных.
Штаб-квартира компании находится в городе Брно, Чешская Республика. Для конечного Заказчика в этом есть одно ключевое преимущество – возможность работы с компаниями санкционного списка. Подробнее о Flowmon Networks, читайте тут или тут.
Но в чем же инновационность решений Flowmon, спросите Вы? Ведь ни одно из вышеперечисленных направлений не ново на рынке. Давно и успешно существуют межсетевые экраны или системы обнаружения вторжений, да и тема мониторинга сама по себе не нова. Все верно, но, как обычно, «дьявол в деталях».
Рассмотрим, например, тему сетевой информационной безопасности. Что в первую очередь приходит в голову? Firewall или, возможно, IDS/IPS? Может быть даже NG Firewall. Все верно, это хорошая проверенная классика, но у которой есть два существенных недостатка:
- ограниченный сигнатурный подход к выявлению проблем безопасности,
- точечная защита только на уровне границы сегментов сети.
Мы же говорим о применении технологий эвристического анализа и машинного обучения. Искусственный интеллект, другими словами. Преимущества очевидны – нет фиксированных сигнатур, которые защитят от zero-day атак только если они обновлены и актуальны.
Безсигнатурный анализ позволит зафиксировать нетипичные атаки уровня приложений, отклонения формата протоколов от RFC и многие другие проблемы, которые доставляют не мало головной боли администраторам каждый день.
Кроме того, второе главное преимущество, это не просто точечный контроль трафика на «стыке» сегментов или периметре, решаемый стандартными средствами защиты, а тотальный контроль и «прозрачность» каждого сетевого подключения в сети.
Мы не предлагаем заменить существующие средства защиты, мы говорим, что в современном мире с постоянно развивающимися технологиями и потенциальными угрозами, стандартного набора средств защиты уже не достаточно. Об этом мы писали ранее, вот тут.
Аналогичная ситуация складывается с задачами контроля функционирования и производительности сетевых приложений, а также баз данных. Полагаю, что каждому знакома ситуация, когда пользователи жалуются на функционирование какого-то бизнес приложения, но проблема не решается. Сетевые администраторы утверждают, что с ЛВС все в порядке и ссылаются на проблемы в самом приложении. Администраторы приложений проверяют сервер, журналы регистрации событий, СУБД и оказывается, что у них тоже все работает. В итоге проблема не диагностируется, на всех уровнях «все в порядке», администраторы «кивают» друг на друга, а у конечного пользователя – ничего не работает. Что делать – не понятно. Бывало? Вот об этом сегодня мы и поговорим.
Архитектура решения
Для правильного понимания подходов и технологий, используемых компанией Flowmon Networks для решения задач контроля производительности распределенных приложений и баз данных, необходимо отметить, что весь анализ базируется на информации о сетевом трафике, который направляется в систему. Одним из плюсов данного подхода можно назвать отсутствие агентского ПО на рабочих станциях и серверах. Производительность пасьянса «Косынка», конечно, замерить не удастся, но вот выявить SQL запрос, «повесивший» базу данных, или кнопку, после нажатия которой приложение зависло, – вполне реально.
В прошлой статье мы уже рассматривали продуктовый портфель Flowmon Networks и процесс инсталляции системы на виртуальной среде VMware EXSi, так что повторяться не будем. Единственным отличием в нашем случае будет метод получения трафика. Так как ни один из Flow протоколов не передает информацию о содержимом пакетов, которая нам нужна для анализа функционирования протоколов 7 уровня по модели ISO OSI, для сбора данных будем использовать зеркальный SPAN (Switched Port Analyzer) порт на коммутаторе.
В этом случае, архитектура решения будет выглядеть примерно следующим образом:
Коммутатор(-ы) зеркалирует требуемый трафик на выделенный сервер (Flowmon Probe), отвечающий за его обработку и преобразование в обогащенный IPFIX формат, который далее передается на центральный узел (Flowmon Collector) для хранения, корреляции и анализа. Вместо SPAN порта, кстати, можно использовать TAP разветвитель трафика:
Преимуществами этого варианта развертывания являются:
- независимость от модели и производителя сетевого оборудования (Cisco, Juniper, любое),
- отсутствие дополнительной нагрузки на существующее сетевое оборудование,
- сохранение существующей логической архитектуры сети компании.
Фактически же, каждый компонент системы может быть как выделенным аппаратным сервером, так и виртуальной машиной. Во втором случае, Flowmon Collector будет включать встроенный Flowmon Probe, но производительность при этом, естественно, будет ниже.
Центральный узел (Flowmon Collector) построен по принципу модульной архитектуры и конфигурируется под задачи каждого Заказчика индивидуально:
Flowmon Collector состоит из ядра системы (Network Visibility Troubleshooting), включающее в себя весь функционал, необходимый сетевым администраторам для мониторинга трафика в ЛВС с детализацией до каждого конкретного сетевого соединения, а также ряда дополнительных и отдельно лицензируемых модулей:
- модуль Anomaly Detection Security (ADS) – выявление аномальной сетевой активности, включая атаки «нулевого дня», на основании эвристического анализа трафика и типового сетевого профиля;
- модуль Application Performance Monitoring (APM) – контроль производительности сетевых приложений без установки «агентов» и влияния на целевые системы;
- модуль Traffic Recorder (TR) – запись фрагментов сетевого трафика по набору предопределенных правил или по триггеру с модуля ADS, для дальнейшего траблшутинга и/или расследования инцидентов ИБ;
- модуль DDoS Protection (DDoS) – защита периметра сети от волюметрических атак отказа в обслуживании DoS/DDoS.
В рамках данной статьи мы рассмотрим, как все работает вживую на примере 2 модулей – Network Visibility Troubleshooting и Application Performance Monitoring.
Инсталляция решения
На тему развертывания виртуальной машины мы уже писали ранее, делается все достаточно быстро и просто из OVF шаблона. Повторяться не будем, напомним только требования к системным ресурсам:
На стороне Flowmon Collector ключевым отличием мониторинга SPAN трафика от NetFlow мониторинга будет являться способ приема данных. Если для NetFlow ранее мы использовали Management interface, со своей конфигурацией IP, то для приема SPAN трафика необходим Monitoring Interface, фактически представляющий собой L2 интерфейс, ассоциированный средствами гипервизора с выделенным физическим портом на шасси сервера.
Другими словами, Monitoring Interface – это и есть Flowmon Probe, встроенный в Flowmon Collector.
Следующим шагом, проверяем, что на Flowmon Collector корректно настроен и готов к приему трафика выделенный порт.
В нашем случае порт UDP/2055 занят под IPFIX/NetFlow с сетевого оборудования, поэтому для трафика с Flowmon Probe возьмем порт UDP/3000. Разделять трафик по портам от разных источников не обязательно, но так удобнее и проще с точки зрения мониторинга и траблшутинга.
Далее настраиваем экспорт трафика из Flowmon Probe в Flowmon Collector. Для этого в разделе Configuration Center -> Monitoring Ports проверим текущие настройки. Главным образом нужно убедиться, что включен мониторинг требуемых приложений 7 уровня ISO OSI, т.к по умолчанию он выключен.
В идеале включить только те протоколы, которые требуется контролировать, но можно и просто включить все.
Сохраняем настройки и снова идем на главный экран Configuration Center, нужно убедиться, что трафик с Flowmon Probe корректно поступает в Flowmon Collector.
Также проверим в разделе Flowmon Monitoring Center -> Sources.
Видим, что трафик начал поступать, система работает. Можно переходить непосредственно к настройке модуля Application Performance Monitoring (APM).
Модуль Application Performance Monitoring (APM)
Разберемся с тем, что конкретно и как именно мы будем контролировать. Какие параметры контролирует Flowmon APM?
- анализ проблемных HTTP и SQL запросов, коды ошибок ответа сервера приложений и БД,
- задержки и потери пакетов, возникающие при клиент-серверном взаимодействии, а также при взаимодействии серверов приложений друг с другом и с серверами БД,
- сведения по каждой транзакции (количество, размер, время, IP-адрес, ID сеанса, имя пользователя ...), а также список проблемных транзакций с нарушениями SLA,
- время ответа приложения (max, min, среднее, процент...) и время передачи на транспортном уровне,
- количество одновременных пользовательских сессий, …
Какие протоколы поддерживает Flowmon APM?
- HTTP 1.1, HTTP 2.0, SSL и TLS,
- SQL (включая MSSQL, Oracle, PostgreSQL, MySQL, MariaDB),
- E-mail (включая SMTP, IMAP, POP3),
- VoIP SIP,
- DHCP, DNS, SMB (включая v1, v2, v3), AS, NBAR2,
- SCADA/IoT (включая IEC 60870-5-104).
В итоге, для каждого контролируемого приложения или БД система вычисляет значение метрики APM Index, варьирующееся в диапазоне от 0 до 100 и зависящее от текущего состояния сервиса. Чем значение метрики выше – тем лучше.
Кастомизируемый интерфейс, основанный на виджетах и дашбордах, позволяет администратору настроить систему индивидуально под себя и контролировать именно те APM Index метрики, которые ему нужны. На примере ниже, система контролирует интернет портал (WebEshop) и его базу данных (MySQL_DB).
В данном примере аналитика производительности разбита по трем блокам:
1. Общая производительность приложения и базы данных за последний день.
Для полноты картины, индекс производительности приложения отображается вместе с индексом производительности базы данных. Это достаточно удобно для траблшутинга и понимания, на каком конкретно участке возникает проблема.
Например, в нашем случае, индекс производительности базы данных – в порядке, он равен 96,839 из 100. А вот с приложением WebEshop наблюдаются явные проблемы, его индекс всего 63,761 из 100.
Сразу же можно заметить и причину подобного рейтинга – высокое время ответа на запросы пользователей. Среднее время – 21.148 секунда, а максимальное – целых 151.797 секунд. Если Вы – администратор онлайн приложения, то понимаете, что мало какой пользователь будет ждать, пока страница будет загружаться 2.5 минуты… И ладно, если это происходит разово, а если пользователю нужно перейти на 2-3-4… страницы? Это уже проблема.
2. APM index за последний день.
С данным разделом все достаточно просто и понятно. Он отображает соотношение числа запросов от общего APM index приложения или базы данных.
Каждый элемент дашборда – интерактивен и кликабелен. Все подчиняется принципу drill-down, когда выбирая на графике интересный участок, можно «провалиться» на уровень ниже, для получения более детальной информации.
Выбирая участок времени, когда была зафиксирована проблема, администратор достаточно быстро найдет ответы на вопросы:
- какие SQL запросы были выполнены в этот момент?
- какие и сколько пользователей работали с системой?
- как реагировала система на запросы пользователей?
- какое было время реакции и задержки системы?
- как проблемы в работе приложения коррелируют с взаимодействием с БД?
- как соответствует работа системы с заданным уровнем SLA?
- и многое другое…
3. Пять самых медленных запросов за последний день.
Современный HTTP портал или WEB приложение – комплексная и сложная программа. Как и любое другое приложение, она состоит из разных страниц и модулей, которые не всегда были написаны одним программистом. Очень часто, современный сайт представляет из себя CMS движок, на который установлены десятки сторонних модулей, расширяющих базовый функционал. Иногда эти модули работают хорошо, а иногда и не очень. Быстро понять, где происходит проблема, удается не всегда и на траблшутинг уходит не один час или день.
С Flowmon APM все становится прозрачно.
Если интересно подробнее – нажимаем на значок «лупы» и получаем детали. Например, для HTTP приложения:
Или для базы данных:
Разумеется, все экспортируется в CSV, поля и колонки настраиваются, фильтры можно сохранять.
Рассмотренные виджеты – это пример стандартных настроек по умолчанию. По необходимости система может быть кастомизирована под индивидуальные задачи – создать собственные дашборды и вывести их на главный экран. Как пример, коды ошибок ответа базы данных:
Или коды ошибок HTTP:
Также, хотим обратить Ваше внимание на важный момент – функционал проактивного мониторинга. Система не только «слушает» и анализирует трафик в пассивном режиме, но и самостоятельно эмулирует взаимодействие «виртуального» пользователя с системой. Данный подход называется Synthetic Users и позволяет автоматически проверять состояние приложения и обнаруживать проблему в тот момент, когда она только начнет происходить, а не после первых жалоб пользователей. Для этого, например, настраиваются выполняемые по расписанию скрипты, проверяющие доступность приложения, функциональность и время ответа.
Что в итоге?
Данный пример является наглядной демонстрацией возможностей работы системы и модуля Application Performance Monitoring (APM), в частности. Не скажу, что работа с Flowmon APM превращает процесс траблшутинга в удовольствие, но то, что этот процесс упрощается и становится значительно быстрее – это точно.
Остались вопросы или хотите протестировать систему? Мы поможем, свяжитесь с нами.
Резюмируем, какие выводы о Flowmon мы можем сделать в сухом остатке:
- Flowmon – решение премиального уровня для корпоративных Заказчиков;
- благодаря универсальности и совместимости, сбор данных доступен с любых источников: сетевого оборудования (Cisco, Juniper, HPE, Huawei…) или собственных зондов (Flowmon Probe);
- возможности по масштабируемости решения позволяют наращивать функционал системы посредством добавления новых модулей, а также повышать производительность благодаря гибкому подходу к лицензированию;
- решение проблем контроля производительности распределенных сетевых приложений и баз данных;
- благодаря полной «прозрачности» с точки зрения установки и присутствия системы в сети – решение не влияет на работу других узлов и компонент Вашей ИТ инфраструктуры;
- Flowmon – единственное на рынке решение, поддерживающее мониторинг трафика на скоростях до 100 Гбит/с;
- Flowmon – решение для сетей любого масштаба;
- лучшее соотношение цена / функционал среди аналогичных решений.
Также, хотим пригласить Вас на наш вебинар, посвященный решениям вендора Flowmon Networks. Для предварительной регистрации просим Вас пройти регистрацию тут.
На этом пока все, спасибо за Ваш интерес!
