Какой лучший способ контролировать ваш REST API?

Ответ 1

Начните с определения основных потребностей, которые, по вашему мнению, будут решаться. Попробуйте ответить на два вопроса: "Что я хочу знать?" и "Как я хочу воздействовать на эту информацию?".

Примеры "Что я хочу знать?"

• Производительность с течением времени
• Крупнейшие пользователи API
• Наиболее часто используемые функции API
• Ошибка в API

Примеры "Как я хочу воздействовать на эту информацию?"

• Просмотрите панель известных измерений
• Будьте предупреждены, когда что-то изменится за пределы ожидаемых границ
• Выполнение трассировки, которое привело к этому состоянию
• Просмотрите измерения для всего срока службы системы.

Если вы можете ответить на эти вопросы, вы можете найти правильное решение сторонних разработчиков, которое отражает интересующие вас показатели, или добавить контрольные пробники в нужную часть вашего API, которые расскажут вам, что вам нужно сделать знать. Я заметил, что вы в первую очередь являетесь Laravel, поэтому, вероятно, многие из показателей, которые вы хотите знать, могут быть захвачены добавлением до (Регистрация перед фильтрами на контроллере) и после (Регистрация фильтра после приложения) с вашим приложением, для измерения времени ответа и успешного завершения ответа. Здесь наиболее важны ответы на первый набор вопросов ( "Что я хочу знать?" ), Так как он будет определять, где и что вы измеряете в своем приложении.

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

Нет никаких популярных (насколько мне известно) примеров узкоспециализированного случая с открытым исходным кодом. Однако существуют многие коммерческие решения: NewRelic, Ruxit, DynaTrace и т.д. И т.д. И т.д. Их функция может быть легко описана как аналогичная удалённому профилировщику, а также множество других функций. (Кроме того, не забывайте, что более традиционный профилировщик может быть полезен для сбора некоторой информации, которая вам нужна, в то время как она определенно не заменит мониторинг вашего приложения, есть много ценной информации, которую можно почерпнуть из профилирования даже до того, как вы пойдете к производству.)

В общих чертах, есть много других вариантов с открытым исходным кодом, о которых я лично знаю. Самый длинный из них - Graphite (отличное введение, которое можно прочитать здесь: "Измерение всего, измерить все" ), который довольно часто используется среди многих, Графит далеко не единственный вариант, но вы можете найти множество других опций, таких как Kibana и InfluxDB, если вы хотите разместить себя.

Многие из этих вариантов с открытым исходным кодом также имеют варианты размещения, доступные от нескольких поставщиков. Кроме того, вы обнаружите, что в этом лагере есть много коммерческих возможностей (я основатель одного на самом деле:) - Instrumental).

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

Ответ 2

(Я явно склонен отвечать за это, так как я стал соучредителем Runscope, который, я считаю, является лидером в области мониторинга API, поэтому вы можете принять все это со вкусом соли или доверять моему многолетнему опыту работы с тысячами клиентов специально по этой проблеме:)

Я не знаю никаких инструментов OSS, специфичных для мониторинга REST (ful) API. Инструменты мониторинга показателей общего назначения OSS (например, Graphite) могут определенно помочь следить за фрагментами вашего стека API, но не имеют каких-либо специфических для API функций.

Инструменты мониторинга коммерческих показателей (например, Datadog) или средства мониторинга производительности приложений (APM), такие как (New Relic или AppDynamics), имеют еще несколько функций, характерных для случаев использования API, но ни одна из них не сосредоточена на нем. Это полезная часть того, что мы называем "многоуровневым подходом к мониторингу": начните с мониторинга уровня высокого уровня API и используйте эти другие инструменты (отслеживатели исключений, APM, необработанные журналы), чтобы погрузиться в проблемы, когда они возникают.

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

Мониторинг времени работы

На базовом уровне вы захотите узнать, доступны ли вам API, даже для клиентов, которым требуется их доступ. Для "общедоступных" (то есть доступных в общедоступном Интернете, не обязательно публикованных... API-интерфейс мобильного брандмана является общедоступным, но не обязательно публичным) API, который вы хотите имитировать клиентов, которые называет их как можно больше. Если у вас есть мобильное приложение, вероятно, API должен быть доступен по всему миру. Поэтому, как минимум, ваш инструмент мониторинга API должен позволить вам запускать тесты из нескольких мест. Если ваш API не может быть достигнут из местоположения, вам понадобятся уведомления по электронной почте, Slack и т.д.

Если ваш API находится в частной сети (корпоративный брандмауэр, промежуточная среда, локальная машина и т.д.), вы также захотите "увидеть" его. Существует множество подходов к этому (агенты, VPN и т.д.), Просто убедитесь, что вы используете один из них, на котором подписывается ваш ИТ-отдел.

Глобальное распространение тестовых агентов - дорогостоящая настройка, если вы являетесь владельцем собственного хостинга, создаете собственный или используете инструмент OSS. Вы должны убедиться, что каждое удаленное местоположение, которое вы настроили (предпочтительно вне основного кластера), является высокодоступным и полностью контролируется. Это может стать очень дорогостоящим и трудоемким.

Мониторинг производительности

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

Внешне мониторинг скорости также важен для получения наиболее точного представления производительности. Если агент мониторинга находится внутри вашего кода или на том же сервере, вряд ли он учитывает все факторы, которые испытывает фактический клиент при совершении звонка. Такие вещи, как разрешение DNS, согласование SSL, балансировка нагрузки, кеширование и т.д.

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

Какая польза от API, который быстро и быстро возвращается, если он возвращает неверные данные? Этот сценарий очень распространен и, в конечном счете, намного хуже, чем у пользователей. Люди понимают "вниз"... они не понимают, почему приложение показывает им неправильные данные. Хороший инструмент для мониторинга API позволит вам глубже проверять полезную нагрузку сообщений, идущих туда и обратно. JSON и синтаксический анализ XML, сложные утверждения, проверка схемы, вычитание данных, динамические переменные, многошаговые мониторы и многое другое необходимы для полной проверки достоверности данных, отправляемых туда и обратно.

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

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

Ответ 3

Я использую runscope.com для своей компании. Если вы хотите что-то бесплатное apicombo.com, также можете это сделать. В основном вы можете создать тест для конечной точки API для проверки полезной нагрузки, времени ответа, кода состояния и т.д. Затем вы можете запланировать запуск теста. Они также предоставляют некоторые основные статистические данные.

Ответ 4

Я попробовал несколько приложений и методов, чтобы сделать это, и лучший (для моей компании и наших связанных проектов) - это log key = value pairs (атомные записи со всей информацией, связанной с этой операцией, например с источником IP, результат, прошедшее время и т.д.... в определенных файлах журналов для каждого node/сервера), а затем отслеживать с помощью Splunk. С вашими данными REST и json ваш aproach будет другим, но он также хорошо поддерживается.

Это довольно легко установить и настроить. Вы можете отслеживать (почти) данные в реальном времени (время ответов, результаты работы), отправлять уведомления о событиях и делать некоторые DWH (и многое другое, есть много плагинов).

Он не с открытым исходным кодом, но вы можете попробовать его бесплатно, если вы используете менее 50 МБ журналов в день (так, как он работал некоторое время назад, так как теперь я на корпоративной лицензии, я не уверен на 100%).

Вот небольшой учебник, объясняющий, как добиться того, что вы ищете: http://blogs.splunk.com/2013/06/18/getting-data-from-your-rest-apis-into-splunk/