Танос — Масштабируемый Прометей

Как надежно и экономично хранить петабайты исторических данных? Можно ли это сделать без ущерба для времени отклика? Можно ли получить доступ ко всем метрикам, расположенным на разных серверах Prometheus, с помощью одного запроса API? Есть ли способ объединить реплицированные данные, собранные с помощью Prometheus HA? Чтобы решить эти проблемы, мы создали Таноса.

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

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

Хотя это отличная модель развертывания, часто бывает необходимо получить доступ к данным на разных серверах Prometheus через один API или пользовательский интерфейс — глобальное представление.

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

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

Иерархическая Федерация .

Это означало создание одного метасервера Prometheus, который собирал некоторые показатели с каждого конечного сервера.

Этот подход оказался проблематичным.

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

Кроме того, такая федерация не позволяет получить истинное глобальное представление, поскольку не все данные доступны из одного запроса API. С этим тесно связано унифицированное представление данных, собранных на серверах Prometheus высокой доступности (HA).

Модель высокой доступности Prometheus независимо собирает данные дважды, что настолько просто, что не может быть проще.

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

Конечно, существует потребность в высокодоступных серверах Prometheus. В Improbable мы очень серьезно относимся к поминутному мониторингу данных, но наличие одного экземпляра Prometheus на кластер — это единственная точка отказа.

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

Даже простое развертывание может вызвать незначительные сбои в сборе метрик, поскольку перезапуски могут значительно превышать интервал очистки.

В Improbable нас заставили настроить срок хранения метрик на девять дней (для Prometheus 1.8).

Это накладывает очевидные ограничения на то, как далеко назад мы можем заглянуть.

В Прометее 2.0 в этом плане улучшились, так как количество таймсерий больше не влияет на общую производительность сервера (см.

Основной доклад KubeCon о «Прометее 2» ).

Однако Прометей хранит данные на локальном диске.

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

Кроме того, в Improbable мы заботимся о надежности, простоте и стоимости.

Большие локальные диски сложнее эксплуатировать и выполнять резервное копирование.

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

Стандартным решением этой проблемы будет понижение частоты дискретизации (downsampling) – уменьшение частоты дискретизации сигнала.

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

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

Именно это и делает компонент Таноса.

Коляска .

Он развертывается рядом с каждым сервером Prometheus и действует как прокси, обслуживая локальные данные Prometheus через API-интерфейс gRPC Store, позволяя получать данные временных рядов по тегам и временным диапазонам.

С другой стороны, это масштабируемый компонент Querier без сохранения состояния, который делает немного больше, чем просто отвечает на запросы PromQL через стандартный HTTP API Prometheus. Querier, Sidecar и другие компоненты Thanos взаимодействуют через протокол сплетен .

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

Кроме того, практически любое объектное хранилище доступно через известный API S3. Прометей записывает данные из оперативной памяти на диск примерно каждые два часа.

Сохраненный блок данных содержит все данные за фиксированный период времени и является неизменяемым.

Это очень удобно, поскольку Thanos Sidecar может просто просмотреть каталог данных Prometheus и по мере появления новых блоков загружать их в сегменты объектного хранилища.

Загрузка в объектное хранилище сразу после записи на диск также позволяет сохранить простоту парсера (Prometheus и Thanos Sidecar).

Это упрощает поддержку, стоимость и проектирование системы.

Как видите, резервное копирование данных очень просто.

А как насчет запроса данных в объектном хранилище? Компонент Thanos Store действует как прокси для получения данных из объектного хранилища.

Как и Thanos Sidecar, он участвует в кластере сплетен и реализует API магазина.

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

Блоки данных временных рядов состоят из нескольких больших файлов.

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

Вместо этого Store Gateway знает, как обращаться с форматом хранения Prometheus. Благодаря умному планировщику запросов и кэшированию только необходимых индексных частей блоков можно свести сложные запросы к минимальному количеству HTTP-запросов к файлам объектного хранилища.

Таким способом можно сократить количество запросов на четыре-шесть порядков и добиться времени отклика, которое вообще сложно отличить от запросов к данным на локальном SSD.



Как показано на диаграмме выше, Thanos Querier значительно снижает стоимость запроса данных объектного хранилища за счет использования формата хранения Prometheus и размещения связанных данных рядом.

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

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

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

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

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

Таким образом, понижение разрешения не только возможно, но и не приведет к заметной потере точности.

Для субдискретизации данных Compactor непрерывно агрегирует данные с разрешением пять минут и один час.

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

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

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

При желании пользователь может управлять этим напрямую через параметр «шаг» в запросе.

Поскольку стоимость хранения одного ГБ невелика, по умолчанию Танос хранит необработанные данные, данные с пятиминутным и часовым разрешением.

Исходные данные удалять не нужно.

Они уменьшают сложность, задержку и стоимость запросов.

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

Это особенно полезно при переходе с обычного Prometheus. Давайте быстро подведем итог тому, что мы узнали о компонентах Таноса, на кратком примере.

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

Мы всегда приветствуем запросы на включение и проблемы GitHub. А пока не стесняйтесь обращаться к нам через Github Issues или Slack. Improbable-eng #thanos если у вас есть вопросы или отзывы, или вы хотите поделиться своим опытом использования! Если вам нравится то, что мы делаем в Improbable, не стесняйтесь обращаться к нам — у нас всегда есть вакансии ! Узнайте больше о курсе.