Как мониторить REST API на время работы и время отклика

Мониторинг REST API — это не то же самое, что мониторинг веб-сайта. Успешный HTTP 200 от вашего API не гарантирует, что ответ правильный, время отклика приемлемо или аутентификация все еще работает. Это руководство охватывает то, что должен проверять монитор API, пороги, которые выявляют проблемы рано без излишних срабатываний, и режимы молчаливых сбоев, которые пропускают простые проверки пинга.

Четыре вещи, которые должен проверять монитор API

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

Код статуса: вернул ли API 200 или он вернул 500, 502 или 503? Время отклика: ответил ли API в приемлемый промежуток времени? Содержимое тела: содержит ли ответ ожидаемые поля? Состояние аутентификации: по-прежнему ли API принимает учетные данные, которые он принимал вчера? Монитор, который проверяет все четыре, выявляет ошибочное поведение, которое любая одна проверка пропустила бы.

Конечные точки, которые стоит мониторить

Не каждой конечной точке API нужен монитор. Три категории охватывают большую часть реальной ценности.

• Конечная точка здоровья: обычно /health или /status. Должна возвращать 200 с небольшим полезным грузом JSON, подтверждающим подключение к базе данных и любые критические зависимости. Легко зондировать, быстро отказывает при сбое.
• Наиболее используемая реальная конечная точка: та, которая берет наибольшую часть вашего трафика. Если ваша конечная точка /users/me обслуживает 80% запросов, мониторьте ее напрямую. Если она перестанет работать, ваши клиенты заметят это немедленно.
• Конечная точка с наибольшей выручкой: та, которая обрабатывает платежи, подписки или что-либо, что напрямую переводится в деньги. Тот же монитор, более высокий приоритет оповещения.

Установка пороговых значений времени отклика без ложных срабатываний

Оповещения об времени ответа — это самый простой способ создать шумный монитор. Один медленный зонд во время развёртывания не является сигналом; десять медленных зондов подряд — это сигнал. Работающая стратегия порогового значения основана на перцентилях, а не на абсолютных значениях.

Измерьте время ответа p95 вашей конечной точки в течение обычной недели. Установите порог оповещения в 2x p95. Оповещайте только если три последовательных зонда его превысят. Результат — монитор, который игнорирует нормальное колебание, но фиксирует настоящую деградацию. Настраивайте множитель и количество последовательных зондов в течение первого месяца, затем больше не меняйте.

Скрытые отказы, которые пропускают простые проверки ping

API может вернуть HTTP 200 и всё равно быть неисправным. Четыре распространённых скрытых отказа появляются в реальных инцидентах.

• Кэшированные ошибочные ответы: API правильно возвращает 500 один раз, кэшируется на CDN и затем отдаёт 200 с устаревшим телом ошибки.
• Неправильный тип контента: API возвращает HTML вместо JSON, потому что средний слой отладки был оставлен включённым. Статус — 200, тело не разбирается.
• Пустой успех: API возвращает 200 с пустым набором результатов, потому что базовый запрос потерял объединение во время миграции.
• Дрейф аутентификации: API возвращает 200, потому что ограничитель скорости обрабатывает неаутентифицированный запрос корректно, но тело говорит «пожалуйста, войдите».

Аутентифицированный мониторинг без утечки учётных данных

Многие API требуют аутентификации на каждой конечной точке. Мониторам нужны учётные данные. Два шаблона работают хорошо; один распространённый шаблон — серьёзный риск безопасности.

Хорошо: выделенный API ключ только для чтения с максимально узким объёмом, ротируемый ежеквартально и хранящийся в зашифрованном виде в инструменте мониторинга. Лучше: подпись webhook или HMAC вместо токена-носителя, чтобы монитор не мог выдавать себя за пользователя. Плохо: долгоживущий токен-носитель для пользователя администратора продакшена, вставленный в конфиг монитора. Третий шаблон создаёт инциденты сам по себе, когда учётные данные монитора утекают.

Базовая настройка для API

Добавьте три монитора на каждый API. Монитор /health с интервалом 60 секунд и порогом времени ответа 500 мс. Монитор наиболее используемой реальной конечной точки с интервалом 60 секунд и проверкой содержимого тела. Монитор конечной точки, генерирующей наибольший доход, с интервалом 30 секунд с той же проверкой тела плюс более строгий порог времени ответа. Общее количество мониторов: три. Общее покрытие: большая часть того, что имеет значение. Добавляйте специфические мониторы для граничных случаев по мере их появления в реальных инцидентах, а не превентивно.