Scrape timeout в Prometheus: как различить медленный exporter и проблему сети

Exporter открывается в браузере, но Prometheus несколько раз в час показывает context deadline exceeded. Ручной успешный запрос не опровергает ошибку: он выполнен в другое время, с другой машины и, возможно, без тех же TLS-настроек. Прежде чем увеличивать timeout, нужно выяснить, какая часть опроса не укладывается в срок.

Scrape interval задаёт периодичность опросов target, а scrape timeout — предел ожидания конкретного опроса. Это разные настройки. Timeout не должен превышать interval. Если exporter регулярно отвечает почти весь доступный срок, небольшой рост нагрузки или задержка сети будет превращать успешный scrape в неудачный.

Сопоставим настройки и наблюдения

scrape_configs:
  - job_name: reports
    scrape_interval: 30s
    scrape_timeout: 10s
    static_configs:
      - targets: ['reports-exporter:9100']

Конфигурация разрешает одному опросу до десяти секунд при периоде 30 секунд. Реальные значения проверьте в загруженной конфигурации Prometheus: job может переопределять global, а отредактированный файл ещё не примениться. Затем откройте target и прочитайте last error. Ошибка DNS, отказ TCP и превышение срока ожидания дают разные направления поиска.

up{job="reports"}
scrape_duration_seconds{job="reports"}
scrape_samples_scraped{job="reports"}

Смотрите эти серии на одном временном интервале. Нулевой up означает неудачный scrape. Продолжительность рядом с пределом timeout усиливает гипотезу о нехватке времени, а рост числа samples может объяснять увеличение ответа. Однако длительность не показывает автоматически, сколько заняли DNS, TLS, генерация и передача тела.

Повторим запрос с правильной точки

Диагностический запрос выполняют из того же сетевого окружения, что и Prometheus, с тем же именем target, путём metrics и необходимыми настройками доверия TLS. Следующий пример годится для HTTP-exporter без авторизации при прямом соединении без proxy. Опция --noproxy '*' исключает использование proxy из окружения curl. Если в Prometheus задан proxy_url, для сопоставимой проверки используйте тот же proxy и соответствующие параметры curl вместо принудительного прямого соединения:

curl --noproxy '*' --max-time 10 --output /dev/null --silent --show-error   --write-out 'connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n'   http://reports-exporter:9100/metrics

Все времена измеряются от начала запроса. Значения connect и starttransfer не нужно складывать. Большой промежуток до первого байта может включать подготовку ответа приложением; долгое завершение после первого байта — передачу и формирование оставшейся части. Для точного разделения потребуется журнал и внутренние измерения exporter.

При HTTPS учитывайте TLS-handshake и сертификаты. Не отключайте проверку сертификата ради «исправления» наблюдения: тогда запрос перестанет соответствовать конфигурации Prometheus. При proxy, namespace или NetworkPolicy локальный curl с ноутбука проверяет другой путь.

Отличим сеть от дорогого сбора

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

Если одновременно задерживаются разные targets, сравните загрузку и ресурсы самого Prometheus, DNS, сеть и общие промежуточные компоненты. Успешный TCP-connect ещё не означает успешное получение полного набора метрик. Полезно сопоставить timestamps ошибок нескольких targets и события инфраструктуры.

Выберем действие и проверим его

Увеличение timeout оправдано, когда нормальная полезная работа действительно требует больше времени и остаётся запас до interval. Снижение частоты scrape уменьшает нагрузку, но делает наблюдение менее частым. Кэширование или исправление дорогого коллектора может решить причину, сохранив частоту опроса.

После изменения наблюдайте несколько обычных и пиковых интервалов. Сравните долю успешных опросов и распределение scrape_duration_seconds с новым сроком. Цель — устойчиво получать метрики с понятной задержкой, а не просто убрать красный target на минуту после изменения конфигурации.

Ещё по теме

• P95 в Prometheus: как считать задержку по histogram и не усреднять процентили
• Rate и increase в Prometheus: считаем запросы и учитываем сброс счётчика

Продолжить изучение

Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».