Deckhouse Prom++: как мы сжали разметку метрик Prometheus и снизили расход памяти в 2,5 раза с помощью статистики данных

В сфере искусственного интеллекта произошло заметное событие. glebundiy 15 минут назад Deckhouse Prom++: как мы сжали разметку метрик Prometheus и снизили расход памяти в 2,5 раза с помощью статистики данных Сложный 24 мин 396 Блог компании Флант C++ * Open source * DevOps * Высоконагруженные системы * Кейс Миллионы метрик, чистый код, но аллокатор показывает в разы больше памяти, чем должно занимать «полезное» содержимое. Профайлер светит на парсинг, а вы гадаете: куда деваются мегабайты? Привет, меня зовут Глеб Шигин, я С++-разработчик в команде Deckhouse Observability.

В этой статье я покажу, как мы искали скрытый расход памяти в Scraper для Prometheus и шаг за шагом сжимали служебные структуры метрик. Вы узнаете:как мы хотели избежать копирования, но всё равно просели по памяти;почему не нужно хранить короткие строки как длинные;как знание своих данных приводит к простым, но эффективным оптимизациям;как выиграть и по памяти, и по скорости. Если вы когда-нибудь упаковывали данные «впритык» и не хотели потерять в скорости — эта статья для вас.

Технические детали

Все описанные в статье оптимизации реализованы в Prom++ — оптимизированной версии Prometheus от команды Deckhouse, которая полностью совместима с оригиналом по форматам данных и API, но использует более эффективные алгоритмы хранения. ​​Его ключевая особенность — способность обрабатывать те же объёмы данных, что и оригинальный Prometheus, но потреблять до 10 раз меньше оперативной памяти. Про архитектуру Prom++ подробнее рассказывали в одной из прошлых статей.

Репозиторий на GitHubСодержание:Зачем Scraper нужен в Prom++Базовый формат разметки: из чего складывается расход памятиОбнаружение проблемы: где прячется лишняя памятьОт данных к гипотезам: где искать экономию памятиПервая оптимизация: Labels VarintВторая оптимизация: Sample EncodingЧто получилось: замеры после оптимизацииРеализуем и ускоряем ReadИтоги и выводыЗачем Scraper нужен в Prom++В Prom++ за сбор данных отвечает компонент Scraper. Он регулярно опрашивает серверы и приложения, получает HTTP-ответ в текстовом формате Prometheus или OpenMetrics и строит промежуточное представление для записи в TSDB. Так устроен Prometheus изнутри.

Слева — источники метрик: поды в Kubernetes, приложения, сервисы. Service Discovery находит, что опрашивать, а Scraper с заданным интервалом (30 секунд) ходит к каждому таргету, получает метрики в текстовом формате и после Relabel складывает их в TSDB — базу временных рядов. Дальше Query Engine принимает PromQL-запросы и отдаёт данные в Grafana для графиков или в Alertmanager для алертов.

Ruler по расписанию прогоняет правила и тоже может писать результаты обратно в TSDB или в RemoteWrite — для отправки данных во внешние хранилища. Метрики в Prom++ накапливаются в памяти в течение нескольких часов для последующей записи на диск в удобном для чтения формате.

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