Тестируйте приложение отовсюду, где есть ваши пользователи.

Мониторинг снаружи собственной сети

Синтетические проверки крошечные и частые, поэтому расходы определяются числом точек наблюдения, а не трафиком:

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

Статика там, где вы в белом списке, резидентка там, где важна география

Путаница между этими двумя путями и есть обычная причина отказов. Белому списку нужны неподвижные адреса, географии нужны подвижные:

Python: два пути, один монитор

STATIC = "http://login:password@198.51.100.20:50100"

def geo(country):
    return f"http://login_c_{country}:password@proxy.sotaproxy.com:10000"

def check(endpoint):
    if endpoint.whitelisted:
        return probe(endpoint, proxy=STATIC, timeout=10)
    return [probe(endpoint, proxy=geo(c), timeout=30) for c in endpoint.markets]

• Проверкам по белому списку ставьте таймаут короче, чем гео-проверкам. Статический маршрут быстрый, и медленный ответ там это настоящий сигнал, а резидентный медленнее по природе.
• Поднимайте тревогу по шаблону, а не по одной неудачной попытке. Один резидентный хоп может отвалиться по причинам, не связанным с вашим сервисом.
• Держите минимум две страны наблюдения для всего, что видят клиенты. Один регион, погасший при зелёных остальных, это самый быстрый способ заметить проблему маршрутизации.
• Включите автопродление на статических адресах. Адрес мониторинга, тихо истёкший, делает дашборд зелёным по неверной причине.

Как мониторинг вам врёт