Prometheus 2.0 alpha: новый TSDB движок и remote read/write API

В начале июля команда Prometheus выкатила первый публичный alpha Prometheus 2.0. Изменений там много, но главное - полностью переработанный движок хранения данных. Мы в managed держим несколько продакшн-установок Prometheus 1.7, поэтому взяли alpha в руки сразу - понять насколько серьёзен апгрейд и когда вообще думать о переходе.

Что конкретно переделали в TSDB

Старый движок хранения Prometheus 1.x - это chunks + index на основе LevelDB, с известными проблемами: медленный startup при большом числе временных рядов, высокое потребление памяти при большом retention, и тупиковые ситуации с compaction при скачках кардинальности. С этим все давно смирились как с фактом жизни.

В 2.0 движок хранения вынесен в отдельную библиотеку - TSDB. Архитектурно это блоки фиксированного размера по два часа, которые иммутабельны после завершения: данные пишутся в head block в памяти, а потом сбрасываются на диск как неизменяемые блоки. Compaction работает поверх готовых блоков, не мешая записи.

Отдельно появились remote read и remote write API как первоклассные фичи - не экспериментальные заглушки как в 1.7, а часть основной архитектуры.

Что мы мерили на тестовом стенде

Взяли стенд с синтетической нагрузкой: около миллиона активных временных рядов, scrape_interval 30 секунд, retention 15 дней. Это примерно соответствует нашему самому нагруженному клиентскому кластеру.

Цифры по потреблению диска при одинаковых условиях - Prometheus 2.0 alpha занимает примерно вдвое меньше места чем 1.7. Это не тюнинг и не изменение настроек - просто другой движок, который плотнее упаковывает данные благодаря delta-of-delta кодированию и лучшему compaction.

Startup после перезапуска - разница ощутимая. В 1.7 при большом количестве chunk-файлов запуск занимал несколько минут и держал CPU в красной зоне пока Prometheus восстанавливал состояние. В 2.0 alpha - секунды. Head block в памяти воспроизводится из WAL, который есть в новом движке.

Потребление RAM. Здесь картина неоднородная. При небольшом числе серий 2.0 alpha немного экономнее. При большом числе серий с высокой кардинальностью - похоже, alpha ещё не до конца оптимизирован, видели спайки которых в 1.7 не было. Это alpha, не удивительно.

Запросы. На исторических данных - быстрее, за счёт структуры блоков. На свежих данных из head block - примерно то же самое.

Remote read/write: что изменилось по сравнению с 1.7

В 1.7 мы уже использовали remote_write в InfluxDB через Telegraf - и жаловались на него в посте про production-тюнинг. В 2.0 remote write переделан: появился remote read, который позволяет Prometheus запрашивать исторические данные из внешнего хранилища. То есть Prometheus становится не только «пишущим» концом пайплайна, но и читающим через единый PromQL интерфейс.

Для нашей federation-схемы с несколькими площадками это меняет расчёт: вместо хранения долгосрочных данных в самом Prometheus можно отдавать старые блоки во внешнее хранилище и читать их обратно через remote read. Но это пока план а не реализация - в alpha эту связку мы не тестировали.

Почему в production остаёмся на 1.7

Ответ простой - это alpha. Не beta, не release candidate. В changelog честно написано что формат данных может измениться до релиза, обратная совместимость не гарантируется. Строить на этом клиентский мониторинг - не вариант.

Конкретные проблемы которые нашли на стенде:

Нет пути миграции данных. Данные Prometheus 1.x нельзя перенести в новый движок - форматы несовместимы. При переходе на 2.0 история остаётся в старом хранилище, а Prometheus 2.0 начинает с нуля. Для нас это означает потерю ретроспективы, которую клиенты ожидают видеть в Grafana.

Несколько мелких регрессий. Пара Grafana-дашбордов с нестандартными PromQL-запросами вела себя иначе - не критично, но требует проверки всех дашбордов перед переходом.

Нет stable API-гарантий. Конфигурационные ключи storage в 1.7 и 2.0 разные, скрипты запуска и unit-файлы придётся переписывать.

Prometheus 1.7 - рабочий, отлаженный инструмент с понятным поведением. Нет смысла торопиться.

Что планируем

Держим стенд с alpha и обновляем его по мере выхода новых alpha/beta. Когда выйдет rc или стабильный релиз 2.0 - будем готовы: процедура апгрейда понятна, узкие места известны.

Единственное что можем делать уже сейчас - складывать метрики через remote_write в InfluxDB на клиентах у которых это ещё не настроено. Тогда при переходе на Prometheus 2.0 долгосрочная история не потеряется - она будет лежать в InfluxDB и Grafana продолжит её показывать.

Пока выглядит как «выйдет 2.0 stable - будем переходить». Диск жалеть хочется.