Чтобы отслеживать потерю пакетов и задержку в разных регионах, запускайте одинаковые проверки одних и тех же целей из нескольких точек, которые соответствуют географии ваших пользователей, и сравнивайте каждый регион с его собственным базовым уровнем, а не с единым глобальным значением. Отслеживайте перцентили и джиттер вместо средних, отправляйте достаточно пакетов за проверку, чтобы потери измерялись осмысленно, и поднимайте оповещение только тогда, когда картина подтверждается несколькими точками или сохраняется во времени.
Выбирайте регионы проверок по географии пользователей
Начинайте с данных о трафике, а не с карты. Если большинство сессий приходит из Западной Европы, с восточного побережья США и из Юго-Восточной Азии, это и есть ваши основные регионы проверок; добавьте второстепенные регионы там, где действуют договорные SLA. Используйте как минимум две точки на каждый ключевой рынок, чтобы локальная проблема одной точки никогда не выглядела как региональный сбой.
Помните, что точки проверки в дата-центрах видят более чистые маршруты, чем домашние или мобильные подключения, поэтому воспринимайте их данные как лучший возможный сценарий.
Задавайте базовые уровни для каждого региона с учётом физики
В оптоволокне свет проходит примерно 200 км за миллисекунду, поэтому каждые 100 км кабеля добавляют около 1 мс ко времени приёма-передачи ещё до любых очередей. Реальные маршруты длиннее прямой линии, поэтому типичные диапазоны выглядят так:
| Маршрут | Типичный RTT |
|---|---|
| Один город или один облачный регион | 1–5 мс |
| В пределах Западной Европы | 10–30 мс |
| Восток США — запад США | 60–75 мс |
| Восток США — Западная Европа | 75–95 мс |
| Западная Европа — Сингапур | 150–190 мс |
| Западная Европа — Сидней | 250–300 мс |
Значение 180 мс от Сингапура до сервера во Франкфурте — норма; то же значение из Амстердама — уже инцидент. Стройте базовые уровни как минимум по недельным данным для каждого региона и оповещайте об отклонениях, например когда p95 превышает семидневную норму на 30–50 процентов.
Измеряйте потери и задержку статистически корректно
Проверка из трёх ping-запросов может показать только 0, 33, 67 или 100 процентов потерь — слишком грубо, чтобы заметить потери на уровне 1–2 процентов, которые уже снижают пропускную способность TCP. Практические рекомендации:
- Отправляйте 10–20 пакетов за проверку или объединяйте несколько проверок в скользящее пятиминутное окно перед расчётом потерь.
- Показывайте p50 для типичного опыта и p95 для «хвоста», на который жалуются пользователи. Средние значения скрывают всплески.
- Отслеживайте джиттер — разброс между последовательными измерениями RTT. Джиттер выше примерно 20–30 мс ухудшает трафик реального времени, даже когда задержка выглядит нормальной.
- Сочетайте ICMP с TCP-проверками порта сервиса: некоторые маршрутизаторы ограничивают ICMP и показывают потери, которых прикладной трафик никогда не испытывает.
Ping-мониторинг UpScanX поддерживает проверки по ICMP, TCP и UDP из более чем 15 точек по всему миру, поэтому вы можете запускать одинаковые проверки в каждом регионе и сравнивать их рядом.
Сравнивайте регионы, чтобы локализовать причину
Сравнение регионов — самый быстрый способ понять, где возникла проблема:
- Ухудшение во всех регионах одновременно: проблема, вероятно, на стороне origin-сервера или его вышестоящего провайдера.
- Ухудшение в одном регионе, остальные стабильны: подозревайте транзитного провайдера, точку пиринга или регионального интернет-провайдера на этом маршруте.
- В одном регионе ухудшаются только эндпоинты за CDN: проверьте edge-узел, обслуживающий этот регион, а не ваш origin.
- Потери видны только по ICMP: скорее всего, это ограничение скорости на промежуточном маршрутизаторе, а не реальное влияние на пользователей.
Когда регион деградирует, запустите traceroute или MTR из этой точки и сравните маршрут с маршрутом из здорового региона. Ищите место, где задержка резко растёт и остаётся высокой на всех последующих хопах; всплеск на одном промежуточном хопе, который исчезает дальше по маршруту, обычно означает лишь то, что маршрутизатор понижает приоритет ответов. Прикладывайте трассировки к инциденту, чтобы показать провайдеру, где именно нарушился маршрут.
Оповещайте по кворуму, отчитывайтесь по регионам
Оповещения по одной точке создают шум. Поднимайте оповещение, когда как минимум две точки в регионе или большинство регионов превышают порог в двух-трёх проверках подряд. Используйте предупреждение для одного затронутого рынка и критическое оповещение, когда сходятся несколько регионов, с доставкой в Slack, Microsoft Teams, по электронной почте, в Telegram или через вебхук.
В отчётах публикуйте по каждому региону задержку p95, потери и джиттер рядом с показателем доступности. ИИ-отчёты UpScanX выявляют аномалии, коррелируют связанные оповещения и рассылают плановые сводки по электронной почте. Подробнее о RTT и настройке порогов читайте в нашем руководстве по мониторингу сетевой задержки.
Ключевые выводы
- Размещайте точки проверки там, где находятся ваши пользователи, — минимум две на каждый ключевой рынок.
- Задавайте базовый уровень для каждого региона отдельно: расстояние устанавливает физический нижний предел задержки.
- Отправляйте достаточно пакетов за проверку и отслеживайте p95 и джиттер вместо средних.
- Сравнивайте регионы и трассируйте маршруты, чтобы разделять проблемы origin-сервера, интернет-провайдера и CDN.
- Оповещайте по кворуму и длительности, а метрики публикуйте по регионам.