Мониторинг связности из десяти городов мира: как собрать честную картину доступности

MAATRIX

Панель мониторинга зелёная, uptime показывает 99,98% — а в поддержку тем временем приходит письмо от клиента из другого региона: «у меня сайт не открывается уже час». Обе картины правдивы одновременно: мониторинг проверял доступность из того же дата-центра, где стоит сервер, а у клиента трафик шёл через провайдера, у которого в этот момент была проблема на маршруте. Зелёный чек с одной точки — это не картина доступности сайта, а картина доступности именно из этой точки, и разница между ними может стоить репутации и денег.

Почему мониторинг из одной точки создаёт ложное чувство благополучия

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

Если монитор стоит в том же дата-центре, что и сервер, он проверяет по сути localhost с сетевой точки зрения — путь состоит из одного внутреннего свитча. Он никогда не увидит деградацию на магистральном канале между регионами, блокировку диапазона IP у оператора связи, проблему на пиринговом стыке, из-за которой отваливается один сегмент аудитории, или сбой у крупного домашнего провайдера в стране, где живёт заметная часть пользователей. Тот же эффект — с мониторингом из офиса разработчиков: это тоже одна конкретная сеть со своими BGP-маршрутами, и если у команды канал быстрый, а у половины аудитории нет, ощущение «у нас всё летает» расходится с реальностью — обнаруживается это обычно по жалобам, а не по алерту.

Мониторинг из одной точки не бесполезен — он прекрасно ловит падение сервера и деградацию по CPU/памяти/диску. Но он отвечает только на вопрос «жив ли сервер», а не «доступен ли сервис пользователям из тех мест, где они реально находятся». Подменять один вопрос другим — источник ситуаций, когда панель зелёная, а бизнес теряет клиентов.

Собственные пробники: дешёвые VPS в разных регионах

Самый прямой способ получить честную multi-region картину — расставить несколько недорогих VPS в разных географических точках и гонять с них периодические проверки до целевого сервера, отправляя результат в центральную систему сбора.

Схема простая:

1. Арендуете несколько минимальных VPS в интересующих регионах — обычно достаточно 1 vCPU и 512 МБ-1 ГБ RAM.
2. На каждом ставите скрипт проверки — curl до HTTP-эндпоинта, ping или mtr до IP сервера, при необходимости DNS-резолв домена (чтобы ловить и проблемы с DNS-провайдером в регионе).
3. Скрипт запускается по cron и отправляет результат — код ответа, время выполнения, факт успеха — в центральную точку сбора.
4. Центральная система (тот же Uptime Kuma в режиме push-мониторов, отдельная база или лог-агрегатор) хранит историю и агрегирует: если из N точек отвечают все или почти все — сервис жив, если не отвечает одна-две — это другой сигнал.

Минимальный скрипт проверки на пробнике может выглядеть так:

#!/usr/bin/env bash
# probe.sh — запускается по cron раз в минуту
TARGET_URL="https://example.com/health"
PROBE_NAME="fra-1"
CENTRAL_ENDPOINT="https://monitor.example.internal/api/push"

START=$(date +%s%3N)
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "$TARGET_URL")
LATENCY=$(( $(date +%s%3N) - START ))

curl -s -X POST "$CENTRAL_ENDPOINT" \
  -H "Content-Type: application/json" \
  -d "{\"probe\":\"$PROBE_NAME\",\"code\":$HTTP_CODE,\"latency_ms\":$LATENCY,\"ts\":$(date +%s)}"

В crontab на пробнике: * * * * * /opt/probes/probe.sh >> /var/log/probe.log 2>&1.

Плюс подхода — полный контроль: вы сами решаете, откуда и что проверять (не только HTTP-код, но и содержимое ответа, заголовки, TLS-сертификат), с какой периодичностью и как долго хранить историю. Минус — эксплуатация: пробники сами могут упасть, и тишина от точки — это не «всё хорошо», а «пробник не смог отчитаться», другой сигнал, который легко перепутать с первым и заметить аварию не сразу.

Для большинства небольших и средних проектов хватает пяти-семи точек в разных регионах и у разных операторов — не обязательно гнаться за десятками, важнее разнообразие по сетям и географии, чем количество.

Готовые сервисы синтетического мониторинга: как это устроено

Синтетический мониторинг (synthetic monitoring) — общее название для класса сервисов, которые имитируют реального пользователя: с определённой периодичностью с серверов, разбросанных по десяткам локаций и у разных провайдеров, отправляют запрос к вашему адресу и фиксируют результат. Принцип схожий независимо от бренда:

• у сервиса своя сеть точек присутствия (probe locations) в разных странах и городах, часто у разных провайдеров специально ради сетевого разнообразия;
• вы регистрируете «монитор» — URL, порт или произвольный чек — и выбираете, из каких точек и с какой периодичностью его проверять;
• при недоступности из точки сервис либо сразу алертит, либо переспрашивает с других точек, чтобы отличить локальную проблему от глобальной, и эскалирует только после подтверждения;
• поверх базовой доступности часто есть многошаговые сценарии (логин, добавление в корзину), проверка SSL-сертификата на истечение, проверка содержимого страницы на ключевые слова.

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

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

Self-hosted инструменты: Prometheus blackbox exporter и Uptime Kuma

Если вы хотите держать всю систему под своим контролем и не платить внешнему сервису, два инструмента закрывают почти весь практический спектр задач.

