Разработайте решение для мониторинга высокой доступности на основе Prometheus и Thanos с включенной мультитенантностью.

Prometheus - широко известное решение для мониторинга с открытым исходным кодом и де-факто стандарт наблюдаемости в средах Kubernetes.

Он особенно популярен из-за фантастического оператора, который позволяет легко развернуть полный стек мониторинга в кластере Kubernetes:

  • Prometheus собирает метрики из динамически найденных конечных точек (подов, сервисов и т. Д.), А затем предоставляет возможности запроса сохраненных метрик с помощью PromQL.
  • С помощью AlertManager вы можете создавать свои собственные правила, чтобы получать уведомления, когда что-то не так, интегрируясь с популярными решениями, такими как Slack или Pager Duty.
  • Grafana может быть добавлена ​​в микс (не входит в оператор), чтобы иметь красивую панель инструментов по всем этим показателям.

О том, как работает Прометей, нужно знать несколько вещей:

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

Кстати, за последние несколько месяцев стек Prometheus расширился:

  • Локи для агрегирования логов.
  • Tempo для трассировки, совместимой с OpenTelemetry.

В этой статье основное внимание будет уделено основному стеку и тому, как создать надежную масштабируемую установку Prometheus.

Вызовы

Высокая доступность

Но что, если вам нужна высокая доступность для вашей установки Prometheus? Обычно вы добавляете второй экземпляр, а затем какую-то балансировку нагрузки перед двумя вашими экземплярами, и все готово.

Но не в этом случае, поскольку в Prometheus нет «кластерного режима». Каждый экземпляр Prometheus будет работать независимо, очищая одни и те же метрики с одних и тех же конечных точек и сохраняя данные локально в файловой системе. Показатели на двух экземплярах вначале будут одинаковыми, но со временем расходятся.

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

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

Долгосрочное хранение

Экземпляр Prometheus может хранить свои данные только на локальном диске. Здесь есть свои проблемы:

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

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

Вам понадобится прокси-сервис между Prometheus и вашим поставщиком хранилища объектов для хранения метрик.

Доступные решения

Два популярных решения для решения этих проблем:

Оба решения имеют примерно одинаковые перспективы и являются частью Инкубационных проектов CNCF для наблюдения и анализа. Они предлагают:

  • Высокая доступность через несколько экземпляров Prometheus и единую конечную точку запроса.
  • Долгосрочное надежное хранение метрик с использованием выбранного вами объектного хранилища (AWS S3, Google Cloud Storage, MS Azure Blob и т. Д.).

Они похожи и сотрудничают, каждый учится у другого. Явного победителя нет!

Здесь мы сосредоточимся на Таносе.

Архитектуры Таноса

Базовая архитектура с использованием коляски

Танос популярен, потому что его можно быстро и легко настроить с помощью базового сценария развертывания:

  • Вы включаете модуль sidecar в своих экземплярах Prometheus.
  • Вы настраиваете сегмент хранилища объектов для хранения метрик.
  • Коляска будет периодически отправлять метрики в хранилище объектов.
  • Вы можете запрашивать все свои экземпляры Prometheus, используя старый добрый PromQL, с единственной конечной точки, называемой Query.
  • Компонент Query может взаимодействовать с экземплярами Prometheus для получения свежих данных или с хранилищем объектов для более старых данных.

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

Так что, если один Prometheus выйдет из строя и перезапустится, вы потеряете два часа показателей!

Чтобы хранить метрики в режиме реального времени и обеспечивать мультитенантность, вам нужна более сложная архитектура.

Архитектура с использованием компонента приема

Эта архитектура заменяет коляски Таноса на компонент Receive:

  • Вы включаете функцию Удаленная запись в Prometheus, чтобы в режиме реального времени передавать показатели на Thanos Receive.
  • Receive записывает данные в объектное хранилище (а также кэширует их локально).
  • Query получает метрики из Receive напрямую или из корзины для более старых данных.
  • Как и в предыдущей архитектуре, в качестве клиента вы общаетесь с Query только для запроса метрик.

Танос и мультиарендность

Компонент Thanos Receive поддерживает мультитенантность, что является еще одной причиной использования этой части стека.

Мягкая мультитенантность

В сценарии мягкой мультитенантности:

  • Показатели передаются в экземпляр Receive с установленным THANOS-TENANT заголовком HTTP.
  • Receive будет использовать этот заголовок для заполнения метки tenant_id при сохранении показателей в сегменте.
  • Затем вы можете фильтровать метрики по клиенту при выполнении запросов PromQL с помощью этого ярлыка.

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

Если входящая метрика для Таноса не имеет такого заголовка, она будет сохранена со значением по умолчанию для метки tenant_id.

То, что мы здесь описываем, на самом деле является мягкой арендой, поскольку экземпляр Receive используется совместно арендаторами. Но вы также можете выбрать по-настоящему жесткую аренду, настроив несколько пар Receive и Bucket.

Жесткая мультиарендность

В жестком сценарии с несколькими арендаторами:

  • Начнем с архитектуры soft-multi-tenant.
  • Но на этот раз мы добавляем другие Receive экземпляров.
  • Каждый Receive экземпляр может быть выделен одному или нескольким конкретным арендаторам.
  • Любой Receive может получить входящее сообщение от Prometheus и отправить данные в выделенный экземпляр, отвечающий за этого клиента.

Проще говоря, несколько Receive экземпляров образуют кластер. Определение кластера выполняется через файл JSON:

В этом примере:

  • tenant-a - это группа из двух Receive экземпляров, выделенных клиенту A.
  • tenant-b-c - это группа из двух Receive экземпляров, выделенных арендаторам B и C.
  • soft-tenants - это своего рода клиент по умолчанию, который используется для клиентов, не являющихся ни A, ни B, ни C. Он также используется для клиентов без набора заголовков THANOS-TENANT (например, анонимных клиентов).

Реализация

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

Несколько замечаний:

  • Если вы ограничитесь мягкой арендой, достаточно будет только одной группы из Receive экземпляров (в этом примере она называется «по умолчанию»).
  • Чтобы установить стек Таноса, вместо использования необработанных ресурсов вы можете использовать диаграмму Helm, которая поддерживает компонент Receive. Bitnami Thanos Helm Chart - одна из таких. Вы никогда не ошибетесь с графиками Bitnami!

Заключение

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

Танос стал классическим решением для обеспечения высокой доступности с помощью Prometheus, но с недавним введением компонента Receive теперь вы получаете выгоду от мультитенантности и поддержки метрик в реальном времени.