Что такое мониторинг API и зачем он нужен

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

Минимальная проверка контролирует соединение, timeout и HTTP-код. Более содержательная дополнительно проверяет JSON или другую часть ответа. Это важно, потому что 200 OK говорит об успешном выполнении HTTP-запроса, но не гарантирует корректность бизнес-данных.

Что именно проверяет мониторинг API

Полезно разделить несколько уровней.

Сетевая доступность

Удалось ли установить соединение с адресом и портом.

HTTP-уровень

Вернулся ли ответ вовремя и соответствует ли статус ожидаемому. Для типичного health endpoint ожидается 2xx, но конкретный критерий зависит от контракта.

Содержимое ответа

Для JSON API можно проверить наличие или значение важных полей. Например, сервис может вернуть:

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

с ошибочно выставленным 200 OK. Мониторинг только HTTP-кода посчитает запрос успешным, хотя бизнес-смысл ответа говорит об обратном.

Время ответа

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

Чем мониторинг API отличается от обычного мониторинга сайта

HTTP-механика похожа, но критерии API обычно строже.

Для публичной страницы иногда достаточно получить ожидаемый статус. API чаще требует:

• конкретного HTTP-метода;
• заголовков;
• авторизации;
• payload;
• проверки JSON;
• более строгого timeout;
• понимания допустимых кодов ответа.

Например, GET / может быть исправен, пока POST /api/orders не работает из-за проблем с БД.

Почему HTTP 200 недостаточно

Согласно HTTP semantics, 200 OK означает, что запрос успешно выполнен на уровне протокола с учётом используемого метода. Но разработчик API может допустить ошибку и вернуть 200 вместе с собственным полем error.

Кроме того, структура ответа может измениться так, что клиент перестанет её понимать, хотя статус останется успешным.

Поэтому для критичного API полезно контролировать контрактные признаки ответа, а не только статус.

Какие endpoint стоит мониторить

Health endpoint

Подходит для базового контроля, если реализован осмысленно. Плохой вариант — /health, который всегда отвечает 200, не проверяя ничего важного.

Критичные read endpoint

Например, получение каталога, профиля или конфигурации.

Критичные write endpoint

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

Внешние интеграции

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

Как проверить API вручную через curl

Базовый GET:

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

Только HTTP-код:

curl -sS -o /dev/null -w '%{http_code}\n' https://api.example.com/health

С ограничением времени:

curl --max-time 5 -i https://api.example.com/health

С Bearer token:

curl -i \
  -H 'Authorization: Bearer <token>' \
  https://api.example.com/private/health

Не вставляйте production-токены в публичные команды, документацию или скриншоты.

Как выбрать критерий успешной проверки

Начните с вопроса: «Какой минимальный ответ доказывает, что эта функция работает?»

Для одного endpoint это может быть:

HTTP 200 + ответ менее 2 секунд

Для другого:

HTTP 200 + JSON поле status = "ok"

Для третьего допустим 204 No Content.

Нет универсального правила «всегда ждать 200» — критерий должен соответствовать API-контракту.

Какой timeout выбрать

Timeout должен быть больше нормального времени ответа, но достаточно мал, чтобы быстро фиксировать явное зависание.

Если обычный endpoint отвечает за 100–200 мс, timeout в 30 секунд может слишком поздно обнаруживать проблему. Если операция по контракту занимает несколько секунд, лимит в одну секунду даст ложные срабатывания.

Правильный способ — сначала измерить реальное распределение времени ответа, учесть допустимый пользовательский предел и затем выбрать threshold.

Как часто проверять API

Частота определяется критичностью. Чем реже проверки, тем больше интервал между реальным началом проблемы и её обнаружением.

Для критичного production API несколько минут могут быть слишком большим окном. Для второстепенной интеграции нет смысла создавать ненужную нагрузку проверкой каждую секунду.

Мониторинговый endpoint должен быть лёгким и безопасным для регулярных запросов.

Авторизованный API

Если реальный пользовательский маршрут требует авторизации, проверка полностью публичного /health не гарантирует, что authentication flow работает.

Но хранение токенов в системе мониторинга требует аккуратности:

• используйте минимально необходимые права;
• отдельные технические учётные данные;
• не используйте персональный token разработчика;
• продумайте ротацию;
• не помещайте секрет в URL query string без необходимости.

Проверка JSON

Рассмотрим ответ:

{
  "service": "payments",
  "status": "ok",
  "version": "2026.08"
}

Если критерием исправности является status = ok, монитор должен проверять именно это условие. Наличие поля version может быть полезно для диагностики, но не обязательно должно влиять на статус проверки.

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

Что делать при ошибке API

1. Зафиксировать URL, метод, статус и время.
2. Повторить безопасный запрос вручную.
3. Определить, проблема постоянная или периодическая.
4. Проверить application logs.
5. Проверить БД, очередь и внешние зависимости.
6. Сравнить с последним релизом.
7. Проверить latency и timeout.
8. После исправления подтвердить восстановление с внешней точки.

Как мониторинг API помогает при инциденте

Автоматическая проверка даёт временную линию: когда endpoint последний раз работал, когда начались ошибки и когда сервис восстановился. Это существенно полезнее сообщения пользователя «кажется, API иногда не работает».

В UpWatch HTTP-монитор можно использовать для контроля endpoint и HTTP-условий, а JSON-проверку — когда важно валидировать содержимое ответа. Тип проверки выбирается по реальному контракту API, а не ради самого наличия мониторинга.

Что не должен делать мониторинг

Мониторинг не заменяет:

• application logs;
• distributed tracing;
• метрики БД;
• профилирование;
• тесты перед релизом.

Он отвечает на другой вопрос: «Работает ли выбранный внешний контракт сейчас и работал ли он в предыдущих проверках?»

Эти инструменты дополняют друг друга.

Чек-лист хорошей API-проверки

• выбран критичный endpoint;
• метод соответствует контракту;
• запрос не создаёт опасных побочных эффектов;
• ожидаемый HTTP-код задан явно;
• timeout реалистичен;
• при необходимости проверяется JSON;
• секреты ограничены минимальными правами;
• проверка выполняется регулярно;
• результат сохраняется в истории;
• команда понимает, что делать при срабатывании.

Источники и спецификации

• RFC 9110: HTTP Semantics
• MDN: коды состояния HTTP