Ping — самый простой способ проверить, жива ли машина. Отправляем ICMP ECHO_REQUEST, жду ответ. Если пришёл ECHO_REPLY — машина online. Не нужен HTTP server, не нужен открытый port, не нужна авторизация. Просто: есть соединение в сети или нет.
Звучит просто, но есть подвох. Ping — это мониторинг инфраструктуры, не сервиса. Хост может пингаться (машина online), но database упал, nginx вернул 500, всё сломалось. Ping этого не видит. Поэтому ping используют в combination с TCP и HTTP checks для полного покрытия.
Как работает ICMP ping
Ping Protocol: ICMP ECHO
ICMP (Internet Control Message Protocol) — протокол управления сетью. Он сидит на одном уровне с IP, используется для диагностики.
Ping packet'а:
- Type: 8 (ECHO_REQUEST)
- Code: 0
- Checksum
- Identifier (process ID)
- Sequence number (какой по счёту ping из серии)
- Timestamp (когда отправили)
- Optional data payload
Ответ: хост получает ECHO_REQUEST, отправляет ECHO_REPLY обратно с тем же data.
Типичный ping процесс
$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=12.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=12.4 ms
--- 8.8.8.8 statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/stddev = 12.2/12.35/12.5/0.13 msИнтерпретация результатов
Latency (time): 12.3 ms = round-trip time. Обычно до 100ms локально, до 500ms в другие регионы.
TTL (Time To Live): 119 = было 128 (default Linux), маршрут прошёл через 9 hop'ов. Если TTL упал до 0 — пакет потерян (слишком много hop'ов).
Packet loss: 0% = все 4 пакета пришли. 25% = 1 из 4 потерян. High packet loss (>5%) = сеть degraded.
Min/Avg/Max: variability. Если max >> avg (12.2 vs 50ms) — сеть имеет jitter (качество нестабильно).
Когда ping мониторинг полезен
Bare metal серверы без HTTP
Машина работает как gateway, firewall, или raw compute node. Нет веб-сервера, нет TCP services. Единственный способ проверить alive это ли ping.
IoT devices и embedded systems
Router, smart sensor, industrial device. Они могут пингаться, но не иметь HTTP API. Ping проверяет, питаются ли они и имеют ли сетевое соединение.
Network health и latency tracking
Даже если вы мониторите HTTP, полезно трекировать ping latency отдельно. Если вашего веб-приложения latency вырастет с 100ms до 300ms — это сигнал, что сеть деградировалась (не приложение).
Мониторинг инфраструктуры (cloud instances, VMs)
AWS EC2 instance, Google Compute Engine VM, Digital Ocean droplet. Даже если приложение упало, machine всё ещё должна пингаться. Ping confirms что она powered on и имеет сетевое соединение.
Диагностика network issues
Если HTTP check fails но TCP к порту открывается, а ping отвечает медленно — проблема в сети, не в приложении. Ping помогает narrowing down root cause.
Когда ping мониторинг NOT достаточен
Ping не ловит application failures
Хост пингается, но nginx вернул 500, database вышел из памяти, приложение зависло. Ping покажет всё OK, пользователи увидят ошибку.
Решение: используйте HTTP health check или TCP check сверху ping'а.
Ping не ловит service port failures
Машина online и пингается, но конкретный port закрыт. PostgreSQL упал, но Linux ядро работает. HTTP server отключён, но ICMP ещё отвечает. Ping не покажет эти failure'ы.
Firewall может блокировать ICMP
Многие corporate firewall'и блокируют ICMP для "security". Хост доступен, но ping returns timeout. Это даёт false positive failure.
ICMP packet loss как метрика
Что означает packet loss
0% packet loss: идеально, все пакеты дошли
< 1% packet loss: нормально для internet, может быть occasional drop
1-5% packet loss: заметный, signal деградации
5-10% packet loss: критичное, приложения notice это (TCP retransmit'ит)
10%+ packet loss: сеть basically broken, нужна диагностика
Что вызывает packet loss
Congestion (перегруженность сети): слишком много traffic'а, router's buffers overflow. Packet'ы drop'ятся.
Physical issues: bad cable, interference, dying ethernet interface
Misconfiguration: MTU mismatch, jumbo frames не совместимы
WiFi interference: если monitor по WiFi, packet loss вероятна
Routing issues: bad path, BGP flapping
Firewall блокирует ICMP: что делать
Диагностика
Если ping timeout но можете ssh на машину — ICMP заблокирована:
# From your machine
$ ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
Request timeout
Request timeout
# But SSH works
$ ssh user@1.2.3.4
Connected!
# Conclusion: Firewall блокирует ICMP, но разрешает TCP/22Решения
Вариант 1: Open ICMP в firewall
Попросите админа разрешить ICMP (Type 8 ECHO_REQUEST) входящий для monitor'а IP
Вариант 2: Use TCP/HTTP check вместо ping
Мониторьте TCP port (port 22 для SSH, или aplikace port) или HTTP endpoint
Вариант 3: Use internal monitoring
Deploy agent внутри network'а, он может пингать внутренние хосты даже если ICMP заблокирован снаружи
Jitter: переменная latency
Идеальная сеть: все ping'и отвечают в точно 12.0ms. Реальная сеть: некоторые 12.0ms, некоторые 12.5ms, иногда spike к 50ms.
Jitter: stddev (стандартное отклонение) в примере ping'а выше = 0.13ms. Это низкий jitter (хорошо).
High jitter: 0.13ms vs 5.0ms stddev означает что latency нестабильна. VoIP и video conference'и страдают при jitter.
Низкий jitter: предсказуемая latency, приложения могут планировать timeout'ы лучше.
Ping мониторинг в AtomPing
Создание ICMP check
Тип: ICMP (Ping)
Host: 1.2.3.4 или example.com
Timeout: 5 секунд (достаточно для internet ping'а)
Интервал: 60 секунд (ping каждый час или реже для экономии)
Регионы: выберите несколько для глобального покрытия
Packet count: обычно 4 packet'а на probe
Комбинирование ping с другими checks
Для production критичных сервисов — мониторьте несколькими методами:
ICMP Ping: infrastructure alive? (машина online, сеть работает)
TCP Check: service listening? (port открыт, process запущен)
HTTP Check: service healthy? (app отвечает, dependencies OK)
Heartbeat: jobs running? (background work happening)
Результаты:
✓ Ping, ✓ TCP, ✓ HTTP → всё хорошо
✓ Ping, ✓ TCP, ✗ HTTP → application crashed
✓ Ping, ✗ TCP, ✗ HTTP → service down (port closed)
✗ Ping, - TCP, - HTTP → machine not reachable (network problem)
TTL и traceroute диагностика
Ping показывает TTL в ответе. TTL (Time To Live) = сколько hop'ов пакет может сделать перед drop'ованием.
Linux: default TTL = 64
Windows: default TTL = 128
Cisco: default TTL = 255
Пример: Linux machine (TTL=64) sent пакет. Приходит ответ с TTL=60. Значит было 4 hop'а (64-60=4).
Диагностика: если TTL очень низкий или переменный — признак нестабильного routing'а.
Ping vs response time monitoring
Ping latency (ICMP round-trip) часто ниже, чем HTTP response time (application processing). Это нормально.
Ping latency: 12ms (просто возвращает packet, no processing)
TCP latency: 15ms (TCP handshake)
HTTP response: 150ms (HTTP overhead + app processing)
Вывод: ping = network baseline. HTTP = application performance. Разница показывает где bottleneck.
Типичные ошибки ping мониторинга
Ошибка 1: полагаться только на ping
Ping успешен, но приложение упало. Не достаточный мониторинг.
Ошибка 2: считать что ICMP заблокирована = сервис down
Firewall блокирует ICMP, сервис прекрасно работает. False positive alert.
Ошибка 3: мониторить cellular/WiFi сети ping'ом
WiFi packet loss естественна (5-10%), mobile networks тоже. Ping много false positives. Используйте HTTP check вместо ping.
Ошибка 4: игнорировать latency увеличение
Ping приходит в 50ms вместо обычных 10ms. Это сигнал, что сеть перегружена. Не ждите complete failure — это предупреждение.
Ping vs internal vs external monitoring
Ping может быть internal (dari within VPC) или external (from internet).
External ping: проверяет что машина доступна из интернета (важно для public facing services)
Internal ping: проверяет connectivity в VPC/network (важно для databases, cache)
Рекомендация: для production используйте оба — external ловит internet routing issues, internal ловит internal network problems
Checklist: ICMP ping monitoring
Цель: правильно ли определена? (infrastructure alive, не service-level)
Firewall: разрешена ли ICMP от monitor'а? Если нет — используйте TCP/HTTP check
Комбинация: ping + TCP + HTTP для defense-in-depth
Базовая latency: знаете ли normal ping time? (10ms? 100ms?)
Alert threshold: при какой latency alert'ировать? (2x normal?)
Интерпретация: правильно ли понимаете результаты (ping OK ≠ service здоров)
Связанные материалы
Complete Guide to Uptime Monitoring — overview всех check типов
TCP Port Monitoring — более детальный мониторинг сервисов
Response Time Monitoring — application latency tracking
Internal vs External Monitoring — coverage strategies
ICMP Check — в AtomPing
FAQ
What is ICMP ping monitoring?
ICMP ping monitoring sends ECHO_REQUEST packets to a target host and measures response time. If the host responds with ECHO_REPLY, it's reachable. Ping measures network latency (round-trip time), packet loss, and whether the host is accessible. Unlike HTTP or TCP checks (which test a specific service), ping checks if the entire host is reachable from the network perspective.
How does ICMP ping work?
Ping uses Internet Control Message Protocol (ICMP). Monitor sends ECHO_REQUEST packet (type 8) with a sequence number and timestamp. Target host receives it and immediately responds with ECHO_REPLY packet (type 0) containing the same data. Monitor measures round-trip time (latency). If no reply arrives within timeout (usually 3-5 seconds), the host is unreachable.
When is ICMP ping useful?
Ping checks infrastructure reachability: is the host powered on? Is the network path open? For bare metal servers, IoT devices, or routers without HTTP services, ping is the only available check. Ping also detects network degradation (packet loss, high latency). Not useful for detecting service-level failures (web server returns 500, database is out of memory) since ping only checks network layer.
Why do firewalls block ICMP ping?
Some systems block ICMP for security (prevent network reconnaissance). Others allow ping for diagnostics. Many cloud providers (AWS, Azure) allow outbound ping but block inbound to prevent abuse. If your ping check shows timeout but the host is up, firewall is likely blocking ICMP. Workaround: use TCP or HTTP check on a known port instead.
What's the difference between latency and packet loss in ping?
Latency (round-trip time) is how long the ping takes (milliseconds). Normal is <100ms local, <500ms intercontinental. Packet loss is percentage of packets that didn't return. 0% = all replies received. 10% = 1 in 10 packets lost. Both indicate network problems: high latency = congestion, packet loss = physical issues or overload.
How is ICMP ping different from TCP/HTTP monitoring?
ICMP ping checks if a host is reachable (network layer). TCP checks if a specific port accepts connections (transport layer). HTTP checks if a service responds correctly (application layer). A host can pass ping (reachable) but fail TCP (port closed), and pass TCP but fail HTTP (service not responding). Use ping for infrastructure, TCP for services, HTTP for applications.