Prometheus хранит все собираемые метрики в собственной базе данных временных рядов (TSDB). Со временем база растёт, и если диск заполнится или сервер выйдет из строя, потребуется умение управлять ею и восстанавливать данные. Можно установить Prometheus, настроить несколько целей и оставить его работать на месяцы без проблем. Но однажды /var/lib/prometheus заполнится, Prometheus откажется запускаться, а вы обнаружите каталог с пронумерованными папками, не зная, что это и безопасно ли их удалять.

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

Примеры проверены на Ubuntu 26.04 и RHEL 9, но они одинаково работают на любых современных дистрибутивах Linux с Prometheus 2.x или 3.x.

Как Prometheus хранит данные на диске

Prometheus хранит все собираемые метрики в локальной базе данных временных рядов (TSDB). Эта база специально спроектирована для эффективного хранения данных с временными метками.

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

Заглянув в каталог данных Prometheus, вы увидите примерно такую структуру:

ls -la /var/lib/prometheus/data

Пример вывода:

drwxr-xr-x 4 prometheus prometheus 4096 Jul 20 09:00 01J9ZK3XW9K7...
drwxr-xr-x 4 prometheus prometheus 4096 Jul 20 11:00 01J9ZK5R2M4T...
drwxr-xr-x 3 prometheus prometheus 4096 Jul 21 08:12 wal
lrwxrwxrwx 1 prometheus prometheus   34 Jul 21 08:12 chunks_head -> 01J9ZKAB77Q2.../chunks

Каждая папка с длинным именем называется блоком. Блок содержит метрики, собранные за определённый временной промежуток. Внутри каждого блока находятся:

  • chunks/ – хранит сжатые выборки метрик.

  • index – сопоставляет имена метрик и метки с данными в чанках.

  • meta.json – содержит информацию о блоке: временной диапазон и другие метаданные.

Каталог wal означает журнал упреждающей записи. В него временно попадают свежесобранные метрики перед записью в блок. Это помогает избежать потери данных при неожиданной остановке Prometheus.

Ссылка chunks_head указывает на активные данные в памяти, ещё не записанные в блок.

Если каталог wal растёт значительно быстрее обычного, это обычно означает, что Prometheus не успевает создавать новые блоки. Такое может происходить при задержках сжатия, медленном вводе-выводе или перегрузке Prometheus.

Проверка состояния блоков с помощью promtool

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

Чтобы проанализировать TSDB, выполните:

promtool tsdb analyze /var/lib/prometheus

Пример вывода:

Block ID: 01J9ZK5R2M4TQXK9J8N3PZC7VW
Duration: 2h0m0s
Series: 48213
Label names: 62
Postings (unique label pairs): 1847

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

Обычно это происходит, когда метка содержит часто меняющиеся значения, например идентификаторы запросов, сессий, временные метки или IP-адреса клиентов, из-за чего Prometheus создаёт новый временной ряд для каждого уникального значения.

Другие полезные команды promtool для TSDB:

1. Анализ TSDB

promtool tsdb analyze /var/lib/prometheus

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

2. Список всех блоков

promtool tsdb list /var/lib/prometheus

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

3. Создание блоков из существующих данных

promtool tsdb list /var/lib/prometheus

Пересобирает блоки TSDB из данных OpenMetrics или файлов правил записи. В основном применяется при импорте или восстановлении исторических метрик.

Настройка хранения по времени и размеру

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

Если Prometheus работает как служба systemd, создайте или отредактируйте файл переопределения:

sudo systemctl edit prometheus

Потребуется sudo, потому что конфигурация службы systemd управляется пользователем root.

Добавьте или обновите следующие строки:

[Service]
ExecStart=
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=15d \
  --storage.tsdb.retention.size=10GB

Здесь:

  • --storage.tsdb.retention.time=15d хранит данные до 15 дней.

  • --storage.tsdb.retention.size=10GB ограничивает размер TSDB 10 ГБ.

Если заданы оба параметра, Prometheus применяет то ограничение, которое будет достигнуто первым. Например, если база достигнет 10 ГБ раньше, чем пройдёт 15 дней, старейшие блоки будут удалены для освобождения места.

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

Если вы ещё не освоились с редактированием файлов служб systemd, не беспокойтесь. Курс «Инструменты мониторинга производительности Linux» подробно объясняет настройку служб Prometheus в составе полного стека мониторинга. После сохранения изменений перезагрузите конфигурацию и перезапустите службу:

sudo systemctl daemon-reload
sudo systemctl restart prometheus

Чтобы убедиться, что Prometheus запустился корректно, посмотрите логи:

sudo journalctl -u prometheus -f

Если всё стартовало нормально, вы увидите сообщения о загрузке WAL и успешном запуске TSDB.

Если возникает ошибка Permission denied для каталога данных, убедитесь, что он принадлежит пользователю службы Prometheus:

sudo chown -R prometheus:prometheus /var/lib/prometheus

После этого снова перезапустите службу.

Как сжатие освобождает дисковое пространство

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

Новые данные сначала сохраняются в двухчасовых блоках. По мере старения Prometheus объединяет их в блоки, охватывающие более длительные периоды. В ходе этого процесса просроченные данные окончательно удаляются.

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

Увидеть, когда происходит сжатие, можно в логах Prometheus:

sudo journalctl -u prometheus | grep compact

Пример вывода:

level=info msg="compact blocks" count=3 mint=1721520000000 maxt=1721527200000 duration=4.2s

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

  • count=3 означает, что Prometheus объединил три существующих блока в один.

  • duration=4.2s показывает, что сжатие заняло 4,2 секунды.

  • mint и maxt представляют минимальную и максимальную временные метки нового блока.

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

