Синтетический мониторинг API: как проверять не только главную

Проверка главной страницы отвечает только на один вопрос: открывается ли https://example.com/. Для витринного сайта этого иногда достаточно, но для приложения, SaaS-сервиса, интернет-магазина или мобильного бэкенда главная может отдавать 200 OK, пока авторизация, оплата, поиск или выдача заказов уже не работают.

Синтетический мониторинг API решает эту проблему: сервис по расписанию выполняет заранее заданные HTTP-запросы к важным эндпоинтам и проверяет не только код ответа, но и содержимое. Например, что GET /api/health вернул 200, POST /api/login не упал с 500, а в JSON-ответе GET /api/products есть ключевое слово "items" или поле "status":"ok".

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

Что такое синтетический мониторинг API

Синтетический мониторинг — это проверка по заранее описанному сценарию. В отличие от RUM, который смотрит на реальные действия пользователей, синтетическая проверка сама имитирует запрос: открывает URL, отправляет метод GET, POST или PUT, добавляет заголовки, тело, токен, ждёт ответ и сравнивает его с ожиданиями.

Для API это обычно выглядит так: раз в минуту или несколько минут отправляется запрос на https://api.example.com/v1/status, проверяется HTTP-код (200, 204, иногда 401 или 403, если это ожидаемая реакция), время ответа сверяется с порогом, в теле ищется ключевое слово или JSON-поле, а при ошибке проверка повторяется и уходит уведомление.

Подробно разницу между синтетическим подходом и мониторингом реальных пользователей можно разобрать отдельно: см. материал что такое synthetic monitoring и чем он отличается от RUM. Для мониторинга API ключевая идея проста: вы проверяете не «сервер жив», а «контракт API выполняется».

Пример ручной проверки через curl:

curl -i https://api.example.com/v1/health

Если в ответе есть HTTP/2 200, тело {"status":"ok"} и нормальное время ответа — базовая проверка прошла. Сервис мониторинга делает примерно то же самое, только регулярно, из внешней сети и с уведомлениями.

Statuser, например, может проверять сайт или API с заданным интервалом и присылать уведомление о сбое. В случае API полезно настраивать не одну проверку «домен доступен», а несколько проверок на разные критичные маршруты.

Почему проверки главной страницы недостаточно

Главная страница часто живёт отдельно от API: она может быть закэширована CDN, отдаваться статикой из Nginx, лежать в другом контейнере или вообще загружаться из фронтенд-бандла, пока бэкенд недоступен.

Типичные ситуации, когда главная работает, а продукт сломан:

1) Упал отдельный API-сервис — фронтенд открывается, но запросы к api.example.com возвращают 502, 503 или 504. Пользователь видит интерфейс, но не может войти, оформить заказ или загрузить данные.

2) Сломалась база данных — GET / отдаёт HTML, потому что он статический, а GET /api/orders падает с 500. Внешне сайт «доступен», но бизнес-функция недоступна.

3) Ошибка в авторизации — страница логина открывается, но POST /api/login возвращает неверный формат, пустой токен или 401 для корректных тестовых данных.

4) Нарушился контракт ответа — код 200, но поле переименовали с items на data, мобильное приложение старой версии перестало разбирать ответ, а обычная проверка доступности ничего не заметила.

5) Проблема только в одном регионе или маршруте — сайт доступен из дата-центра провайдера, но API медленно отвечает из-за DNS, TLS, маршрутизации или блокировки на конкретном сетевом пути.

Мониторинг доступности главной страницы — это нижний слой: он показывает, что домен, DNS, TLS и веб-сервер в целом отвечают. Мониторинг API добавляет продуктовый слой — работают ли конкретные функции. Если нужна база по обычным проверкам сайта, можно начать с инструкции по проверке доступности сайта, а затем расширить её проверками эндпоинтов.

Какие эндпоинты стоит проверять

Не нужно превращать внешний мониторинг в полный набор автотестов: проверка сотен маршрутов каждую минуту даст только шум, нагрузку и сложное сопровождение. Лучше выбрать небольшое число контрольных точек, которые отражают здоровье продукта.

1) Технический health check — отдельный endpoint вроде GET /health, GET /ready или GET /api/status. Он должен быстро отвечать и показывать состояние ключевых зависимостей: приложения, базы, кэша, очереди, внешних сервисов. Подробнее о таких проверках — в статье health checks на практике.

Хороший health-ответ может выглядеть так:

{
  "status": "ok",
  "database": "ok",
  "redis": "ok",
  "version": "2026.02.1"
}

