Привет, Хабр!

Я делаю Valpero — uptime-мониторинг с проверками из 10 регионов мира. Когда я только собирал probe-сеть, я был уверен, что 10 географических точек это автоматически и 10 точек отказа. Открыл недавно AS-картину своего же парка — и обнаружил, что из 10 узлов у меня реально 4 разных автономных системы. 7 из 10 probe сидят на одном и том же AS209847.

Ниже расскажу о том, как сейчас выглядит сеть, какие провайдеры реально стоят, как я измерял AS-разнесённость, и что я планирую с этим делать.

В конце таблица с IP-адресами всех узлов и их AS — повторить расклад на своём проекте можно за вечер.

Где сейчас живут probe-узлы

Десять узлов разбросаны по миру:

Helsinki, Finland Hetzner Cloud HEL1 AS24940 core Vienna, Austria Castlegem SRL AS8218 probe Secaucus NJ, USA Castlegem Inc. AS29838 probe Bucharest, Romania Castlegem SRL AS8218 probe Reykjavík, Iceland WorkTitans B.V. AS209847 probe Rome, Italy Weiss Hosting Group AS209847 probe Tokyo, Japan WorkTitans B.V. AS209847 probe São Paulo, Brazil WorkTitans B.V. AS209847 probe Wellington, New Zealand WorkTitans B.V. AS209847 probe Almaty, Kazakhstan WorkTitans B.V. AS209847 probe

Helsinki — core-нода (там стоит control plane: Postgres, Redis, FastAPI, аггрегатор результатов). Остальные девять — probe, которые держат WebSocket до core и шлют результаты проверок.

География — 4 континента, 10 стран. На бумаге выглядит как солидная сеть. На деле — посмотрим на AS-колонку.

Почему AS важнее географии

Когда фейлится конкретный IP, причина обычно одна из этих:

  • сам VPS упал (kernel panic, OOM, hypervisor maintenance)

  • network upstream провайдера упал

  • BGP-leak / route flap на пути до целевого сайта

Первое — изолированное событие. Второе и третье — корреляция по провайдеру (а точнее по AS, потому что AS это и есть «у кого этот IP арендован»).

Если у меня 6 probe-узлов в одной AS, и эта AS словила сетевую проблему — упадут все 6 одновременно. Quorum-логика на серверной стороне увидит «6 регионов из 10 видят сайт down» и откроет инцидент. Хотя сайт работает, и виноват один-единственный сетевой апстрим у моего провайдера.

Это не теоретическая проблема. У меня уже случалось похожее раньше: одна AS дала пакет потерь на 90 секунд, и сразу 6 моих probe-узлов сообщили о падении одного и того же целевого сайта. Quorum-алгоритм сработал «честно» — большинство регионов видят down — и open’нул incident. Я разбудился, проверил сайт, он работал.

Это false-positive не от сети целевого сайта, а от моей собственной.

AS-разнесённость моей сети

Раскладка по AS:

AS24940 Hetzner Cloud 1 nodes (Helsinki — core) AS8218 Castlegem SRL 2 nodes (Vienna, Bucharest) AS29838 Castlegem Inc. 1 nodes (Secaucus) AS209847 WorkTitans/Weiss 6 nodes (Reykjavík, Rome, Tokyo, São Paulo, Wellington, Almaty)

То есть из 10 узлов:

  • 6 на AS209847 — одна и та же autonomous system, разные локации, но одна сетевая ответственность

  • 2 на AS8218 (Castlegem SRL — европейское юрлицо)

  • 1 на AS29838 (Castlegem Inc. — американское юрлицо, но компания та же)

  • 1 на AS24940 (Hetzner — это core, не probe)

Получается, что для probe-сети реально 3 независимых AS, а не 10. Если AS209847 уйдёт в маршрутизационные проблемы — у меня вырубит 60% probe-сети.

Объяснение почему так вышло банальное — WorkTitans и Weiss выкупили IP-блоки у одного и того же оптового провайдера, и сами клиентам продают «локацию X», но физически их сеть это та же одна AS с разными PoP’ами. Это распространённая модель у мелких VPS-провайдеров: один upstream, много географических точек.

Когда я заказывал «Reykjavík», «Tokyo», «São Paulo» через интерфейс одного и того же провайдера, я просто не подумал что они все будут на одной AS.

