Какие существуют подходы для мониторинга в «облаке»?

Первая часть статьи

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

Мониторинг производительности приложений в облачных средах

Инструменты для мониторинга производительности приложений используют агентов на основе хоста или контейнера для сбора событий или метрик, а также все чаще для сбора трассировок. Таким образом, инструменты APM обычно способны найти взаимосвязь между производительностью приложения и производительностью инфраструктуры. Например, они могут связать ошибку приложения с производительностью контейнера, хоста или капсулы (в среде Kubernetes), на которых запущено приложение. Подобная корреляция важна для быстрого устранения неполадок.

Функциональная распределенная трассировка данных способна объединять вместе транзакции, которые могут проходить через микросервисы, контейнеры, облака и центры обработки данных, что позволяет пользователям точно определять медленные спаны (Span), а затем быстро устранять неполадки. Эти программные решения все чаще рассматриваются, как критически важный подход к достижению видимости в контейнерах. Тем не менее, существует ряд проблем, связанный с развертыванием распределенной трассировки данных и извлечением из нее выгоды, особенно в области сбора данных. Реализовать сбор и отправку каждой визуализации транзакции (Trace) практически невозможно из-за существования огромного объема данных, который необходимого переправить по сети для достижения этой цели. Поэтому сохранение образцов трассировки имеет свои компромиссы.

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

Мониторинг инфраструктуры в облачных средах

Инструменты мониторинга инфраструктуры могут также использовать агентов для сбора информации о производительности инфраструктуры в контейнерной среде, например, для отображения метрик и графиков использования ЦП, памяти и диска. Некоторые решения для мониторинга инфраструктуры способны сгруппировать контейнеры по сервисам, чтобы специалисты ИТ-отделов могли использовать этот инструментарий для обнаружения проблем с производительностью конкретного приложения, а затем целенаправленно исследовать инфраструктуру позади этого приложения — в том числе и на уровне контейнеров — для идентификации причины.

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

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

Мониторинг сети в облачных средах

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

Первый подход — это агенты, установленные на каждой виртуальной машине и образе контейнера, которые активируются при запуске рабочей нагрузки. Агенты отправляют пакетные данные в назначенные места сбора, которые затем распределяют собранные пакетные данные среди потребителей. Эту модель используют такие производители, как Extrahop, Gigamon и Nubeva. Преимущество такого подхода заключается в том, что обработка — такая как фильтрация, нарезка, дедупликация и другие манипуляции с пакетами — выполняется на отдельном централизованном сервере или сервисе, что минимизирует потребление дополнительных ресурсов рабочей нагрузкой контейнеров или виртуальных машин. Явным недостатком такого подхода является то, что централизованный сервер или сервис становятся потенциальным узким местом с точки зрения производительности инструмента мониторинга сети и единой точкой отказа при сборе данных.

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

Кроме того, существует несколько подходов к сбору пакетов, ориентированных исключительно на контейнерные среды. Они включают в себя использование сетевого плагина для контейнерной среды, агентов рабочей нагрузки контейнера и «вспомогательных» sidecar-контейнеров:

• Сетевой интерфейс контейнера является фреймворком (framework) для сетевого плагина для контейнерной среды и управляется системой управления контейнерами. Принцип его работы очень близок к виртуальному перехватчику трафика, используемому для сред гипервизора. Траффик, проходящий через контейнерную сеть, захватывается виртуальной сетью, обрабатывается, а затем направляется к следующему месту назначения.
•  Пакеты могут быть собраны с помощью агента, установленного на контейнере приложения. Эти агенты могут запускаться с рабочей нагрузкой контейнера.
• Также агенты могут быть реализованы в конфигурации «sidecar», которая представляет собой контейнер, запущенный параллельно с рабочей нагрузкой контейнера приложения.
• Некоторые из контейнерных сервисов, такие как Envoy proxy, имеют встроенные возможности захвата сетевых пакетов. Этот и подобные ему сервисы могут конкурировать с другими возможностями захвата сетевых пакетов или даже, в некоторых случаях, способны заменять их.

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

Облачные сервисы

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

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

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

В отличие от локальных сетей, где виртуальные порты могут быть сконфигурированы для сбора всех пакетов, например, с помощью виртуального перехватчика трафика, облачные сети не предоставляют такой тип доступа. Это пробел, который облачные сервисы только начинают устранять. Такими примерами являются функциональность VPC Flow Logs от компании Amazon Web Services и доступная на данный момент в предварительной версии TAP (точка доступа к терминалу) виртуальной сети Azure от компании Microsoft. Но эти возможности все еще сильно ограничены в использовании, поэтому решение об их использовании связано с рисками и неминуемо повлечет за собой дополнительные расходы.

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

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

Выводы

ИТ-отделы компаний будут по-прежнему сталкиваться с новыми вызовами при сборе, обработке и статистическом анализе данных о производительности их приложений в контейнерах, микросервисах и облачных средах. Например, как собрать данные о производительности в разных средах, какие инструменты использовать для сбора данных и есть ли смысл использовать один и тот же инструментарий везде, где будут выполняться обработка и хранение данных (в зависимости от того, где находятся рабочие нагрузки). Открытым вопросом остается и то, как обеспечить, чтобы сбор данных происходил по мере изменения рабочих нагрузок приложений. Специалистам ИТ-отделов следует рассматривать мониторинг как практику, которая является адаптируемой к новым средам и способна охватить все среды развертывания приложений, используемые бизнесом. Это означает, что необходимо будет тесно сотрудничать с архитекторами и разработчиками приложений для реализации функциональности сбора и мониторинга сетевых данных в качестве основного элемента любого нового или переносимого в облако приложения.

С другой стороны, добавление поддержки для облачных и контейнерных сред является важным шагом расширения функциональных возможностей решений для поставщиков мониторинга производительности приложений и мониторинга сетевой производительности. Хотя существует несколько способов осуществления сбора данных, результат, как правило, одинаков для всех поставщиков. Некоторые методы способны лучше удовлетворить специфические потребности конкретного предприятия, чем другие, но это свойство будет иметь больший вес для новых продаж, при этом оставаясь с точки зрения потребителя слабой мотивацией для замены или увеличения количества поставщиков решений для мониторинга. Nubeva, стартап в области сбора сетевых данных, который использует уникальный облачный подход, но ему не хватает физических и локальных возможностей по сбору сетевых данных. Возможность расшифровки TLS для контейнеров и Kubernetes, включая поддержку TLS 1.3, является важным фактором выбора для тех компаний, которые ставят повышенные требования к точности измерения эффективности и производительности. Также Nubeva является хорошей целью для приобретения для поставщиков мониторинга сетевой производительности, мониторинга производительности приложений и мониторинга безопасности, которые ищут новые возможности для реализации своих собственных инструментов для захвата сетевых пакетов в облаке.

Появились вопросы или нужна консультация? Обращайтесь!

Вечный параноик, Антон Кочуков.

В чём «шаговая» рефлектометрия кабельных линий выигрывает у импульсной?

Как вести мониторинг веб-приложений в Microsoft Azure? Кейс!

Как меняется рынок мониторинга инфраструктуры в новых условиях облачных вычислений?