RIPE Atlas и публичные пробы: меряем доступность своего сервера из сотни точек мира

MAATRIX

Пользователь пишет в поддержку: «у нас в стране сайт не открывается уже второй день». У вас с двух личных VPS всё отвечает нормально, ping и traceroute чистые — и возникает соблазн списать жалобу на локальную проблему у конкретного человека. Но у вас нет ни одной точки измерения в его стране, а значит и объективных данных против его слов тоже нет. Здесь на помощь приходят публичные распределённые измерительные сети — сервисы, которые дают запустить ping, traceroute или DNS-запрос к вашему серверу с сотен реальных точек по всему миру, а не только с тех двух-трёх, что арендовали вы сами.

Что такое распределённые измерительные сети и при чём тут RIPE Atlas

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

Самый известный проект такого рода — RIPE Atlas, некоммерческая инициатива RIPE NCC (регионального интернет-регистратора для Европы, Ближнего Востока и части Центральной Азии). Публично известно, что у RIPE Atlas тысячи активных зондов по всему миру, у разных провайдеров и в разных странах — точное число, доступные типы измерений и правила участия меняются со временем, поэтому здесь сознательно не называю конкретных цифр: перед тем как полагаться на проект в работе, откройте официальную документацию atlas.ripe.net и посмотрите текущее состояние и условия использования самостоятельно.

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

Как устроены зонды: что ставит волонтёр и что получает

Волонтёр, который хочет присоединиться к такой сети, обычно получает (или покупает по символической цене — конкретные условия проверяйте в документации проекта) небольшое аппаратное устройство размером с флешку или роутер, которое подключается к его домашней или офисной сети и работает в фоне, не мешая обычному трафику. У RIPE Atlas такие устройства называются зондами (probes), а более мощная и предсказуемая по доступности разновидность, которая обычно размещается в дата-центрах на серверном оборудовании, — якорями (anchors).

Зонд сам не решает, что и когда измерять, — он выполняет команды из центральной системы и отправляет результат обратно. Владелец зонда получает взамен «кредиты» за то, что зонд онлайн и работает, — их можно тратить на собственные измерения (детали начисления смотрите в актуальной документации). А вы как сторонний пользователь можете заказывать измерения через чужие зонды в рамках доступного вам лимита — в случае RIPE Atlas платформа в целом открыта, но конкретные условия доступа, регистрации и лимитов нужно смотреть на официальном сайте, а не полагаться на пересказ из статьи в интернете, включая эту.

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

Какие измерения можно запускать: ping, traceroute, DNS и не только

Базовый набор измерений, который поддерживают такие сети, обычно включает классические сетевые инструменты, знакомые любому, кто разбирался с диагностикой связности:

• Ping — проверка базовой доступности и задержки (RTT) до цели.
• Traceroute — построение маршрута от зонда до цели по хопам, аналогично тому, что делает mtr или traceroute локально; про то, как читать колонки в выводе такого инструмента, есть отдельная статья про чтение вывода mtr.
• DNS-запросы — проверка, что резолвится ваш домен именно с точки зрения этого зонда, и совпадает ли ответ с ожидаемым (полезно при работе с geo-DNS и CDN, где ответ намеренно разный в разных регионах).
• Часто доступны и более специфичные типы — проверка SSL/TLS-сертификата, NTP, HTTP-запрос к URL. Полный актуальный список типов измерений, их параметров и ограничений смотрите в документации конкретного проекта — он может со временем расширяться или меняться.

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

Зачем это владельцу сервера: объективная картина вместо пары ограниченных точек

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

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

Отдельная ценность — сами зонды сидят у реальных операторов, включая небольших региональных провайдеров, у которых вы никогда не арендовали бы VPS ради одного измерения. Именно у таких провайдеров чаще всего и возникают локальные проблемы связности, не видные ни с крупного облачного провайдера, ни с вашего рабочего канала.

Чем это отличается от собственного мониторинга на арендованных VPS

Оба подхода — свои VPS-пробники в разных регионах и публичная измерительная сеть — решают смежную задачу, но по-разному, и выбор между ними (или их сочетание) зависит от того, что вам важнее: контроль или охват. Про то, как строится классический multi-region мониторинг на собственных VPS и через синтетический мониторинг, подробно разобрано в статье про мониторинг связности из десяти городов — здесь же коротко сравним оба варианта именно в контексте RIPE Atlas и подобных проектов.

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

Квоты и кредиты: за широкий охват платите частотой измерений

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

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

Практический вывод простой: не рассчитывайте настроить через такую сеть постоянный alerting-мониторинг с ежеминутной проверкой из сотни точек — квоты для этого обычно не хватит, да и не для этого сеть создавалась. А для разовой или периодической диагностики конкретного вопроса кредитов обычно хватает с запасом, особенно если не гнаться за максимальным числом зондов в каждом измерении, а брать разумную выборку под задачу — скажем, десяток-другой зондов в интересующей стране, а не все доступные там сразу.

Практический сценарий: жалобы из конкретной страны — проверка вместо догадок

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

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

1. Зарегистрируйтесь на платформе (для RIPE Atlas это ripe.net / atlas.ripe.net) и ознакомьтесь с актуальными условиями использования — какие измерения доступны без собственного зонда, какой стартовый лимит кредитов, какие есть ограничения на новый аккаунт. Это может отличаться от того, что было полгода назад, поэтому не полагайтесь на чужие пересказы, включая эту статью.
2. Создайте измерение, указав в качестве цели адрес или домен вашего сервера, а в качестве источников — зонды именно в нужной стране или у конкретного провайдера, если платформа позволяет фильтровать по такому признаку. Для первичной диагностики обычно достаточно ping и traceroute — DNS и остальные типы добавляйте по мере необходимости.
3. Запустите измерение и дождитесь результатов от выбранных зондов. Если платформа предоставляет CLI-инструменты или API (у RIPE Atlas такие есть, и это может быть удобнее интерфейса в браузере при повторяющихся задачах) — используйте их для автоматизации, но для разового случая обычно хватает и веб-интерфейса.
4. Сравните результат по зондам. Если проблема отвечает не у всех зондов в регионе одинаково, а конкретно у зондов определённого провайдера — вероятная причина локализована именно на этом участке: проблема на стороне конкретного оператора, а не у вас в целом. Если не отвечает вообще ни один зонд из региона — это уже сигнал в сторону более широкой блокировки или магистральной проблемы, а не единичного случая у одного пользователя.
5. Сопоставьте с traceroute от зонда. Если ping не проходит, а traceroute обрывается на определённом хопе (или до определённой границы сети) сразу у нескольких зондов одного провайдера — это довольно сильный аргумент в пользу проблемы именно на этом участке маршрута, а не на вашем сервере: остальной мир при этом может отвечать нормально.

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

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

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