Для большинства продакшн-хостов хорошая отправная точка — интервал проверки 30–60 секунд, таймаут примерно в 2–3 раза больше обычного времени приема-передачи (RTT), алерт после 2–3 сбоев подряд и подтверждение как минимум из двух локаций мониторинга. Установите предупреждение по задержке на уровне 1,5–2x от измеренной базовой линии, критический алерт — на 3x, а по потере пакетов — примерно от 2% (предупреждение) и 10% (критический уровень). Затем настройте значения под тип хоста.
Скорость обнаружения определяют три параметра
Время обнаружения сбоя примерно равно интервалу, умноженному на требуемое число сбоев подряд, плюс таймаут. При интервале 30 секунд и трех обязательных сбоях вы узнаете о полном отказе примерно через 90 секунд. Если сократить интервал вдвое, это время тоже сократится вдвое, но у кратковременных сбоев станет больше шансов вызвать ложный алерт.
Практичные значения по умолчанию:
- Интервал: 30 секунд для критичной инфраструктуры, 60 секунд для обычных серверов, 2–5 минут для низкоприоритетных устройств или устройств с ограниченной пропускной способностью.
- Таймаут: 2–3x от p95 RTT, но не меньше примерно 1 секунды.
- Сбоев подряд: 2 для критичных хостов, 3 для большинства остальных. Одна потерянная проба редко означает инцидент.
Используйте кворум из нескольких локаций
Сбой, зафиксированный только из одной точки, часто говорит о проблеме рядом с зондом, а не у цели. Требование согласованности нескольких локаций — самый эффективный фильтр ложных срабатываний. Распространенное правило: «хост недоступен, если сбой фиксируют минимум 2 из 3 локаций», или большинство, если локаций пять и больше. Сбой в одном регионе при этом может вызывать алерт пониженной важности — он помогает выявить проблемы маршрутизации или пиринга.
Задавайте пороги задержки относительно базовой линии
Фиксированные значения в миллисекундах редко подходят всем хостам. Измерьте базовую линию минимум за неделю, используя p50 для типичного поведения и p95 для нормального разброса, и настройте алерты на отклонения:
- Предупреждение: устойчивая задержка на уровне 1,5–2x от базовой линии в течение нескольких проверок подряд.
- Критический уровень: 3x от базовой линии или абсолютный потолок, при котором приложение перестает нормально работать, например 250 мс для интерактивного API-бэкенда.
Сочетайте оба подхода: относительный порог поймает скачок LAN-канала с 5 до 20 мс, а абсолютный потолок защитит пользователей, даже если сама базовая линия постепенно растет.
Потеря пакетов и джиттер
Потеря пакетов часто становится первым признаком деградирующего канала или перегруженного интерфейса. Оценивайте ее в скользящем окне, например по последним 10–20 пробам, а не по каждой проверке отдельно. Типичные стартовые значения — выше 2% для предупреждения и выше 10% для критического уровня; в LAN любая устойчивая потеря заслуживает расследования.
Джиттер — разброс между последовательными значениями RTT — важнее всего для голоса, видео и API реального времени. Для таких нагрузок распространенный порог предупреждения — около 30 мс. Для веб- или пакетного трафика джиттер лучше рассматривать как диагностический сигнал, а не как триггер алерта.
Стартовые пороги по типам хостов
| Тип хоста | Интервал | Таймаут | Сбоев | Задержка предупр. / крит. | Потери предупр. / крит. |
|---|---|---|---|---|---|
| Сервер в LAN | 30s | 1s | 2 | 2x / 3x от базовой (напр. 5 / 10 мс) | >0,5% / >2% |
| Облачная VM, тот же регион | 30s | 1s | 2–3 | 2x / 3x от базовой (напр. 20 / 40 мс) | >1% / >5% |
| Межконтинентальный | 60s | 3s | 3 | 1,5x / 2x от базовой или 300 мс абсолютно | >2% / >10% |
| Edge- / IoT-устройство | 2–5 min | 5s | 3–5 | 2x / 3x от базовой | >5% / >15% |
В первые недели замените примерные значения собственными базовыми линиями.
Настройка для снижения ложных срабатываний
- Разбирайте каждый алерт в течение двух недель. Классифицируйте его как реальный, кратковременный или вызванный стороной зонда.
- Увеличивайте число сбоев подряд, прежде чем удлинять интервал, чтобы отфильтровать единичные потери проб.
- Добавьте TCP-проверку к ICMP. Некоторые сети ограничивают ICMP по частоте или понижают его приоритет; TCP-проба на известный порт подтверждает, действительно ли сервис доступен.
- Пересчитывайте базовые линии после изменений инфраструктуры, например переезда в другой регион или установки новых межсетевых экранов.
- Разделите маршрутизацию предупреждений и критических алертов. Отправляйте предупреждения в канал Slack или Microsoft Teams, а критические состояния — по email, в Telegram или через webhook.
Ping-мониторинг UpScanX выполняет проверки ICMP, TCP и UDP из более чем 15 локаций по всему миру, что упрощает настройку кворума, а AI-отчеты выявляют постепенные аномалии задержки. Более общие рекомендации по настройке — в нашей статье о лучших практиках ping-мониторинга.
Ключевые выводы
- Время обнаружения примерно равно интервалу, умноженному на число сбоев, плюс таймаут; настраивайте все три параметра вместе.
- Требуйте кворума из нескольких локаций, прежде чем объявлять хост недоступным.
- Настраивайте алерты по задержке относительно базовой линии, подкрепляя их абсолютным потолком.
- Используйте скользящие окна для потери пакетов, а алерты по джиттеру оставьте для трафика реального времени.
- Пересматривайте пороги после первых двух недель и после каждого изменения в сети.