Blackbox exporter: up равен 1, а сайт недоступен — проверяем probe_success

Внешняя проверка сайта настроена, но панель up остаётся зелёной даже при ошибке сайта. Prometheus действительно получает ответ — от blackbox exporter. Сам exporter при этом может вполне успешно сообщить, что целевой сайт недоступен. Два результата описывают разные соединения.

Обычный scrape спрашивает метрики target. В схеме blackbox Prometheus обращается к exporter, передаёт адрес проверяемого ресурса, а exporter выполняет пробу. up относится к получению метрик этим scrape. probe_success сообщает, прошла ли целевая проверка по правилам выбранного модуля.

Сохраним адрес сайта в правильном месте

scrape_configs:
  - job_name: blackbox-http
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com/
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Сначала адрес сайта переносится в параметр target. Затем он сохраняется как instance для удобной идентификации результата. Последним шагом реальный адрес scrape заменяется адресом exporter. Поэтому в labels остаётся понятный сайт, хотя сетевой запрос Prometheus отправляется на другой узел.

Имя http_2xx должно существовать в конфигурации exporter. Для обычного HTTP-модуля достаточно задать prober http и нужный timeout; дополнительные параметры определяют допустимые status codes, redirects, TLS и содержимое ответа. Проверьте именно загруженный модуль: название не является встроенной гарантией бизнес-смысла проверки.

Прочитаем два сигнала вместе

up{job="blackbox-http"}
probe_success{job="blackbox-http"}

При up=1 и probe_success=0 Prometheus получил метрики, а проверка сайта не прошла. При up=0 сначала исследуют доступ к exporter, timeout или некорректный ответ scrape. Если probe_success отсутствует, нельзя автоматически считать его нулём: неизвестно, была ли проба выполнена и опубликован ли результат.

Разделите правила на отказ пробы и отказ сбора. Первое выражение может быть probe_success{job="blackbox-http"} == 0, второе — up{job="blackbox-http"} == 0. Выдержку for выбирают по требуемой реакции и частоте опросов. Полное исчезновение target из discovery требует отдельного контроля ожидаемых объектов.

Найдём этап неуспешной пробы

Exporter отдаёт диагностический ответ при добавлении debug=true к запросу /probe. Выполняйте его с тем же target и module из сетевого окружения exporter. В отладке ищите разрешение имени, попытку соединения, TLS, redirect, HTTP-status и причину признания ответа неуспешным. Адреса с credentials и приватные сведения не стоит переносить в общедоступный журнал.

Дополнительно посмотрите временные метрики пробы и HTTP-status. Быстрый ответ 503 и сетевой timeout требуют разных действий. Если проверка следует перенаправлениям, успешный финальный status может скрывать ошибочный redirect на другой ресурс; при необходимости закрепите условия проверки в модуле.

Определим, что означает доступность сайта

HTTP 200 главной страницы не подтверждает возможность оформить заказ или прочитать данные пользователя. Для бизнес-критичной операции нужен подходящий безопасный endpoint либо отдельный синтетический сценарий. Blackbox HTTP-проба полезна тем, что проверяет путь с точки размещения exporter, включая DNS и TLS.

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

После настройки воспроизведите отдельно недоступный сайт и недоступный exporter на учебном стенде. В первом случае должен измениться probe_success при успешном scrape, во втором — up. Такая проверка показывает, что мониторинг различает сам сбой и потерю возможности его измерять.

Ещё по теме

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

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

Продолжить на практике

  • Prometheus и Grafana: мониторинг и observability ↗

    Замечайте сбои до жалоб пользователей. Соберите мониторинг приложения: метрики Prometheus, запросы PromQL, дашборды Grafana и алерты, по которым понятно, что делать. Итог — наблюдаемый сервис и разбор учебного инцидента.