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. Такая проверка показывает, что мониторинг различает сам сбой и потерю возможности его измерять.
Ещё по теме
- Grafana показывает No data: проверяем метрику, время и переменные
- Scrape timeout в Prometheus: как различить медленный exporter и проблему сети
Продолжить изучение
Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».
Продолжить на практике
- Prometheus и Grafana: мониторинг и observability ↗
Замечайте сбои до жалоб пользователей. Соберите мониторинг приложения: метрики Prometheus, запросы PromQL, дашборды Grafana и алерты, по которым понятно, что делать. Итог — наблюдаемый сервис и разбор учебного инцидента.