Как я это узнал

Простой Python-скрипт. Для каждого probe-узла берём его IP и резолвим в AS через WHOIS / IP-info API:

import requests

def probe_as(ip: str) -> tuple[int, str]: “”“Return (asn, owner_name) for an IPv4 address.”“” r = requests.get(f"https://ipinfo.io/{ip}/json", timeout=10).json() org = r.get(“org”, “”) # “AS24940 Hetzner Online GmbH” if org.startswith(“AS”): asn, _, name = org.partition(" ") return int(asn[2:]), name return 0, org

PROBES = [ (“helsinki”, “204.168.163.111”), (“vienna”, “185.75.241.186”), (“secaucus”, “162.254.85.68”), (“bucharest”, “162.254.84.95”), (“reykjavik”, “45.83.21.41”), (“rome”, “194.165.59.100”), (“tokyo”, “5.253.41.37”), (“sao-paulo”, “45.82.245.91”), (“wellington”, “5.180.22.3”), (“almaty”, “45.159.250.188”), ]

from collections import Counter asns = Counter() for name, ip in PROBES: asn, owner = probe_as(ip) print(f"{name:<12} AS{asn:<7} {owner}") asns[asn] += 1

print(“\nDistribution:”) for asn, count in asns.most_common(): print(f" AS{asn}: {count} nodes")

Выхлоп — та таблица что выше. 6 на AS209847 — это звонок, что моя сеть менее устойчива чем я думал.

Что планирую с этим делать

Не паника — система работает, инцидентов с массовым выпадением AS209847 пока не было уровня catastrophic. Но три вещи в roadmap:

  1. Заменить минимум 3 узла на других AS. Tokyo и São Paulo планирую перенести на местных провайдеров (Vultr или DigitalOcean), Wellington — на NZ-местного хостера. После этого распределение будет: 6 AS на 10 probe вместо 3 AS на 10 probe.

  2. Зафиксировать в quorum-логике учёт AS. Сейчас quorum-алгоритм просто считает регионы. Хочу добавить веса по AS: если 6 узлов на одной AS все фейлят, это считается за 1.5 «голоса», а не за 6. Тогда single-AS outage не сможет перевесить голос остальной сети.

  3. Алёрт «AS-correlation detected» в дашборде. Если падение совпало с тем что 80%+ failed узлов на одной AS — incident помечается как «возможно false-positive по нашей вине», и оператор может бесплатно ре-провизионить узлы у других провайдеров.

Бенчмарк по latency (для интереса)

Хоть это и не основной фокус — стоимость latency-проверок с probe до core по континентам:

Probe → Core (Helsinki): Vienna p50 = 38 ms p99 = 65 ms Bucharest p50 = 52 ms p99 = 81 ms Reykjavík p50 = 49 ms p99 = 78 ms Rome p50 = 58 ms p99 = 89 ms Secaucus p50 = 95 ms p99 = 138 ms São Paulo p50 = 195 ms p99 = 280 ms Tokyo p50 = 235 ms p99 = 312 ms Wellington p50 = 285 ms p99 = 365 ms Almaty p50 = 165 ms p99 = 245 ms

Это RTT для WebSocket-ping’а. Для самого probe-проверки (HTTP-запрос с probe на целевой сайт) latency между probe и core не важна — она влияет только на доставку результата, а не на сам replay. Поэтому high-latency Wellington-узел нормально работает.

Что я понял

Probe-сеть из «10 регионов» это просто маркетинг, пока вы не проверили AS-разнесённость. Реально у меня сейчас 3 AS на 10 узлов. Это меньше, чем у Pingdom с их 100+ PoP, где разнесённость по AS — главное value proposition.

Если строишь свою сеть мониторинга, с самого начала держи в Excel или просто в Markdown табличку с колонкой ASN. И не покупай узлы у одного провайдера только потому что у него удобный интерфейс. Закажи у 6-7 разных, даже если придётся 7 раз вводить карту — потому что один общий backbone это одна точка отказа на всю сеть.

Конкретно у меня впереди — миграция 3-4 узлов на другие AS и quorum-логика с учётом AS-весов. Когда сделаю, напишу follow-up.

Ссылки

  • valpero.com — мой uptime-мониторинг где это всё крутится. Free план 1 монитор, 2 региона, без карты.