Бартломей Плотка, главный инженер-программист компании Red Hat, выделяет на портале Information Age пять ключевых развивающихся тенденций в современной наблюдаемости облаков.

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

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

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

APM повсюду

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

Сейчас мы живем в мире вложенной виртуализации, программно-определяемой инфраструктуры (SDI) и облачных сервисов. Наши рабочие нагрузки приложений часто окружены слоями ПО (также «приложения»): операционная система, прокси, ПО для оркестровки, контейнерный движок, виртуальная машина, внешний сервис и многое другое.

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

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

Федеративное централизованное оркестрованное представление

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

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

Подключенная корреляция внутри «брандспойта»

Большой объем данных, которые мы потребляем и производим прямо сейчас, позволяет нам получать гораздо больше сигналов для удовлетворения наших требований к наблюдаемости. Если мы представим себе, что Интернет вещей (IoT) экспоненциально увеличивает количество точек данных, то мы пьем из прямо брандспойта — в плане потока данных... И это может значительно усложнить задачу наблюдаемости.

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

Непрерывное профилирование

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

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

Улей активности с eBPF

Наконец, перейдем к eBPF, или расширенному пакетному фильтру Беркли. Это механизм, который позволяет нам выполнять дополнительный код в ядре Linux. Если мы сможем посмотреть на определенные функции внутри ядра, используя эту «шпионскую» технику, мы сможем получить новый контроль над наблюдаемостью. В качестве дополнительного преимущества eBPF можно отметить, что он не требует инструментария на уровне приложений для начала сбора метрик.

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

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

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