# Prometheus remote_write отстаёт: WAL, очереди и shards

Диагностика: Prometheus remote_write отстаёт: WAL, очереди и shards. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/prometheus-remote-write-wal-backlog/
Language: ru

Локальный scrape может работать, пока remote_write всё сильнее отстаёт. Проверяйте WAL reader, pending samples, очереди shards и приём удалённого endpoint отдельно. Увеличение max_shards без оценки памяти и возможностей backend способно усилить перегрузку вместо восстановления доставки.

## Разделите локальное и удалённое время

Сравните свежесть одного ряда в локальном Prometheus и удалённом хранилище с учётом его query behavior. Запишите конфигурацию нужного remote_write destination, поскольку очереди нескольких адресов независимы. Up=1 описывает scrape target, а не успешную отправку всей телеметрии дальше. Сохраните ошибки экспорта, timestamps и сетевые наблюдения. Отсутствие свежих точек в удалённом dashboard может также возникать в query layer, поэтому сначала подтвердите фактическую задержку ingestion.


[Официальный источник 1](https://prometheus.io/docs/practices/remote_write/).

## Проследите WAL и shards

Remote write читает WAL и распределяет samples по очередям shards, которые отправляют batches endpoint. Если очередь shard заполняется, чтение WAL может блокироваться для остальных shards этой очереди destination. Prometheus регулирует параллелизм на основе входного потока и скорости отправки. Capacity — число samples в очереди, а max_samples_per_send ограничивает batch; эти параметры не равны retention. Число shards и их ёмкость увеличивают расход памяти вместе с кешем соответствия series IDs и labels.


[Официальный источник 2](https://prometheus.io/docs/prometheus/latest/configuration/configuration/).

## Разберите короткий отказ backend

В учебном опыте удалённый приём временно недоступен, локальные scrape продолжаются, pending растёт. После возврата endpoint важно наблюдать не только отсутствие новых ошибок, но и сокращение отставания. Поток восстановления конкурирует с новыми samples. Если скорость доставки не превышает входную, backlog не исчезнет. WAL не является бесконечным архивом: длительное отставание и compaction могут привести к потере неотправленных данных; фактические ограничения сверяют с версией и настройками.

| Наблюдение | Проверяемый участок |
| --- | --- |
| Локальные точки свежие | Scrape и локальная запись |
| Pending увеличивается | Очередь доставки |
| Ошибки endpoint | Доступность и ответ backend |
| Lag уменьшается | Доставка догоняет входной поток |

## Подберите ограниченное изменение

Проверьте CPU и сеть отправителя, latency и throttling получателя. Затем изучите queue_config и параметры backoff. Более крупный batch может помочь одному backend и ухудшить другой, поэтому нужен контролируемый опыт. Слишком много shards создаёт дополнительные запросы и RAM overhead. Не назначайте глобальный рекомендуемый размер по чужому примеру. Если часть рядов не нужна удалённо, write relabeling уменьшает будущий поток, но не делает прежний backlog автоматически доставленным.

## Проверьте восстановление полноты

После тестового отказа сопоставьте локальный и удалённый временной диапазон, pending и скорость сокращения lag. Отметьте возможные пробелы отдельно от новых успешных отправок. Артефакт содержит destination, queue settings, входной поток и хронологию восстановления. Успешный HTTP ответ на endpoint недостаточен для вывода о полной доставке накопленного объёма. Повторяйте тест после смены backend limits, чтобы конфигурация очереди оставалась связанной с измеренным поведением, а не только со значениями по умолчанию.

Связанные разборы: [gpu monitoring scorecard](/ru/journal/gpu-monitoring-scorecard/); [inference capacity planning](/ru/journal/inference-capacity-planning/).