Мониторинг узла должен ловить не только падение, но и деградацию задержки

Мониторинг узла должен ловить не только падение, но и деградацию задержки

Доступность в сети часто проверяют слишком грубо: есть ответ — значит всё в порядке. Для узлов этого недостаточно. Узел может отвечать, но уже терять пакеты, наращивать очередь, уходить в джиттер или давать рост RTT до порога, где прикладной сервис начинает сбоить.

Рассматривать стоит три слоя метрик:
— reachability: ICMP, TCP connect, health endpoint;
— latency: p50/p95/p99 по маршруту и на самом узле;
— loss and jitter: потери, разброс задержки, повторные передачи.
Если контролировать только первый слой, инцидент будет виден слишком поздно.

Анализ показал, что полезнее связывать метрики в одну картину: рост задержки без потери доступности часто указывает на перегрузку интерфейса, проблемы с очередями, ошибки на канале или деградацию upstream-пути. Рекомендуется обращать внимание на корреляцию между RTT, retransmits, load average и состоянием сетевого интерфейса. Это позволяет отделить сетевой дефект от проблем приложения.

Отдельно важно проверять сами точки измерения: один probe изнутри DC и один с внешней стороны дают разную картину. Для устойчивой диагностики нужны несколько источников и одинаковые интервалы опроса, иначе краткие провалы будут выглядеть как шум.

Если узел отвечает, но задержка растёт, считать его здоровым нельзя: сначала проверяем транспорт, затем очередь и только потом прикладной уровень.