Диагностика и устранение проблем при записи метрик через Remote API

Наиболее распространенной проблемой является отставание данных, отправляемых в удаленное хранилище, от данных, записываемых в WAL. Обычно это происходит после перезапуска Prometheus или перезагрузки конфигурации.

Если вы столкнулись с отставанием в записи метрик через Remote API:

• Проанализируйте собранные метрики, чтобы выявить причину отставания.
• Попробуйте воспользоваться одним из решений распространенных проблем.

Диагностика проблем при записи метрик через Remote APIДиагностика проблем при записи метрик через Remote API

Если вы подозреваете, что данные отправляются в удаленное хранилище с отставанием:

1. Проверьте, совпадают ли значения метрик prometheus_wal_watcher_current_segment и prometheus_tsdb_wal_segment_current. Если значения не совпадают, это значит, что отправка данных в удаленное хранилище отстает от записи новых данных в WAL.
2. Сравните значение метрики prometheus_remote_storage_queue_highest_sent_timestamp_seconds со значением метрики prometheus_remote_storage_highest_timestamp_in_seconds. Так вы сможете оценить то, насколько велико отставание.
3. В случае отставания сравните метрики prometheus_remote_storage_shards и prometheus_remote_storage_shards_max. Если их значения равны, удаленная запись использует максимально возможное количество шардов.
4. Сравните метрики prometheus_remote_storage_shards_desired и prometheus_remote_storage_shards_max. Если желаемое число шардов больше максимального, текущего максимального количества шардов недостаточно для эффективной удаленной записи.
5. Проанализируйте значения метрики prometheus_remote_storage_samples_retried_total. Длительные завышенные показания этой метрики могут указывать на проблемы с сетью или удаленным хранилищем. В этом случае может потребоваться снизить пропускную способность удаленной записи, чтобы уменьшить нагрузку.

Устранение распространенных проблем при записи метрик через Remote APIУстранение распространенных проблем при записи метрик через Remote API

Настройка удаленной записи производится путем изменения параметров конфигурации Prometheus в секции queue_config внутри секции remote_write.

Неоптимальные ограничения количества шардовНеоптимальные ограничения количества шардов

Удаленная запись Prometheus использует шардирование для увеличения пропускной способности данных. Данные распределяются по набору шардов, количество которых вычисляется на основе недавней пропускной способности и объема поступающих данных. Если удаленная запись не может использовать оптимальное число шардов, это может вызывать задержки в отправке данных в удаленное хранилище.

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

Параметр min_shards отвечает за минимальное число шардов при удаленной записи. Обычно его не требуется менять. Исключением является случай, когда при удаленной записи всегда используется определенное минимальное количество шардов, и тогда увеличение параметра min_shards может улучшить время восстановления после перезагрузки Prometheus.

Недостаточный размер буфераНедостаточный размер буфера

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

За размер буфера шарда отвечает параметр capacity. Рекомендованное значение capacity должно быть от трех до десяти раз больше значения параметра max_samples_per_send. Вы можете поднять параметр capacity для увеличения пропускной способности каждого шарда, но завышенные значения параметра могут привести к излишнему потреблению памяти.

В случае высокой нагрузки на сеть попробуйте увеличить значение параметра capacity и одновременно уменьшить параметр max_shards. Так вы сможете снизить нагрузку на сеть, не изменяя пропускную способность.

Слишком малый дедлайн отправки в удаленное хранилищеСлишком малый дедлайн отправки в удаленное хранилище

У отправляемых в удаленное хранилище данных есть дедлайн отправки, при достижении которого данные будут отправлены в хранилище, даже если пакет данных заполнен не полностью. Дедлайн можно изменить через параметр batch-send-deadline, который устанавливает максимальное время между отправками данных для каждого шарда.

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

Слишком малый размер пакета данныхСлишком малый размер пакета данных

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

Слишком частые повторные попытки отправки данных в удаленное хранилищеСлишком частые повторные попытки отправки данных в удаленное хранилище

Если при отправке данных в удаленное хранилище происходит ошибка, но она является устранимой, происходит повторная попытка отправки. Во избежание потери данных повторные попытки отправки будут происходить бесконечно. За минимальную и максимальную задержки перед повторной отправкой отвечают параметры min_backoff и max_backoff.

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

© 2025 Linux Foundation. Все права защищены. Linux Foundation зарегистрировала товарные знаки и использует товарные знаки. Список товарных знаков Linux Foundation см. на странице Trademark Usage.