Для мониторинга достаточно проверять 200 OK и наличие "status":"ok" или "database":"ok".

2) Ключевой публичный endpoint — например, GET /api/products, GET /api/articles, GET /api/catalog. Он показывает, что API не просто жив, а отдаёт реальные данные. Здесь полезна проверка ключевого слова: "items", "products", "total".

3) Авторизация или получение токена — если для продукта критичен вход, можно проверять POST /api/login на тестовом пользователе. Такой сценарий требует аккуратности: отдельный тестовый аккаунт, ограничения прав, защита от блокировок и утечек.

4) Создание тестового объекта — иногда нужно проверять запись: POST /api/orders/test, POST /api/forms/submit, POST /api/webhooks/test. Лучше делать это через специальный тестовый маршрут или объект с признаком synthetic=true, чтобы не засорять аналитику и не запускать реальные бизнес-процессы.

5) Внешние интеграции — если сервис зависит от платёжного провайдера, доставки, CRM или SMS-шлюза, полезно проверять endpoint, который отражает готовность интеграции, но не создавать реальные платежи или SMS каждую минуту. Нужен безопасный sandbox-сценарий.

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

Что именно проверять в ответе

Слабая проверка API выглядит так: «URL вернул любой 2xx». Это лучше, чем ничего, но не защищает от многих реальных поломок. Надёжная проверка смотрит на несколько признаков.

1) HTTP-код — задайте ожидаемый статус: обычно 200, 201, 204. Иногда корректным результатом будет 401, если endpoint специально проверяется без токена. Главное — ожидаемый код должен быть осознанным, а не «любой успешный». Коды 500, 502, 503, 504 почти всегда требуют реакции, но и 404, 403, 429 могут быть инцидентом, если раньше endpoint отвечал иначе. Освежить значения статусов поможет справочник всех кодов ответов HTTP.

2) Тело ответа — проверяйте ключевые слова и JSON-поля, особенно когда API возвращает 200, но внутри ошибка:

{
  "status": "error",
  "message": "database unavailable"
}

Формально HTTP-код успешный, но мониторинг должен считать такой ответ сбоем. Подробнее о том, как правильно искать такие признаки, — в следующем разделе.

3) Время ответа — задайте таймаут и порог деградации. Например, если GET /api/products обычно отвечает за сотни миллисекунд, ответ за 8–10 секунд может быть проблемой даже при 200 OK. Для API latency часто важнее самого факта доступности: пользователь не отличает «не работает» от «работает через 20 секунд».

4) Заголовки — иногда нужно проверять Content-Type: application/json, Cache-Control, CORS-заголовки, наличие Strict-Transport-Security или корректный редирект. Это особенно полезно для публичных API и браузерных клиентов.

5) Размер и структура — слишком маленький ответ может означать пустую заглушку, слишком большой — ошибочный дамп или HTML-страницу вместо JSON. Минимальная проверка структуры спасает от ситуации, когда балансировщик вернул красивую HTML-ошибку с кодом 200.

Смысл не в том, чтобы повторить контрактные тесты, а в том, чтобы отловить явные нарушения, которые пользователь заметит сразу.

Как настраивать запросы: методы, заголовки, тело

Мониторинг API должен уметь повторить настоящий HTTP-запрос. Для простых endpoints хватит URL и метода GET, но многие проверки требуют заголовков и тела.

1) Метод — выбирайте тот же метод, который использует клиент: GET, POST, PUT, PATCH, DELETE. Не проверяйте GET /api/login, если реальная авторизация работает через POST /api/login.

2) Заголовки — чаще всего нужны:

• Accept: application/json;
• Content-Type: application/json;
• Authorization: Bearer <token>;
• X-Api-Key: <key>;
• User-Agent: synthetic-monitor;
• пользовательские заголовки вроде X-Tenant-ID.

3) Тело запроса — для POST и PUT используйте минимальный безопасный payload, например:

{
  "email": "synthetic@example.com",
  "password": "test-password"
}

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

4) Редиректы — для API редиректы обычно подозрительны. Если https://api.example.com/v1/orders внезапно начал отдавать 301 на страницу логина или HTML-заглушку, это может сломать клиентов. Решите заранее: следовать редиректам или считать их ошибкой.

5) TLS и домен — проверка должна идти по тому же публичному адресу, что и реальные клиенты. Запрос напрямую на IP или внутренний hostname не покажет проблем с DNS, сертификатом, SNI, CDN или reverse proxy.

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

Пример проверки с заголовком и телом:

curl -i \
  -X POST https://api.example.com/v1/login \
  -H "Content-Type: application/json" \
  -H "User-Agent: synthetic-monitor" \
  -d '{"email":"synthetic@example.com","password":"test-password"}'

Если такой запрос вручную работает, его можно переносить в систему мониторинга.

Проверка ключевых слов и JSON-полей

Проверка ключевого слова — простой, но сильный механизм. Она отвечает на вопрос: «В ответе есть то, что мы ожидали увидеть?»

Для текстового ответа можно искать строку OK, ready, pong. Для JSON — фрагмент "status":"ok" или имя обязательного поля. Но есть нюансы.

1) Проверяйте стабильные признаки — не ищите текущее время, случайный идентификатор, количество товаров или текст, который меняется при локализации. Лучше искать постоянное поле: "status", "items", "version", "authenticated".

2) Не полагайтесь только на наличие слова — если API возвращает {"status":"error","message":"not ok"}, простая проверка слова ok может ошибиться. Лучше искать точный фрагмент "status":"ok" или использовать JSONPath, если инструмент его поддерживает.

3) Учитывайте форматирование — JSON может быть минифицированным или отформатированным с пробелами. Строка "status":"ok" не совпадёт с "status": "ok", если проверка слишком буквальная. В таком случае лучше искать "status" и "ok" вместе или использовать проверку JSON-поля.

4) Проверяйте отрицательные признаки — иногда полезно считать ошибкой наличие слов error, exception, traceback, maintenance, Service Unavailable. Но такая проверка должна быть дополнительной: слово error может встретиться и в документации, и в поле errorCount.

5) Разделяйте проверки доступности и бизнес-логики — если endpoint иногда легально возвращает пустой массив, не надо алертить на отсутствие товаров. Лучше проверять структуру: "items":[] допустимо, отсутствие "items" — нет.

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

Аутентификация, тестовые данные и безопасность

Мониторинг API часто упирается в доступ. Открытые endpoints проверять просто, но реальная ценность обычно находится за авторизацией. Здесь важно не сделать мониторинг источником риска.

1) Создайте отдельного synthetic-пользователя — не используйте аккаунт администратора или реального сотрудника. У тестового пользователя должны быть минимальные права: только чтение или доступ к специальному тестовому пространству.

2) Ограничьте окружение — если возможно, заведите отдельный tenant, организацию или проект synthetic-monitoring. Все созданные объекты должны легко фильтроваться и удаляться.

3) Не запускайте реальные действия — проверка не должна отправлять письма клиентам, списывать деньги, создавать настоящие заказы, менять цены или публиковать контент. Для таких сценариев нужен sandbox или специальный dry-run endpoint.

4) Следите за рейт-лимитами — мониторинг может сам попасть под 429 Too Many Requests, особенно если проверок много или интервал слишком короткий. Для synthetic-клиента можно настроить отдельный лимит, но не стоит полностью обходить защиту: иногда полезно знать, что ваш API начал ошибочно ограничивать собственных клиентов.

5) Ротируйте токены — API-ключи для мониторинга должны иметь срок жизни, понятного владельца и процедуру замены. Если токен протухнет, мониторинг начнёт присылать ложные алерты. Если токен утечёт, ущерб должен быть ограничен.

6) Не логируйте секреты — проверьте, что запросы мониторинга не попадают в логи вместе с Authorization, паролями и приватными payload. В логах лучше оставлять ID проверки, endpoint, код ответа и время.

Если API использует OAuth2, JWT или API keys, выберите самый простой стабильный способ для synthetic-проверок. Полный пользовательский login-flow полезен, но он более хрупкий: капча, MFA, блокировки и антифрод могут создавать лишний шум.

Интервалы, таймауты и борьба с ложными срабатываниями

Слишком редкие проверки поздно обнаруживают сбой, слишком частые — создают нагрузку, шум и больше false positive. Интервал нужно выбирать по критичности endpoint и цене простоя.

1) Критичные публичные endpoints — health, авторизация, оформление заказа, получение конфигурации приложения. Их обычно проверяют чаще: например, раз в минуту или несколько минут.

2) Второстепенные endpoints — справочники, поиск, отчёты, интеграции, которые не блокируют весь продукт. Их можно проверять реже.

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

4) Таймауты — задавайте реалистичный предел. Если API обычно отвечает за 300 мс, таймаут 60 секунд сделает мониторинг бесполезным для latency-проблем. Но слишком жёсткий таймаут может алертить на нормальные сетевые колебания.

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