Prometheus blackbox exporter — экспортер, который сам выполняет проверки (HTTP, HTTPS, TCP, ICMP, DNS) и отдаёт результат в формате метрик Prometheus. Для multi-region сценария разворачиваете экземпляр exporter'а на каждой пробной точке (том же дешёвом VPS в нужном регионе), а центральный Prometheus через remote_write или федерацию подтягивает метрики со всех точек в одну базу. Дальше — стандартный стек: Grafana для визуализации по регионам и Alertmanager для правил вида «из трёх и более точек подряд провал — критичный алерт, из одной — предупреждение».

Пример базового конфига проверки в blackbox exporter (blackbox.yml):

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: [200]
      method: GET

Дальше в scrape_configs центрального Prometheus targets указывают на https://example.com, а через relabel_configs запрос перенаправляется на локальный blackbox exporter (127.0.0.1:9115) — стандартный паттерн из документации exporter'а. Такая связка мощная, но требует реальной настройки — федерации между регионами, правил алертинга, хранения истории. Оправдана, если у вас уже есть Prometheus/Grafana для других метрик и вы расширяете его на multi-region доступность.

Uptime Kuma — заметно более простой self-hosted вариант с готовым веб-интерфейсом, без необходимости разбираться с PromQL и federation. Настоящей multi-region архитектуры с распределёнными пробниками у него нет из коробки, но есть режим push-мониторов: внешний скрипт (тот же curl-пробник с VPS в другом регионе) шлёт heartbeat на URL Uptime Kuma, и если heartbeat не пришёл вовремя — Kuma считает точку недоступной и алертит. Это тот же принцип, что и с собственными пробниками, только роль центральной системы берёт на себя готовая панель. Подробно про типы проверок Uptime Kuma и настройку интервалов и retries — в статье про настройку Uptime Kuma, общий обзор инструментов — в статье про инструменты мониторинга доступности сайта.

Держите в голове частую ошибку, опасную и для одноточечного, и для multi-region мониторинга: если центральная система сбора стоит на том же сервере, что и прод, при падении хоста замолчат оба сразу — алерта не будет именно тогда, когда он нужнее всего. Центральная система должна физически стоять отдельно от точек, за которыми наблюдает.

Как выбрать точки мониторинга: не «популярные города», а ваша аудитория

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

Практический порядок действий:

1. Посмотрите в аналитику, откуда реально приходит трафик — гео-разбивка в веб-аналитике или логах nginx по IP-диапазонам подскажет не только страны, но и конкретных операторов (по ASN обратного DNS или базам вроде MaxMind). Если 70% аудитории из двух-трёх стран, точки логично концентрировать там, а не распылять поровну по десяти городам ради картинки.
2. Учитывайте провайдера внутри страны, а не только страну. Крупная страна может состоять из сетевых сегментов, слабо связанных между собой — доступность у клиентов разных операторов может отличаться из-за разной связности с сетью сервера. Если критично, ставьте по одной точке у двух-трёх крупнейших операторов.
3. Не забывайте про мобильный трафик отдельно от домашнего — у мобильных операторов часто своя, отдельная связность, и проблема может проявляться только на мобильном сегменте.
4. Пересматривайте набор точек по мере роста аудитории — набор, актуальный для одного-двух регионов, устаревает при выходе на новые рынки, сверяйте с гео-статистикой раз в несколько месяцев.

Физическая близость точки мониторинга к серверу тоже ничего не гарантирует с точки зрения маршрута — соседний по карте город может идти к серверу другим сетевым путём, чем город на другом континенте, если у него более прямой пиринг. Наглядный разбор такого случая — в статье о сервере во Франкфурте, который оказался быстрее московского для клиентов из Москвы.

Зачем мониторить из «недружественных» с точки зрения маршрутизации точек

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

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

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

Как читать алерты: авария или проблема у конкретного провайдера

Главная практическая ценность multi-region мониторинга не в объёме данных, а в возможности правильно интерпретировать сигнал вместо паники по первому алерту.

Два принципиально разных сценария:

• Недоступность из всех или почти всех точек одновременно — скорее всего, реальная авария: упал сам сервер, приложение отдаёт 500-е, закончилось место на диске, истёк SSL-сертификат. Реагировать нужно немедленно.
• Недоступность из одной точки при доступности из остальных — с высокой вероятностью проблема на конкретном участке маршрута: деградация у провайдера, сбой пирингового стыка, локальная блокировка IP в конкретной стране. Сервер при этом жив и доступен для большинства пользователей.

Практическое правило, которое стоит закладывать сразу при настройке: критичный алерт (будить дежурного ночью) — только при недоступности из большинства точек одновременно или при недоступности из одной точки дольше разумного порога (скажем, 10-15 минут — число подбирается под задачу). Недоступность из одной точки в течение пары минут логичнее логировать без эскалации: единичные разрывы на конкретных маршрутах случаются регулярно и сами восстанавливаются, а будить человека на каждый такой случай — способ получить усталость от алертов, после которой перестают реагировать даже на настоящие аварии.

Полезная деталь для отсева случайных провалов — правило «N из M»: считать точку недоступной не после первого неудачного запроса, а после нескольких подряд неудач с короткими интервалами retry. Это отфильтровывает разовые сетевые всплески и оставляет только устойчивую деградацию, о которой стоит сообщать.

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

Частые вопросы