Пять ключевых (и только формирующихся) тенденций в сфере наблюдаемости

26.10.2021

Бартоломей Плотка (Bartłomiej Płotka), старший инженер-разработчик ПО, Red Hat:

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

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

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

Мониторинг производительности приложений – везде и всюду

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

Теперь же мы живем в мире вложенной, многоуровневой виртуализации, программно-определяемых инфраструктур SDI (Software Defined Infrastructure) и облачных сервисов. В этой ситуации рабочие нагрузки приложений окружены несколькими слоями другого софта (по сути, тоже приложениями): операционными системами, прокси-серверами, платформами оркестрации, контейнерными движками, виртуальными машинами, внешними сервисами и т.д.

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

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

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

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

Сегодня объединение данных наблюдаемости в определенном центре – это распространенный и проработанный на уровне методов и процессов подход. Как показала практика, он лучше других подходит для выявления перегрузок в облаке, проблем с инициализацией ресурсов и потерявшихся и простаивающих без дела зомби-инстансов. Объединив все подобные сигналы, можно более эффективно использовать облачные ресурсы, например, при поддержке сетей доставки контента (Content Delivery Networks, CDN), и в целом работать более грамотно.

Связанная корреляция – как пить из пожарного шланга

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

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

Постоянное профилирование

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

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

eBPF – масса возможностей в одном механизме

И, наконец, у нас есть eBPF, он же Berkeley Packet Filter – механизм, позволяющий выполнять дополнительный код в ядре Linux. Если мы можем видеть определенные функции внутри ядра с помощью этой «шпионской» техники, то можем и реализовать новые средства наблюдаемости. Кроме того, с eBPF метрики можно начать собирать без какого-либо дополнительного инструментария на уровне приложений.

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

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

Тема:О том, о сём