В таком случае подумайте об увеличении объёма хранилища, снижении кардинальности метрик или уменьшении срока хранения.

Создание снимка перед изменениями

Перед изменением настроек хранения или обслуживанием стоит создать резервную копию TSDB. Prometheus не предоставляет дамп базы данных, как MySQL, но поддерживает живые снимки через Admin API. Снимок создаёт согласованную копию базы без остановки Prometheus.

Admin API по умолчанию отключён, поэтому сначала его нужно включить. Отредактируйте файл переопределения systemd:

sudo systemctl edit prometheus

Добавьте следующую опцию в строку ExecStart:

--web.enable-admin-api

Сохраните файл, затем перезагрузите конфигурацию и перезапустите Prometheus:

sudo systemctl daemon-reload
sudo systemctl restart prometheus

Теперь создайте снимок:

curl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot

Пример вывода:

{
  "status": "success",
  "data": {
    "name": "20260721T081204Z-8f2a91c3d4e5"
  }
}

Prometheus создаёт снимок в каталоге:

/var/lib/prometheus/snapshots/

Подставьте вместо <name> значение, возвращённое API, и заархивируйте снимок:

sudo tar -czf prometheus-backup-$(date +%F).tar.gz \
  -C /var/lib/prometheus/snapshots \
  <name>

Вот что делает эта команда:

  • tar -czf создаёт сжатый архив .tar.gz.

  • -C /var/lib/prometheus/snapshots переходит в каталог снимков перед упаковкой.

  • <name> — это имя каталога снимка, полученное от API.

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

Восстановление из снимка

Чтобы восстановить резервную копию, сначала остановите Prometheus, чтобы он не пытался обращаться к TSDB во время замены.

sudo systemctl stop prometheus

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

Распакуйте архив в каталог данных Prometheus:

sudo tar -xzf prometheus-backup-2026-07-21.tar.gz \ -C /var/lib/prometheus

Затем снова запустите Prometheus:

sudo systemctl start prometheus

При запуске Prometheus сканирует каталог данных, загружает восстановленные блоки TSDB и продолжает использовать их так, будто они были созданы локально. Если вы включили Admin API только для создания снимков, после этого его лучше отключить.

Удалите опцию --web.enable-admin-api из файла переопределения systemd и перезапустите службу. В отключённом состоянии количество административных конечных точек Prometheus сокращается.

На RHEL и Rocky Linux

Команды настройки Prometheus и работы со снимками на RHEL и Rocky Linux те же. Основное отличие — SELinux, который может помешать Prometheus получить доступ к каталогу данных с неправильным контекстом безопасности.

Если вы перенесли TSDB в новое место, назначьте правильный контекст SELinux:

sudo semanage fcontext -a -t var_lib_t "/var/lib/prometheus(/.*)?"
sudo restorecon -Rv /var/lib/prometheus

Первая команда сообщает SELinux, какой контекст должен использовать каталог, а вторая применяет этот контекст к каталогу и всему его содержимому.

Если Prometheus по-прежнему не запускается и логи содержат сообщения вроде Opening storage failed, хотя права доступа выглядят правильно, проверьте недавние блокировки SELinux:

sudo ausearch -m avc -ts recent

Если в выводе видны сообщения о запрете доступа для каталога данных Prometheus, значит, SELinux блокирует доступ. Исправьте контекст SELinux, прежде чем подозревать проблему с диском или самой TSDB.

Если вы планируете регулярно создавать резервные копии Prometheus, можно автоматизировать снимки с помощью cron, а не запускать их вручную. Курс по Bash-скриптингу покажет, как писать и планировать подобные скрипты.

Типичные ошибки и их значение

found (hash collision on unrelated labels) во время сжатия: Это сообщение появляется, когда два разных набора меток дают одинаковое значение хеша. Хотя встречается редко, Prometheus обрабатывает такую ситуацию автоматически во время сжатия, и обычно проблемой это не является.

Ничего исправлять не нужно, если сообщение не сопровождается другими ошибками хранилища.

Диск заполняется, несмотря на установленный retention.size: Опция --storage.tsdb.retention.size ограничивает размер сохранённых блоков TSDB, но не учитывает журнал упреждающей записи (WAL) и данные, ожидающие сжатия.

В периоды интенсивного сбора метрик WAL может вырасти до нескольких гигабайт, прежде чем его содержимое будет записано в блоки. Поэтому не задавайте retention.size равным полному объёму диска. Оставляйте не менее 10–15% свободного места, чтобы у Prometheus было пространство для роста WAL и сжатия блоков.

context deadline exceeded при создании снимка: Если ваш TSDB велик или диск медленный, создание снимка может занять больше времени, чем ожидает клиент. Вместо предположения о неудаче увеличьте таймаут запроса curl:

curl --max-time 120 -X POST \
http://localhost:9090/api/v1/admin/tsdb/snapshot

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

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

Заключение

Теперь вы знаете, как Prometheus хранит метрики в локальной TSDB, где данные располагаются на диске и как настройки хранения управляют удалением старых данных.

Вы также разобрались, как сжатие освобождает место на диске, как анализировать TSDB с помощью promtool и как создавать и восстанавливать снимки через встроенный Admin API. Все эти возможности встроены в Prometheus, поэтому вам не нужны дополнительные инструменты для управления или резервного копирования базы метрик.

В качестве быстрой проверки выясните, как сейчас настроен ваш сервер Prometheus:

ps aux | grep prometheus

Обратите внимание на параметры --storage.tsdb.retention.time и --storage.tsdb.retention.size. Если ни один из них не задан, Prometheus использует стандартное поведение хранения, что со временем может заполнить диск в зависимости от количества собираемых метрик.