Network Performance Monitoring (NPM) and Diagnostics | Application Performance Monitoring (APM) | Application-Aware Network Performance Monitoring (AA NPM) | Network Fault Management | Information Security | Network Security

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

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

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

Неразбериха на рынке: все мониторят всё

Приложения, развернутые в динамических средах, таких как контейнеры, микросервисы, бессерверные и облачные системы, требуют новых подходов к мониторингу. Между тем, как отмечают исследовали аналитической компании 451 Research, на рынке сейчас наблюдается определенное пересечение ценностей, которые предоставляют пользователям поставщики из исторически различных направлений мониторинга. К примеру, часть поставщиков, ориентированных изначально на свой сегмент рынка (мониторинг производительности сети (Network Performance Monitoring, NPM), мониторинг производительности приложений (Application Performance Monitoring, APM) или мониторинг инфраструктуры), собирают и анализируют различные наборы данных. Но с точки зрения конечных пользователей граница между этими вендорами становится все более размытой, так как они, в попытке укрепить свое положение на рынке, все чаще предоставляют комплексные решения, которые решают большое количество идентичных между собой проблем.

мониторинг микросервиса

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

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

Чего на самом деле хотят ИТ специалисты?

Чтобы оставаться конкурентоспособными и удержать клиентов, бизнесы стремятся «двигаться быстрее» — более быстро устранять проблемы, расширять возможности и добавлять новую функциональность. Этот тезис подтверждает опрос «Digital Pulse Vendor Evaluations», который в 2018 году провела компания 451 Research. В частности, 24 % ИТ-специалистов, принявших участие в опросе, выбрали пункт «более быстрое реагирование на потребности бизнеса в течение следующих 12 месяцев» в качестве наиболее важной цели для своих организаций.

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

Какие облачные технологии наиболее важны для вашей организации

Результаты опроса ИТ-специалистов на тему «Какие облачные технологии наиболее важны для вашей организации?»

Кроме того, на рынке по-прежнему наблюдается активная миграция предприятий в облачные среды, и, согласно исследованию компании 451 Research, доля центров обработки данных в качестве основной ИТ-среды, принадлежащей непосредственно компаниям, к 2020 году впервые опустится ниже отметки 50 %. Хотя новые технологии, такие как облако, контейнеры, микросервисы и бессерверные вычисления, помогают ИТ-организациям развиваться быстрее, эти технологии также добавляют новые требования к осуществлению мониторинга, в дополнение к поддержке уже существующих возможностей по мониторингу приложений и производительности сети.

Так, стандартного размещения физических или виртуальных брокеров сетевых пакетов (Network Packet Broker) на линии трафика становится недостаточно для осуществления полноценного мониторинга приложений в облачной среде, ведь поддерживающие это приложение контейнеры в любой момент времени могут быть масштабированы, завершены, добавлены или удалены. Кроме того, контейнерные среды часто размещают несколько компонентов приложения на одном сервере или используют зашифрованные «накладки» (оверлейные сети) для соединения с несколькими серверами, что делает сетевой трафик непрозрачным для сбора данных. Поэтому, чтобы соответствовать требованиям функционирования современных приложений, поставщики APM и NPM стремятся внедрять новые подходы к сбору сетевых данных.

Внедрение системы мониторинга микросервисов и контейнеров в облаке

Результаты опроса ИТ-специалистов о местоположении их основной ИТ-среды в четвертом квартале 2018 года и о планах на четвертый квартал 2020 года.

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

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

Продолжение - ЧАСТЬ 2

 

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

Антон Кочуков

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

Комментарии
Тут пока ничего нет, но Вы можете быть первым!
Авторизуйтесь для этого

См. также:

Рейтинг@Mail.ru © 2015 - 2024 NetworkGuru.ru Использование материалов сайта без согласования запрещено!
Заказать звонок