Применение API в разработке ПО сыграло большую роль в создании современных приложений и повлияло на их общую оценку и опыт конечных пользователей. В этой статье Екатерина Саяпина, Product Owner личного кабинета платформы МТС Exolve, рассказывает про правильные подходы при отслеживании работы API. Подробности — под катом.

Доходы бизнеса возросли, что подтверждают результаты опроса более 40 000 разработчиков из отчёта Postman о состоянии API. 43% заявили, что использование API приносит более четверти общего дохода их компаниям. В то же время важно контролировать функционирование программных интерфейсов и проводить качественный мониторинг жизненного цикла, чтобы убедиться в корректности их работы. Такой анализ поможет определить проблемные места и обнаружить ошибки до того, как продукт выйдет на рынок.

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

Для чего отслеживать API

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

Вот несколько преимуществ такого подхода.

1. Обеспечение успешности транзакций API

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

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

2. Проверка данных ответа и обработка ошибок

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

3. Выявление изменённых конечных точек и ошибок сторонних интеграций

Конечные точки API довольно часто меняются по мере расширения организаций, где они используются (применение новых схем размещения продуктов). С учётом этого их версии обновляются, а значит, необходимы частые проверки. Так можно гарантировать, что код не выйдет из строя при внесении изменений.

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

Мониторинг API помогает выявлять и решать подобные проблемы в режиме реального времени. Это эффективный инструмент оптимизации служб в организации или проекте.

Какие ключевые метрики API отслеживать

1. Доступность или время безотказной работы (Uptime)

Эта метрика — стандарт измерения доступности вашего продукта, она обычно входит в SLA (соглашение об уровне обслуживания) при заключении договора между поставщиком услуги и заказчиком. Время безотказной работы API измеряют в процентах или в некоторых случаях как среднюю продолжительность простоя в год. В среде разработчиков часто можно услышать, что показатель определяется «девятками».

Рассмотрим на примере таблицы:

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

2. Использование процессора и памяти (CPU and memory usage)

При локальной отладке API вы увидите загрузку процессора системой через диспетчер задач в Windows (или монитор активности на Mac).

Однако на сервере это сделать проблематичнее. Высокая загрузка ЦП или памяти хост-сервера API обычно указывает на перегрузку виртуальной машины, контейнера или узла шлюза API, что замедляет его производительность.

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

3. Спрос на API (API Consumption)

Спрос на API измеряется количеством запросов в минуту или секунду (RPM). Эту метрику производительности часто используют при сравнении серверов HTTP или баз данных. Зная количество одновременных обращений пользователей, скорость ответа на них и среднее время размышления, вы легко сможете вычислить количество запросов в минуту по формуле:

r = n ÷ (T_response + T_think)

Например, вы увидели, что после запуска ПО для интернет-ресурса среднее количество одновременных пользователей составило 2 800. Это зависит от числа людей, зарегистрировавшихся на сайте, их поведения и времени, которое они выбирают для отправки запросов.

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

• n = 2 800 одновременных пользователей

• T_response = 1 (среднее время ответа на запрос — одна секунда)

• T_think = 3 (среднее время размышления — три секунды)

Расчёт количества запросов в секунду:
г = 2 800 ÷ (1 + 3) = 700

Следовательно, количество запросов в секунду равно 700, а количество запросов в минуту — 42 000.

4. Время ответа API (API Response Time)

Показатель представляет собой счётчик времени, которое требуется конечной точке API для предоставления ответа. Этот показатель сложно отслеживать при использовании сторонних API, поскольку задержка может быть результатом как чрезвычайно медленной работы конечных точек, так и проблем с сетью.

Высокопроизводительными API считаются, если среднее время отклика составляет от 0,1 до 1 секунды. При такой скорости человек, использующий вашу программу, не увидит каких-либо перебоев в её работе. Спустя одну-две секунды задержка уже заметна, а через пять секунд вы рискуете потерять пользователя приложения.

Например, у вас может быть конечная точка POST /checkout, задержка которой постепенно увеличивается из-за роста объёма таблицы SQL и её неправильной индексации. Однако из-за небольшого количества вызовов POST /checkout эта проблема маскируется вашей конечной точкой GET /items, которая вызывается гораздо чаще, чем checkout. Аналогично, если у вас GraphQL, вам нужно посмотреть среднюю задержку на операцию GraphQL.

5. Частота ошибок (Error rate)

Error rate показывает количество ошибок в минуту или секунду. Он позволяет получить точную информацию об отслеживании проблем в конкретных конечных точках API. Это количество вызовов API в минуту с кодами состояния, отличными от 200, и оно имеет решающее значение для измерения того, насколько ваш API некорректно работает и подвержен ошибкам. Поэтому чем меньше значение показателя, тем лучше. Все коды состояния можно посмотреть в Википедии.

6. Количество уникальных пользователей API (Unique API Consumers)

Эта API-метрика помогает команде разработчиков получить представление об общем росте продукта и привлечении новых клиентов на основе числа активных пользователей за месяц. Быстрое снижение показателей в часы пик работы может указывать на проблему с платформой приложений.

Важно измерять API DAU (ежедневные активные пользователи) и веб-DAU, если внедрили такой формат. Мы говорим о тех случаях, когда ваша команда создаёт продукт и в виде API, и в виде веб-платформы. Если веб-DAU растёт намного быстрее API DAU, это может означать негерметичную воронку во время интеграции. Это особенно актуально, когда основной продукт компании — API, как у МТС Exolve.

7. Рост процента использования API (API usage growth)

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

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

Практики мониторинга API

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

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

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

3. Отправка автоматических оповещений клиентам через мессенджеры или SMS API от Exolve. Стратегия мониторинга API не будет эффективной, если разработчикам придётся вручную проверять его состояние. Поэтому руководителю следует использовать возможности оповещения и интеграцию с инструментами коммуникации, чтобы команды автоматически получали уведомления о соответствующих действиях.

4. Ищите исторические тренды. Это поможет повышать производительность, анализируя тесты с течением времени, и выявлять тенденции при возникновении проблем.

5. Запускайте мониторинг с правильной частотой. Определите, как часто будете выполнять тесты. Ваш API критически важен и требует ежеминутного мониторинга? Или достаточно запускать тесты каждые 60 минут или 24 часа?

Инструменты мониторинга

Все описанные показатели и метрики можно просмотреть и проанализировать при помощи любой из существующих на сегодняшний день APM-систем (Application Performance Monitoring).

Вот несколько решений для мониторинга и тестирования API:

• AWS Cloudwatch

• Postman (статья на русском о тестировании API при помощи Postman)

• AppDynamics

• Datadog

• SigNoz (в открытом доступе)

• New Relic

• Prometheus (в открытом доступе)

• Sauce Labs

• Graphite (в открытом доступе)

• SmartBear

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

Поделитесь своими метриками, инструментами и практиками в комментариях.