Ваш сервер работает. Логи чистые. Grafana зелёная. Но клиент в Берлине пишет в поддержку: "Ваш сайт не открывается уже 20 минут". Вы проверяете — у вас всё работает. Потому что вы проверяете из того же датацентра, где стоит сервер. А у клиента DNS-резолвер вернул старый IP после вчерашней миграции. Или CDN edge в Европе отдаёт 502. Или Cloudflare WAF заблокировал подсеть его провайдера.
Synthetic monitoring решает именно эту проблему: проверяет ваш сервис снаружи, из тех же точек, откуда заходят реальные пользователи. Регулярно, автоматически, 24/7 — включая 3 часа ночи в воскресенье, когда на сайте ноль трафика и RUM ничего не покажет.
Synthetic vs RUM: два подхода к мониторингу
Мониторинг веб-приложений делится на два фундаментально разных подхода. Понимание разницы между ними — ключ к выбору правильной стратегии.
Synthetic monitoring (активный)
Мониторинговая система сама генерирует трафик. Из внешних точек (агентов) отправляются HTTP-запросы к вашему сайту или API по расписанию — каждые 30 секунд, каждую минуту, каждые 5 минут. Запрос идёт по тому же маршруту, что и запрос реального пользователя: DNS-резолвинг → TCP-подключение → TLS handshake → HTTP-запрос → получение ответа.
Результат каждой проверки записывается: status code, response time, TTFB, размер ответа, содержимое (если настроена валидация). Если что-то не так — система инцидентов реагирует немедленно.
Real User Monitoring (пассивный)
JavaScript-сниппет в браузере собирает данные о реальных пользователях: время загрузки страницы, LCP, FID, CLS, ошибки JavaScript, неудавшиеся fetch-запросы. Данные агрегируются и показывают реальную картину пользовательского опыта.
RUM даёт бесценную информацию о том, как ваш сайт работает в реальных условиях: на медленном 3G в Индии, на старом iPhone SE, через корпоративный прокси. Но у RUM есть фундаментальное ограничение: нет пользователей — нет данных.
Synthetic мониторинг отвечает на вопрос: "Работает ли мой сервис прямо сейчас, из этих конкретных точек, по этим конкретным критериям?" Ответ — да/нет, с точным временем и деталями.
RUM отвечает на вопрос: "Какой опыт получают реальные пользователи?" Ответ — статистическое распределение по перцентилям, устройствам, регионам, страницам.
Когда synthetic monitoring незаменим
Synthetic monitoring — не альтернатива RUM, а другой инструмент для других задач. Есть ситуации, где только synthetic работает:
Обнаружение outage в нерабочее время
B2B SaaS в 2 часа ночи по местному времени имеет околонулевой трафик. Если сервер упадёт в 2:00 и поднимется в 7:00 — RUM не зафиксирует ничего. Пять часов downtime, невидимых для passive monitoring. Synthetic check обнаружит проблему через 30-60 секунд, независимо от трафика.
Базовая линия производительности
RUM-данные зашумлены: каждый пользователь — на своём устройстве, со своей сетью, со своими расширениями браузера. Тяжело отличить деградацию сервера от "у 10 пользователей медленный WiFi". Synthetic check делает одинаковый запрос из одинаковой точки каждую минуту — идеальная baseline. Если response time вырос на 200ms, причина — на стороне сервера, а не клиента.
Мониторинг API и бэкенд-сервисов
RUM живёт в браузере. API-endpoint, webhook-receiver, microservice health check — всё это невидимо для RUM. API monitoring — целиком территория synthetic: отправить запрос, проверить ответ, замерить время.
Pre-launch и staging
Staging-среда не имеет реальных пользователей по определению. Но вам нужно знать, что она работает, прежде чем деплоить в production. Synthetic мониторинг staging — стандартная практика в CI/CD.
SLA compliance и uptime reporting
SLA требует объективных, измеримых данных: availability за месяц, количество инцидентов, среднее время восстановления. RUM не даёт этих метрик — он не знает, когда сайт "лежал", потому что в это время просто не было данных. Synthetic monitoring проверяет непрерывно и даёт точные цифры uptime.
Типы synthetic checks
"Synthetic monitoring" — зонтичный термин. Под ним скрываются разные типы проверок, каждый для своей задачи.
HTTP/HTTPS check. Базовый тип. Отправляет GET или POST запрос, проверяет status code, response time, содержимое ответа. Подходит для сайтов, API, health check endpoints. В AtomPing — основной тип мониторинга.
DNS check. Проверяет, что домен резолвится в правильный IP. Ловит проблемы на уровне DNS до того, как они станут HTTP-ошибками. DNS monitoring — отдельный тип проверки, работающий параллельно с HTTP.
TCP/Port check. Проверяет, что порт открыт и принимает соединения. Используется для баз данных, SMTP-серверов, кастомных TCP-сервисов. Port monitoring не зависит от HTTP-протокола.
SSL/TLS check. Валидирует сертификат: срок действия, chain, hostname match. TLS monitoring предупреждает за 30 дней до истечения — критичная проверка, потому что expired SSL = полный отказ.
ICMP/Ping check. Проверяет, отвечает ли хост на ICMP echo. Самый низкоуровневый тип — если ping не проходит, проблема на уровне сети или хост отключён. Ping monitoring полезен для серверов, роутеров, сетевого оборудования.
Keyword check. HTTP-запрос + проверка, что ответ содержит (или не содержит) определённый текст. Ловит сценарии "200 OK, но внутри — страница ошибки". Keyword monitoring — защита от тихих сбоев.
Heartbeat check. Инвертированный synthetic: не мониторинг проверяет ваш сервис, а ваш cron job пингует мониторинг. Если ping не пришёл вовремя — алерт. Dead man's switch для scheduled tasks.
Multi-region: зачем проверять из нескольких точек
Проверка из одной точки — лучше, чем ничего. Но она порождает ложные алерты: сетевой jitter между probe и вашим сервером, DNS-кэш probe, maintenance у хостинга probe — всё это выглядит как "сайт лежит", хотя он работает.
Multi-region мониторинг решает это фундаментально. Вместо одного агента — 11, распределённых по Европе. Каждый проверяет независимо. Результаты сравниваются:
1 из 11 агентов видит DOWN → локальная сетевая проблема, результат подавляется. Никакого алерта.
8 из 11 агентов видят DOWN → реальный инцидент, подтверждённый кворумом. Алерт отправляется немедленно.
Все 11 агентов видят DOWN → глобальный outage. Инцидент с максимальным приоритетом.
Побочный бонус: multi-region данные показывают реальную картину latency по географии. Если response time из Франкфурта — 80ms, а из Хельсинки — 340ms, у вас проблема с маршрутизацией или CDN-конфигурацией в Северной Европе.
Что проверять: за пределами "сайт отвечает"
Примитивный synthetic monitoring проверяет: "вернул ли сервер 200 OK?". Этого недостаточно. Сервер может вернуть 200 с пустым JSON, 200 с HTML-страницей ошибки nginx, 200 с кэшированными данными трёхдневной давности.
Продвинутый synthetic мониторинг валидирует:
Status code. Не просто "2xx", а конкретный код. 200 для GET, 201 для POST, 204 для DELETE. Если вместо 200 приходит 301 — кто-то поменял routing.
Содержимое ответа. Keyword check на ключевое слово ("Dashboard", "status":"ok") или JSON path assertion ($.data.length > 0). Ловит тихие сбои, невидимые по status code.
Response time. Абсолютный порог (>500ms = warning, >2s = critical) и деградация относительно baseline. Response time tracking записывает историю для анализа трендов.
Headers. Content-Type, Cache-Control, CORS-заголовки. Пропавший CORS-header ломает весь фронтенд при исправном API.
TLS-валидность. Параллельно с HTTP-проверкой — валидация сертификата. Если до истечения меньше 30 дней — уведомление.
Настройка synthetic мониторинга: практический чеклист
Минимальная конфигурация, которая покрывает 95% потребностей среднего SaaS-продукта:
1. HTTP check на главную страницу. URL: ваш domain. Интервал: 1 минута. Ожидаемый код: 200. Keyword: название продукта или уникальный DOM-элемент. Регионы: 3+.
2. HTTP check на API health. URL: /api/health или /health/ready. Интервал: 30 секунд. Ожидаемый код: 200. Keyword: "status":"healthy". Это ваш canary — первый индикатор проблем с бэкендом.
3. DNS check. Проверка, что домен резолвится в правильный IP. Интервал: 5 минут. Ловит проблемы на уровне DNS, которые HTTP check обнаружит с задержкой.
4. SSL/TLS check. Проверка валидности сертификата. Алерт за 30 дней до истечения. Занимает 30 секунд на настройку, предотвращает один из самых дорогих типов downtime.
5. Heartbeat для cron jobs. Каждый критичный scheduled task — бэкапы, sync, cleanup — добавьте curl на heartbeat URL в конец скрипта.
6. Alerting. Slack, Telegram, email — на ваш выбор. Правило: hard incident после 2-3 последовательных проверок с проблемой, подтверждённых кворумом из нескольких регионов. Это убирает 99% ложных алертов.
Synthetic monitoring для разных типов сервисов
E-commerce
Критичные endpoints: главная, каталог, корзина, checkout, payment callback. Минимально — HTTP checks на каждый с keyword validation (проверить, что на странице каталога есть товары, а не пустой список). Payment callback endpoint нуждается в самой частой проверке — 30 секунд, потому что его недоступность = потеря транзакций.
SaaS API
Health check endpoint с deep проверкой (БД, Redis, внешние зависимости). Отдельные checks на auth endpoint и core CRUD operations. JSON path assertions на ответы API. Response time мониторинг c порогами, привязанными к вашему SLO.
Marketing site / Landing pages
HTTP check + keyword validation (проверить, что CTA-кнопка или ключевой текст на месте). DNS check — обязательно, потому что marketing sites часто используют CDN с CNAME, и проблемы с DNS-записями ломают весь трафик. SSL check — для сертификатов, которые обновляются через CDN-провайдера.
Microservices
Outside-in подход: начните с внешнего gateway, потом добавляйте health checks отдельных сервисов. Каждый сервис — свой /health/ready. Если gateway здоров, а конкретный сервис нет — вы точно знаете, куда смотреть, вместо того чтобы перебирать 15 логов.
Ошибки, которые все совершают
Мониторинг только из одного региона. Экономит 5 минут на настройке, стоит часы ложных алертов. Три региона — абсолютный минимум для кворума.
Проверка только homepage. Главная страница на CDN может работать при мёртвом бэкенде. Мониторьте API-endpoints, authenticated pages, критичные user flows.
Нет валидации содержимого. Status code 200 ≠ "всё работает". Добавьте keyword check — одна строка текста, которую вы ожидаете увидеть в ответе.
Слишком агрессивные пороги. Алерт на каждый единичный таймаут = alert fatigue через неделю. Используйте hard incident thresholds (2-3 последовательных сбоя) и quorum confirmation.
Забытый мониторинг SSL. Сертификат истекает — и вместо одного алерта за 30 дней вы получаете полный outage в выходные. SSL мониторинг — 30 секунд на настройку, которые спасают от ночных инцидентов.
FAQ
What is synthetic monitoring?
Synthetic monitoring uses scripted transactions to simulate user interactions with your website or API from external locations. Unlike real user monitoring (RUM), which passively collects data from actual visitors, synthetic monitoring actively sends requests at regular intervals — even when no real users are online. This makes it ideal for catching outages at 3 AM or during low-traffic periods.
What is the difference between synthetic monitoring and real user monitoring?
Synthetic monitoring proactively tests your site using scripted checks from known locations on a fixed schedule. RUM passively collects performance data from real browsers as actual users interact with your site. Synthetic gives you consistent baselines and instant outage detection. RUM gives you real-world user experience data with all the variability of different devices, networks, and locations.
Do I need both synthetic and real user monitoring?
For most teams, synthetic monitoring covers 90% of monitoring needs — especially if you're a B2B SaaS or API-driven product. RUM adds value when you have high consumer traffic with diverse devices and need to understand real user experience. Start with synthetic, add RUM when you have the traffic volume to make it statistically meaningful.
How often should synthetic checks run?
Critical endpoints (login, payment, API health): every 30-60 seconds. Important pages (dashboard, product listings): every 1-3 minutes. Secondary pages (blog, docs, about): every 5-10 minutes. Match frequency to business impact — if a 2-minute outage costs you thousands, check every 30 seconds.
Can synthetic monitoring test APIs and not just websites?
Yes. In fact, API monitoring is one of the strongest use cases for synthetic monitoring. You can validate status codes, check response body content with JSON path assertions, verify headers, measure latency, and test authenticated endpoints — all on a fixed schedule from multiple regions.
Does synthetic monitoring affect my server performance?
Negligibly. A synthetic check is a single HTTP request every 30-60 seconds — far less than one real user browsing your site. Even with 10 monitoring regions checking every 30 seconds, that's 20 requests per minute. For comparison, a single user loading a modern SPA generates 30-50 requests in a page load.