Архитектура хранения: TSDB, компрессии, индексы и срок жизни данных
Prometheus строит хранение временных рядов вокруг специально разработанной Time Series Database (TSDB). Эта архитектура оптимизирована под высокую скорость записи, эффективную выборку по меткам и экономичное использование дискового пространства при большом объёме данных и высокой кардинальности. В рамках данной главы рассматриваются ключевые компоненты хранения: структура TSDB, журнал WAL, принципы компрессии и кодирования, индексная архитектура, а также практики управления сроком жизни данных (retention) и стратегии долговременного хранения. Подчёркнута роль интеграций с внешними системами и архитектурные решения для сценариев масштабирования и устойчивости.
В Prometheus хранение данных организовано как append-only журнал с последующей компактацией и формированием блоков данных фиксированной длительности. Это упрощает инкрементную запись и упрощает отказоустойчивость: восстановление производится по WAL и последующим применением блоков. Однако данная модель требует тщательного управления размером блока, политики стирания старых данных и компрессии, чтобы обеспечить баланс между задержкой ответов на запросы, временем отклика и затратами на хранение.
Краткое содержание главы
- Архитектурные принципы TSDB Prometheus: структура блоков, WAL, индексы и памятование целостности данных.
- Механики компрессии и кодирования: почему данные сжимаются и как это влияет на скорость запросов.
- Индексация и поиск по меткам: как из скорости чтения формируется эффективная выборка по фильтрам и как это влияет на рост индексов.
- Политики жизни данных: retention, downsampling, архивирование и интеграции с долговременным хранением.
- Интеграции и эксплуатационные практики: remote_write/remote_read, Thanos, Cortex, мониторинг и резервное копирование.
Введение в архитектуру хранения Prometheus
Основной задачей TSDB является хранение миллионов временных серий в оптимальном балансе между объёмом на диске, скоростью записи и эффективностью запросов. Данные пишутся последовательно в журнал WAL, после чего образуются блоки фиксированной длительности и структуры, которые затем индексируются и доступны для чтения. Такой подход облегчает параллелизм и упрощает очистку устаревших данных: старые блоки удаляются целиком, а новые блоки продолжают запись.
Ключевые принципы архитектуры включают:
- Append-only запись в WAL для восстановления при сбое; WAL служит надёжной лентой изменений до того, как они попадают в постоянное хранилище блоками.
- Разделение данных на блоки фиксированной длительности, что упрощает компактацию и управление сроками жизни.
- Эффективное индексирование по меткам (label) и вторичным ключам, позволяющее быстрого реализовать фильтры в запросах.
- Компрессия и кодирование внутри блоков: уменьшение занимаемого пространства без существенного влияния на скорость чтения.
Эта архитектура позволяет Prometheus обслуживать запросы с высокой частотой и сохранять исторические данные в разумных пределах, однако она налагает требования к планированию хранения и к выбору дополнительных решений для долговременного хранения.
Компоненты TSDB: WAL, Head, блоки и индексы
WAL и журнал изменений
WAL (Write-Ahead Log) записывает каждую операцию добавления выборки до того, как она попадёт в постоянное хранилище. Это обеспечивает устойчивость к сбоям: при реставрации Prometheus читается WAL, восстанавливаются недопоставленные/повреждённые данные и повторно применяются к блочным файлам. В современных реализациях WAL поддерживает сегментацию и периодическую архивацию, чтобы снизить накладные расходы на хранение.
Пояснение: WAL обеспечивает долговременную непрерывность данных, особенно в условиях падений системы или непредвиденных перезагрузок. Без WAL риск потери данных возрастает значительно при системных сбоях, даже если физическое хранилище остаётся доступным.
Head и структура блоков
Head - это динамическая часть TSDB, где данные попадают вначале и затем переработке в устойчивые блоки. Внутри головы хранится текущий прогон записей и быстрое индексирование для недавних данных. По мере накопления данных формируются блоки: каждый блок покрывает фиксированный интервал времени (по умолчанию около 2 часов), содержит:
- набор серий и их метаданные;
- таблицу индексов, которые позволяют сопоставлять метки с конкретной серией;
- сгруппированные и сжатые последовательности точек времени и значений.
Стратегия формирования блоков позволяет изолировать данные по времени и облегчает параллельные операции на чтении и записи. Кроме того, каждый блок имеет собственный индекс, что уменьшает накладные затраты на поиск в больших массивах времени.
Индексы и поиск по меткам
Индекс Prometheus устроен как множество взаимосвязанных структур, обеспечивающих быстрое соответствие пары (ярлык/значение) или набору условий фильтрации к конкретной серии. В основе - инвертированный индекс по ярлыкам (label names и label values) с postings-списками и распределением по блокам. Это позволяет ускорить выборку, например, по всем сериям с именем метрики и конкретными значениями лейблов.
Особенности индекса:
- локализованный к каждому блоку: поиск начинается с конкретного блока, что уменьшает объём сканируемых данных.
- поддерживает эластичные запросы по нескольким меткам, агрегации и фильтры.
- размер индекса тесно связан с кардинальностью: слишком большое число уникальных пар лейблов приводит к экспоненциальному росту индекса и потреблению оперативной памяти.
Понимание индексов критично для архитекторов: высокую кардинальность следует ограничивать за счёт продуманной модели лейблинга, агрегаций на уровне запросов и, при необходимости, внешних решений долговременного хранения.
Компрессия и кодирование: как достигается экономия пространства
Внутри блока данные кодируются и сжимаются для эффективного хранения. Основной механизм - компактное кодирование серий и их точек времени, которое затем дополнительно упаковывается механизмом общего блока. Основные принципы:
- упорядоченное хранение точек по времени с использованием эффективных схем кодирования для временных штампиков и значений.
- применение общей компрессии на уровне блока (обычно Snappy) для снижения размера файла без существенного влияния на скорость чтения.
- отсутствие дублирований: повторяющиеся значения или повторяющиеся временные шаблоны кодируются эффективнее, что особенно заметно на сериях с низкой динамикой.
Почему это важно: компрессия не только экономит место, но и улучшает пропускную способность чтения, поскольку обладает меньшими объёмами для копирования по сети и дисковым I/O. Однако слишком агрессивная компрессия может усложнить декодирование и slightly увеличить задержку запросов. Поэтому выбор параметров компрессии следует проводить в рамках эксплуатации и под задачи конкретного окружения.
Политики срока жизни данных: retention, компактация и архивирование
Retention и стратегия хранения
Retеншн - это сохранения данных в TSDB в течение заданного времени. В Prometheus retention обычно задаётся через флаги командной строки или конфигурацию (например, storage.tsdb.retention.time). Принято различать:
- короткосрочный retention для оперативной аналитики и оперативных дашбордов;
- долгосрочный retention с использованием внешних решений (remote storage) для архивирования и последующего анализа.
Ключевые принципы:
- соответствие retention-таймам бизнес-требованиям и регуляторным требованиям.
- планирование хранения: вычисление потребностей в дисковом пространстве, управляемый рост индексов и блоков.
- контроль за кардинальностью: чрезмерная разнообразность меток ускоряет рост индекса и затрат на хранение.
Компактация и управление блоками
Компактация в TSDB - это процесс объединения меньших блоков в более крупные с целью снижения количества блоков и уменьшения индекса, который должен обрабатываться на запросах. Обычно компактация идёт по расписанию и по условиям заполнения блоков. Важно:
- обеспечить баланс между частотой компактации и задержками при чтении: слишком агрессивная компактация может привести к задержкам на запись.
- учитывать требования к чтению по диапазонам времени: целевые интервалы блоков должны соответствовать типичным паттернам запросов.
- поддерживать возможность быстрой очистки старых блоков: после достижения retention старые блоки должны удаляться или архивироваться.
Архивирование и долговременное хранение
Для активной аналитики в течение длительного времени используют внешние системы (remote storage). В Prometheus это реализуется через механизмы remote_write и remote_read, а в экосистемах как Thanos, Cortex или Mimir - через глобальные решения, которые позволяют хранить исторические данные в распределённых хранилищах (облачные хранилища, локальные СХД, объектные хранилища и т. п.).
Поддержка remote storage предоставляет следующие преимущества:
- масштабируемость: хранение может выходить за рамки локального дискового пространства.
- долговременная аналитика: возможность осуществлять сложные расчёты на данных за длительный горизонт.
- устойчивость: репликация и распределённость снижают риски потери данных.
Разумеется, удалённые хранилища добавляют задержку к некоторым запросам, поэтому их роль следует рассматривать как Ergänzung к локальному TSDB для целей архивирования и глубокого анализа.
Интеграции и эксплуатационные практики
Интеграции с remote storage: Thanos и Cortex
Для сценариев масштабирования и долговременного хранения часто используются решения, которые дополняют Prometheus логикой удалённого хранения. Примеры:
- Thanos: обеспечивает глобальное хранилище данных, кэш запросов и агрегацию по нескольким кластерам Prometheus. Позволяет объединённо хранить данные и сохранять единый обзор по времени и метрикам.
- Cortex: предлагает масштабируемое хранение и многокластерное окружение со стеком микросервисов. Включает долговременное хранение и горизонтальное масштабирование.
Эти инструменты не заменяют локальный TSDB, но позволяют плавно переносить данные в долговременное хранилище, обеспечивая единый интерфейс запросов и возможность агрегаций через Remote Read/Write. Важной практикой является выбор между Thanos и Cortex в зависимости от задач: единый глобальный просмотр и репликация против модульной архитектуры и гибкого масштабирования.
Практики эксплуатации и мониторинга хранения
- Регулярное резервное копирование конфигураций и жизненно важных данных; копирования TSDB сами по себе не заменяют систем резервирования.
- Мониторинг нагрузки на диск, скорости ввода-вывода и потребления памяти TSDB.
- Наблюдение за ростом индексов и кардинальности: при резком росте рассматривать переразметку лейблов или внедрять агрегации на уровне запроса до обращения к индексу.
- Проверка планов обновления и миграций: перенос блоков и обновления форматов требуют планирования.
- Безопасность: контроль доступа к данным на уровне файловой системы и шифрование критичных данных в хранилище.
Пример конфигурации (-retention, remote)
-
Пример конфигурации для локального retention:
--storage.tsdb.retention.time=30d --storage.tsdb.retention.size=500GB
-
Пример настройки remoto в Prometheus (для сохранения в внешнюю систему):
remote_write: - url: "https://remote.example.org/api/v1/write" remote_read: - url: "https://remote.example.org/api/v1/read"
Упоминание внешних систем не означает их обязательность, но даёт ясное направление для архитекторов: как обеспечить устойчивость к росту данных, как сохранять историю и как строить аналитические пайплайны вокруг Prometheus.
Практики проектирования и реализации
Планирование политики хранения
- Определите горизонт retention, исходя из требований аналитики и регуляторных ограничений.
- Рассчитайте необходимое дисковое пространство, учитывая кардинальность и ожидаемую скорость записи.
- Разработайте стратегию перехода данных в долговременное хранилище: какие данные остаются в локальном TSDB, какие отправляются в remote storage и с какой частотой.
Управление кардинальностью
- Оптимизируйте конфигурацию меток: избегайте избыточной детализации и дублирующих лейблов в сценариях с очень большими объёмами метрик.
- Используйте агрегации на уровне запроса, где возможно, чтобы минимизировать обращение к большому количеству серий.
- Мониторьте рост индекса и применяйте технические меры по ограничению его размера.
Резервирование и тестирование
- Регулярно тестируйте резервное копирование TSDB и удалённых хранилищ.
- Проводите практические восстановления, чтобы подтвердить способность реконструировать данные из WAL и блоков.
- Внедряйте каналы для тестирования изменений конфигураций хранения без воздействия на продакшн-окружение.
Эволюция архитектуры
- В условиях растущего объёма данных следует рассмотреть коммерческие или открытые решения для долговременного хранения, которые сохраняют совместимость с Prometheus и обеспечивают масштабируемость.
- Оцените переход к единым кластерам для упрощения управления запросами и консолидации сохранённых данных.
Key takeaways
- TSDB Prometheus строится вокруг WAL, HEAD и фиксированных по времени блоков, что обеспечивает высокую скорость записи и эффективный доступ к данным.
- Компрессия и кодирование внутри блоков снижают объём хранения и улучшают пропускную способность чтения, однако требуют балансирования между размером блока и задержкой запросов.
- Индексы по лейблам критически зависят от кардинальности. Оптимальная стратегия - ограничение кардинальности и продуманная модель лейблинга.
-Retention policies и долговременное хранение через remote storage (Thanos, Cortex) позволяют масштабировать хранение и сохранить аналитическую ценность данных на длительный срок. - Эксплуатационные практики: мониторинг, резервное копирование, тестирование восстановления и планирование миграций являются неотъемлемой частью устойчивой архитектуры хранения.
- Интеграции с внешними системами требуют чёткого баланса между задержками запросов и доступностью исторических данных.
- Архитектура Prometheus по сути ориентирована на быстрый доступ к недавно записанным данным и на долговременное хранение в системах удалённого хранения, что требует продуманной политики ретенции и мониторинга.
FAQ
- Каковы базовые компоненты хранения в Prometheus и чем они отличаются?
- Основные элементы - WAL, Head и блоки данных. WAL служит журналом изменений и обеспечивает устойчивость к сбоям. Head - это рабочая область, где данные накапливаются перед формированием устойчивых блоков. Блоки представляют собой зафиксированные временные диапазоны, которые ускоряют компактацию и поиск по времени. Индексы в блоках позволяют быстро находить серии по лейблам, но их размер растёт с кардинальностью метрик.
- Что такое retention и как он управляется в Prometheus?
- Retention - это период, на который сохраняются данные в локальном TSDB. Управляется через параметры сохранения: продолжительность хранения и объем пространства. Периодически данные старше retention удаляются, а в долгосрочном сценарии они могут архивироваться в remote storage. Важно согласовать retention с бизнес-задачами и регуляторными требованиями.
- Какую роль играет компрессия в TSDB и какие ограничения она налагает?
- Компрессия уменьшает размер блоков, что экономит место на диске и снижает сетевые издержки во время чтения. Основной механизм - сжатие внутри блока (часто Snappy). Важно сбалансировать скорость декодирования и плотность хранения: слишком агрессивная компрессия может незначительно увеличить задержку чтения.
- Какие проблемы могут возникать с высокой кардинальностью и как их снижать?
- Высокая кардинальность приводит к росту индексов и объёма памяти, что может сказаться на производительности и стоимости хранения. Решения: ограничение количества уникальных лейблов, агрегации до запроса, использование внешних систем долговременного хранения, разделение рабочих данных на отдельные пространства (проект/профиль) и упрощение запросов.
- Каковы варианты долговременного хранения и чем они полезны?
- Варианты - remote storage через remote_write/remote_read, а также внешние решения, такие как Thanos или Cortex. Они позволяют сохранить данные за пределами локального TSDB, обеспечивают глобальные запросы и масштабируемость. Выбор зависит от требуемой глобальной видимости, Latency/Throughput и дубляжа данных.
- Какие риски сопровождают интеграцию Prometheus с внешним хранилищем?
- Риски включают задержки чтения, задержки обновления кэшей и сложности консолидации данных между кластерами. Необходимо продумать стратегию кэширования, SLAs по ответам и тестирование сценариев сбоев. Важно обеспечить согласование зон accessible и надёжности, чтобы аналитика не прерывалась.
- Как организовать мониторинг самой системы хранения Prometheus?
- Рекомендуется мониторить: скорость записи, размер WAL, размер и число блоков, рост индексов, задержки запросов, пропускную способность к удалённым хранилищам и нагрузку на диск. Принято использовать встроенные метрики Prometheus для мониторинга TSDB, а также внешние системы мониторинга для удаленных компонентов (Thanos Cortex).
- Какие практики миграций и обновлений хранения полезно учитывать?
- Перед миграцией выполните резервное копирование, протестируйте новый формат/параметры на стенде, спланируйте окно обслуживания и проверяйте совместимость версий. Для перехода между локальным хранением и remote storage полезна поэтапная миграция с верификацией целостности и согласованности данных.
- Что учитывать при выборе между Thanos и Cortex для удалённого хранения?
- Выбор зависит от задач: Thanos обеспечивает единый глобальный вид данных по нескольким Prometheus-инстансам и эффективную агрегацию. Cortex предлагает модульную архитектуру и горизонтальное масштабирование. В любом случае следует определить требования к консолидации данных, latency и бюджету операционной поддержки.
- Какие практические шаги рекомендуется предпринять при проектировании архитектуры хранения?
- Определить retention policy и требования к долгосрочному хранению; оценить кардинальность и влияние на индексы; спроектировать стратегию компактации и блоков; выбрать подход к удалённому хранению и интеграцию с существующей инфраструктурой; внедрить мониторинг и тестирование резервного восстановления.