Подробнее про выбор частоты есть отдельный материал как выбрать интервал проверки сайта. А если мониторинг часто «кричит зря», полезно разобраться, что такое false positive в мониторинге.

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

Как выстроить практическую схему мониторинга API

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

1) Составьте карту критичных сценариев — вход, получение данных, создание заказа, оплата, загрузка файлов, вебхуки, интеграции. Напротив каждого сценария укажите endpoint, метод, ожидаемый код, ключевое слово и допустимое время ответа.

2) Разделите проверки по слоям — инфраструктура (/health), продуктовые чтения (/api/products), продуктовые записи (/api/orders/test), внешние зависимости (/api/integrations/status). Так проще понять масштаб инцидента: сломан весь API или только один сценарий.

3) Задайте понятные имена — не Check 17, а API health, Login API, Catalog API, Order dry-run. Название должно попадать в уведомление, чтобы дежурный сразу понимал, куда смотреть.

4) Настройте разные уровни реакции — падение health и логина требует срочного алерта. Медленный справочник можно отправить в менее критичный канал. Не все проверки одинаково важны.

5) Привяжите проверки к релизам — при изменении контракта API обновляйте synthetic-проверки вместе с кодом. Если переименовали поле, изменили путь или добавили обязательный заголовок, мониторинг должен быть частью checklist релиза.

6) Документируйте ожидаемое поведение — рядом с проверкой должно быть понятно: почему ожидается именно 200, почему ищем "status":"ok", какой таймаут считается нормальным, кто владелец endpoint.

7) Сверяйте с внутренними метриками — внешний мониторинг API отвечает на вопрос «видит ли проблему клиент». Метрики приложения показывают причины: latency, ошибки, насыщение ресурсов, зависимость от базы или очереди. Для HTTP API полезно использовать RED-подход: rate, errors, duration. Подробно он разобран в статье мониторинг HTTP API: RED-метрики, latency и error budget.

Итоговая схема может быть очень простой:

• GET /health — ожидаем 200, ищем "status":"ok", таймаут 2 секунды;
• GET /api/products — ожидаем 200, ищем "items", таймаут 3 секунды;
• POST /api/login — ожидаем 200, ищем "token", таймаут 3 секунды;
• POST /api/orders/dry-run — ожидаем 201, ищем "synthetic":true, таймаут 5 секунд;
• GET /api/integrations/payments/status — ожидаем 200, ищем "available":true.

Это уже намного полезнее, чем проверка одной главной страницы.

Типичные ошибки при мониторинге API

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

1) Проверять только 200 OK — API может вернуть успешный код с ошибкой внутри тела. Добавляйте проверку ключевого слова или JSON-поля.

2) Использовать нестабильные данные — если проверка зависит от товара, который редактор может удалить, она рано или поздно сломается. Для synthetic-сценариев нужны стабильные тестовые объекты.

3) Делать опасные POST-запросы без dry-run — мониторинг не должен создавать реальные заказы, отправлять письма и менять состояние пользователей в обход тестового контура.

4) Игнорировать latency — «ответил за 25 секунд» для пользователя часто равно «не работает». Проверяйте время ответа, а не только код.

5) Не учитывать авторизацию — открытый health может быть зелёным, пока авторизованные методы падают. Если продукт требует входа, минимум одна проверка должна проходить авторизованный путь.

6) Слишком широко алертить — если каждая небольшая деградация будит всю команду, уведомления начнут игнорировать. Разделяйте критичные и некритичные проверки, используйте подтверждение сбоя и разумные пороги.

7) Не обновлять проверки после релиза — endpoint переехал, формат ответа изменился, токен истёк, а мониторинг остался прежним. В результате он либо ломается зря, либо перестаёт отражать реальное состояние API.

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

FAQ

Что лучше проверять: /health или реальные endpoints?
И то и другое. /health показывает техническое состояние сервиса, а реальные endpoints проверяют пользовательские сценарии и контракт API.

Нужно ли мониторить каждый метод API?
Нет. Выберите критичные маршруты: авторизация, основные чтения, важные записи, интеграции. Полный контракт лучше проверять автотестами в CI.

Можно ли проверять API без авторизации?
Можно, если у вас есть публичные endpoints. Но для закрытого продукта этого мало: хотя бы одна проверка должна проходить авторизованный сценарий.

Что считать сбоем: только 5xx или медленный ответ тоже?
Медленный ответ тоже может быть сбоем. Для API стоит задавать порог latency и алертить, если endpoint стабильно выходит за допустимое время.