В этом материале
Локальный scrape может работать, пока remote_write всё сильнее отстаёт. Проверяйте WAL reader, pending samples, очереди shards и приём удалённого endpoint отдельно. Увеличение max_shards без оценки памяти и возможностей backend способно усилить перегрузку вместо восстановления доставки.
Локальный 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.
Проследите 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.
Разберите короткий отказ 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; inference capacity planning.