Пинг-мониторинг регулярно отправляет на хост небольшие тестовые пакеты и фиксирует, отвечает ли он, сколько длится путь туда и обратно и сколько пакетов теряется. Он показывает, доступна ли машина по сети, но не то, работает ли размещённое на ней приложение. Используйте ping для устройств и сервисов без веб-эндпоинта, а HTTP-проверки — везде, где важна страница или ответ API.
Как работает пинг-мониторинг
Классический ping — это ICMP Echo Request, на который цель отвечает Echo Reply. Мониторинг отслеживает:
- Время приёма-передачи (RTT): задержку от отправки пакета до ответа, обычно как среднее значение и p95.
- Потерю пакетов: долю пакетов, которые не вернулись. Устойчивые потери выше примерно 1–2 % на проводном канале, как правило, стоит расследовать.
- Джиттер: разброс RTT между замерами, критичный для VoIP и трафика реального времени.
Многие сети блокируют ICMP или ограничивают его частоту. В таком случае TCP-ping, измеряющий время установки соединения с открытым портом, например 22 или 443, даёт надёжный сигнал доступности, а UDP-проверки покрывают такие сервисы, как DNS на порту 53. Подробнее о механике — в статье как работает пинг-мониторинг.
Ping против HTTP-проверок: уровень 3 против уровня 7
Ключевое различие — в том, где заканчивается проверка: ping работает на сетевом уровне, HTTP — на уровне приложения.
| Вопрос | Ping (ICMP/TCP/UDP) | HTTP-проверка |
|---|---|---|
| Доступен ли хост? | Да | Косвенно |
| Деградирует ли маршрут (задержка, потери)? | Да | Частично |
| Возвращает ли веб-сервер 200? | Нет | Да |
| Корректно ли содержимое ответа? | Нет | Да, с проверкой ключевых слов или JSON |
| Работает с устройствами без веб-сервера? | Да | Нет |
Сервер может безупречно отвечать на ping, в то время как Nginx возвращает 502, а приложение застряло в цикле перезапусков. Успешный ping никогда не доказывает, что сайт работает.
Когда ping — правильный выбор
Ping лучше подходит в качестве основной проверки, когда у цели нет HTTP-интерфейса или важен сам сетевой путь:
- Маршрутизаторы, коммутаторы и межсетевые экраны. Часто они доступны только по SSH или SNMP. Ping подтверждает, что устройство живо, и выявляет рост задержки на аплинках.
- VPN-шлюзы и межсайтовые туннели. Ping хоста за туннелем показывает, проходит ли трафик на самом деле, а не просто включён ли шлюз.
- Серверы баз данных и кешей. Хосты PostgreSQL, MySQL или Redis не должны отдавать HTTP. TCP-ping на порт сервиса — честный сигнал.
- IoT- и периферийные устройства. У камер, датчиков и POS-терминалов зачастую есть лишь IP-адрес и ответчик ICMP.
- Почтовые, игровые и другие не-HTTP-серверы. SMTP, собственные TCP-сервисы и игровые UDP-серверы удобно контролировать TCP- или UDP-проверками.
Типичный интервал — 30–60 секунд, с оповещением после двух-трёх неудач подряд, чтобы отсеять кратковременные сбои.
Когда нужны HTTP-проверки
Всё, к чему клиенты обращаются через браузер или клиентскую библиотеку, требует HTTP-мониторинга: сайты, сценарии входа и оформления заказа, REST- и GraphQL-API. HTTP-проверки контролируют коды статуса, время ответа, редиректы и содержимое и тем самым ловят сбои выше сетевого уровня: неудачные деплои, ошибки базы данных, проявляющиеся как 500, или неверно настроенные CDN. Если ваш SLA учитывает успешные запросы, одним ping его не измерить.
Почему сочетание обеих проверок ускоряет диагностику
Когда обе проверки направлены на один сервис, оповещение «сайт недоступен» превращается в диагноз:
- Ping не проходит, HTTP не проходит: вероятно, проблема в сети, на хосте или у провайдера.
- Ping проходит, HTTP не проходит: хост доступен, поэтому смотрите на веб-сервер, приложение, TLS или внешние зависимости.
- Обе проходят, но растёт задержка: сравните RTT со временем HTTP-ответа, чтобы отличить перегрузку сети от медленного кода.
Несколько регионов добавляют ещё одно измерение: если ping пропадает только из одной локации, вероятнее проблема регионального маршрута, а не вашего сервера. UpScanX выполняет ICMP-, TCP- и UDP-проверки наряду с HTTP/HTTPS-мониторингом из более чем 15 точек по всему миру, поэтому оба сигнала отображаются на одной временной шкале, а ИИ-отчёты сопоставляют связанные оповещения и подсказывают вероятную первопричину. Оповещения отправляются по электронной почте, в Slack, Telegram, Microsoft Teams или через вебхук.
Главное
- Ping измеряет доступность, RTT, потерю пакетов и джиттер на сетевом уровне; о состоянии приложения он ничего не говорит.
- Выбирайте ping, а там, где ICMP фильтруется, — TCP- и UDP-проверки для маршрутизаторов, межсетевых экранов, VPN-шлюзов, серверов баз данных, IoT-устройств и не-HTTP-серверов.
- Используйте HTTP-проверки для всего, от чего зависят пользователи и API-клиенты.
- Сочетайте оба вида проверок для критичных сервисов, чтобы сам характер оповещений указывал, какой уровень вышел из строя.
Чтобы добавить проверки сетевого уровня к вашим мониторам доступности, начните с пинг-мониторинга UpScanX.