Почему мониторинг API — это другое#

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

Пример: страница оформления грузится (сайт жив ✅), но платёжный API падает (сайт сломан ❌). Клиенты не могут оформить покупку. Выручка останавливается.

Мониторинг API ловит такие невидимые сбои.

Что нужно мониторить

Платёжные шлюзы (Stripe, PayPal, Square)
Эндпоинты аутентификации (login/logout)
Data API (списки товаров, данные пользователей)
Webhooks (входящие данные от третьих сторон)
Эндпоинты поиска
API загрузки медиа

Коды HTTP в API#

API используют HTTP-коды иначе, чем сайты:

Сайт:

200 OK: страница загружается
500 Server Error: сайт сломан

API:

200 OK: запрос успешен
400 Bad Request: клиент прислал неверные данные
401 Unauthorized: аутентификация не прошла
403 Forbidden: нет прав
404 Not Found: эндпоинт не существует
429 Too Many Requests: rate limit
500+ Server Error: бэкенд сломан

Ключевое отличие: API может вернуть 200 OK с ошибкой в JSON-теле.

Пример:

{
  "status": 200,
  "success": false,
  "error": "Payment processing failed"
}

HTTP говорит «OK», а API на деле сломан. Базовый uptime-мониторинг это упускает.

Настройка мониторинга API#

Шаг 1. Определите критичные эндпоинты#

Перечислите каждый критичный для бизнеса эндпоинт:

/api/auth/login (без него пользователи не входят)
/api/payments/create (без него нет оформления)
/api/users/profile (без него крашится приложение)
/webhooks/stripe (без него платежи не фиксируются)

Шаг 2. Решите, как валидировать ответ#

Для каждого эндпоинта решите, что значит «жив»:

Базово (HTTP-статус):

200 или 201 = OK

Промежуточно (статус + время отклика):

200 И ответ <1 секунды

Продвинуто (статус + содержимое тела):

200 И тело содержит ожидаемые данные

Шаг 3. Настройте инструмент#

В Nova Uptime:

Добавьте домен: https://api.yourdomain.com
Каждый критичный эндпоинт — отдельным монитором:
- /api/auth/login
- /api/payments/create
- и т. д.
Настройте валидацию тела при наличии
Пороги алертов (2 неуспешные проверки подряд)

Продвинуто: валидация тела ответа

Часть эндпоинтов требует конкретного формата ответа.

Пример: эндпоинт создания платежа

Ожидаемый ответ:

{
  "success": true,
  "payment_id": "pay_12345",
  "amount": 99.99
}

Настройка мониторинга:

Проверять, что в ответе есть "success": true
Если нет — эндпоинт «сломан», даже если HTTP 200

Email Health Checker от Nova Uptime валидирует тело ответа — тот же принцип применим к API-мониторингу.

Токены аутентификации в API-мониторинге#

Большинство API требуют аутентификации. Чтобы их мониторить:

Вариант 1: тестовый API-ключ

Сгенерируйте отдельный тестовый ключ для мониторинга
Используйте его во всех запросах мониторинга
Только read-доступ (нельзя менять данные)
Подключите ключ в инструменте мониторинга

Вариант 2: публичный эндпоинт

У некоторых API есть неаутентифицированные эндпоинты (health, status)
Мониторьте их
Пример: GET /api/health (публично, без авторизации)

Мониторинг вебхуков

Вебхуки сложнее. Они входящие (вы их получаете, а не шлёте).

Мониторьте эндпоинт-приёмник:

Пример: Stripe шлёт POST на https://yourdomain.com/webhooks/stripe

Как мониторить:

Создайте тестовый отправитель вебхуков (триггерите вручную)
Проверьте, что эндпоинт принимает и отвечает 200
Проверьте логи, что вебхук был обработан

Или используйте синтетический мониторинг:

Поставьте синтетический POST на эндпоинт вебхука
Включите тестовый payload
Убедитесь, что принят и обработан

Мониторинг времени отклика

API — это не только up/down, это ещё и скорость.

Медленный API = сломанный API (с точки зрения пользователя).

Пороги времени отклика:

Эндпоинт аутентификации: <200 мс
Платёжный эндпоинт: <500 мс
Эндпоинт поиска: <1000 мс (сложнее)

Если эндпоинт отвечает 5 секунд, даже когда «работает», — пользователи получают таймауты и уходят.

Учёт rate limit#

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

Проблема: ваш мониторинг шлёт проверку каждую минуту. На 1 000 мониторов это 1 000 запросов в минуту. Если API ограничивает 100/мин, мониторинг блокируется.

Решение:

Отдельный API-ключ для мониторинга (с высоким лимитом)
Или реже проверки (раз в 5 минут вместо 1)
Или внутренний /health, не подпадающий под rate-limit

Типичные ошибки

Ошибка 1. Мониторинг продакшена через разрушительные операции#

Не мониторьте:

POST /api/users/delete    ← удаляет пользователей при каждой проверке
POST /api/billing/charge  ← списывает деньги при каждой проверке

Мониторьте read-only:

GET /api/users/{id}
GET /api/health

Ошибка 2. Аутентификация в URL#

Не делайте:

GET /api/endpoint?auth_token=SECRET

Это утаскивает секреты в логи. Используйте заголовки:

Authorization: Bearer SECRET_TOKEN

Ошибка 3. Не тестировать эндпоинты вебхуков#

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

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

Мониторинг зависимостей API#

Ваш API может зависеть от внешних сервисов:

БД (если она лежит — лежит и API)
Очередь сообщений (Redis, RabbitMQ)
Кэш (Memcached)
Внешние API (Stripe, Twilio)

Мониторьте их отдельно:

Health-эндпоинт БД
Эндпоинт состояния кэша
Страницу статуса стороннего API

Алерты на сбои API#

Когда мониторинг ловит сбой:

Алерт должен содержать:

Какой эндпоинт упал
Что за сбой (таймаут vs 500)
Когда начался
Недавние изменения (если есть)

Серьёзность:

Critical: платёжный/auth API (пользователи заблокированы)
High: search/data API (пользователи раздражены)
Medium: analytics/logging (ошибки видны пользователям)

Мониторинг API в Nova Uptime#

Nova Uptime мониторит uptime API наравне с uptime сайтов:

Добавьте API-домен: https://api.yourdomain.com
Настройте мониторинг эндпоинтов
Получайте алерты по email/Slack
Просматривайте историю инцидентов и время отклика
Автоматические скриншоты сбоев (для отладки)

Плюс мониторинг email health — если ваш API шлёт транзакционные письма, Nova Uptime автоматически проверяет SPF/DKIM/DMARC на той же панели.

Итог

Перечислите критичные эндпоинты
Определите, что значит «жив» для каждого (статус, время отклика, тело)
Поставьте мониторинг на каждый
Задайте пороги времени отклика
Мониторьте зависимости (БД, кэш, сторонние)
Регулярно тестируйте вебхуки
Алертите на сбои сразу

Запустите мониторинг своего API сегодня: API-мониторинг Nova Uptime. На одной панели — uptime + email health. 🚀

Uptime-мониторинг для API: мониторинг эндпоинтов и вебхуков