Мониторинг узла без задержек и флапов — базовый слой, а не опция

Мониторинг узла без задержек и флапов — базовый слой, а не опция

Если узел «жив» по ICMP, это не значит, что он пригоден для работы. Анализ показал, что проблема часто сидит в разрыве между доступностью и качеством ответа: пакеты доходят, но с ростом RTT, джиттера или потерь прикладной трафик уже деградирует.

Для проверки держат в одном контуре несколько метрик:
— reachability: ICMP, TCP handshake, L7 healthcheck;
— latency: p50/p95/p99, а не только среднее;
— loss: отдельно по направлению и по типу трафика;
— saturation: загрузка интерфейса, очередь, дропы на NIC и в ядре.

Рассмотрим архитектурный срез по данному узлу. Локальный агент видит то, чего не видит внешний probe: очередь на интерфейсе, ошибки драйвера, рост retransmit, всплески conntrack и CPU softirq. Внешний мониторинг, наоборот, нужен для проверки маршрута и реальной достижимости из соседнего сегмента или другой площадки.

Рекомендуется обратить внимание на метрику «доступен, но медленнее порога». Это хороший триггер для раннего предупреждения: узел ещё отвечает, но уже не выдерживает целевую задержку. Такие события лучше алертить отдельно, чем ждать полного отказа.

Если в дашборде есть только зеленый статус, это не мониторинг, а индикация. Рабочая схема — разделять «не отвечает», «отвечает с деградацией» и «отвечает в пределах SLO»: тогда инцидент видно до того, как его заметят пользователи.