Этот раздел помогает разработчикам программного обеспечения, которые хотят разрабатывать приложения с помощью инструментов мониторинга Dotcom-Monitor.
Существует несколько способов просмотра и взаимодействия с данными мониторинга за пределами интерфейса веб-сайта Dotcom-Monitor, включая использование XML-канала для потребления данных и взаимодействие с API Dotcom-Monitor для мониторинга и обновления установленных агентов мониторинга.
С помощью XML-канала разработчики могут подписаться на разыскиваемые данные и представить их в своем собственном формате, используя свои собственные пользовательские отчеты. Подробнее об этом можно усмотреть с помощью инструмента службы отчетности XML (XRS).
Пользователи API Dotcom-Monitor могут создавать свои собственные пользовательские сценарии или приложения для взаимодействия с настройками и просмотра отслеживаемых данных в своей собственной настроенной среде. Наша система использует REST API, что позволяет программно взаимодействовать с веб-сайтом Dotcom-Monitor с использованием наиболее популярных методов работы с данными через HTTP(S) запросы (GET, POST, PUT, DELETE). Почти ко всем объектам Dotcom-Monitor можно получить доступ через REST API, и почти всеми аспектами функциональности службы Dotcom-Monitor можно управлять. С помощью вызовов API разработчики могут создавать и удалять устройства и задачи, откладывать и запускать их, создавать и управлять группами оповещений, шаблонами, фильтрами и планировщиками, получать информацию о состоянии устройства и многие другие опции.
В целом, API Dotcom-Monitor можно использовать в следующих задачах:
- Сторонняя интеграция с решением Dotcom-Monitor Monitoring.
- Загрузка и выгружа данных.
- Изменение данных.
Наиболее распространенные действия, выполняемые через REST API:
- Доступ к спискам платформ мониторинга, устройств, целей, планировщиков, местоположений, групп оповещений, фильтров, шаблонов оповещений.
- Доступ к подробной информации о платформах, устройствах и целях.
- Редактирование устройств, целевых объектов, планировщиков, групп оповещений и шаблонов, фильтров.
- Создание нового объекта dotcom-Monitor (устройства, цели, планировщики и т.д.).
- Управление объектами аудита.
Пользовательский коллектор API
Отдельный API MetricsView представляет собой набор методов для загрузки любых метрик из любого источника, независимо от платформы в Dotcom-Monitor inc. для дальнейшей обработки и анализа.
API Dotcom-Monitor разбит на 10 типов ресурсов:
- Платформа: Все задачи мониторинга подпадают под одну из пяти различных платформ.
- Устройства: Мониторинг устройства является организованным “набором” задач мониторинга, который содержит либо одну задачу мониторинга, последовательность задач мониторинга, сценарий мониторинга, который включает в себя задачи, или сочетание всех трех.
- Задачи: Задача состоит из любого действия по мониторингу, например мониторинга цели (URL, почтовый сервер, FTP Server и т.д.).
- Частота: Определяет, как часто будут выполняться сеансы мониторинга.
- Планировщик: Планировщик подробно, когда задача будет или не будет запущена.
- Местонахождение: Местоположение мониторинга, доступное в сети мониторинга Dotcom-Monitor по всему миру.
- Группа оповещения: Настройка группы помещает получателей отчета и/или оповещения в группу. Каждый получатель в группе может иметь уникальный шаблон оповещения.
- Шаблон оповещения: Шаблон определяет формат оповещений.
- Фильтр: Фильтр – это набор правил, определяющих, как обрабатываются и отображаются ответы мониторинга.
- Аудит: Предоставляет историческую информацию о каждой модификации учетной записи.
Перед любым запросом API необходимо проверить подлинность в Dotcom-Monitor. Срок действия аутентификации истекает через 60 секунд после бездействия.
В таблице ниже показано, какой тип запроса и действие поддерживаются каждым типом ресурса. Подробные описания см. в разделе Методы мониторинга.
| Тип ресурсов | Метод запроса | URI (ы) | описание |
|---|---|---|---|
| платформа | Получить | /платформы | Обратный список доступных платформ |
| устройство | Получить | /устройства/{platform} | Получите список устройств по платформе. |
| Получить | /устройство/{deviceId} | Получить информацию об устройстве | |
| Поместить | /устройства?verb-PUT | Создание нового устройства | |
| класть | /устройства | ||
| Поместить | /устройство/ {deviceId} /DisableAlert/ | Отключение оповещений | |
| Поместить | /устройство/{deviceId} | Редактировать устройство | |
| Поместить | /устройство/ {deviceId} ?verb’delete | Удаление устройства | |
| удалить | /устройство/{deviceId} | ||
| задача | Получить | /устройство/ {deviceid} /задачи | Получить список задач под устройством |
| Поместить | /задачи?verb-PUT | Создание новой задачи | |
| класть | /задачи | ||
| Получить | /задача/{TaskId} | Получить информацию о задаче | |
| Поместить | /задача/{TaskId} | Задача редактирования | |
| Поместить | /задача/ {TaskId} ?verb’delete | Удаление задачи | |
| удалить | /задача/{TaskId} | ||
| Частота | Получить | /частоты/{platform_name} | Получить доступ freq. по платформе. |
| планировщик | Получить | /Планировщики | Получить список планировщиков |
| Получить | /Расписание/{Scheduler_ID} | Получить конкретную информацию планировщик | |
| Поместить | /Планировщики?вербе-ПУТ | Создание нового планировщика | |
| класть | Планировщики | ||
| Поместить | /Расписание/идентификатор планировщика | Редактировать планировщик | |
| Поместить | /Расписание/ {Scheduler_Id} ?verb’delete | Удалить планировщик | |
| удалить | /Расписание/{Scheduler_Id} | ||
| Расположение | Получить | /локации/{platform_name} | Получить список доступных мест |
| Группа оповещения | Получить | /группы | Получить список групп оповещения |
| Поместить | /группы?verb-PUT/groups | Создание группы оповещения | |
| класть | группы/группы | ||
| Получить | /Группа/{Group_ID} | Получить информацию о группе оповещения | |
| Поместить | /Группа/{Group_ID} | Редактировать группу оповещения | |
| Поместить | /Группа/ {Group_Id} ?verb’delete | Удалить группу | |
| удалить | Группа/{Group_Id} | ||
| Шаблон оповещения | Получить | /шаблоны | Получить список шаблонов оповещения |
| Поместить | /шаблоны?verb-PUT/templates | Создание нового шаблона оповещения | |
| класть | /шаблоны/шаблоны | ||
| Получить | /шаблон/{Template_ID} | Получить информацию о шаблоне оповещения | |
| Поместить | /шаблон/{Template_ID} | Редактировать шаблон оповещения | |
| Поместить | /шаблон/ {Template_Id} ?verb’delete | Удалить шаблон | |
| удалить | /шаблон/{Template_Id} | ||
| фильтр | Получить | /фильтры | Получить список фильтров |
| Поместить | /фильтры?verb-PUT | Создание нового фильтра | |
| класть | /фильтры | ||
| Получить | /фильтр/{filter_ID} | Получить конкретную информацию о фильтре | |
| Поместить | /фильтр/{filter_ID} | Редактировать фильтр | |
| Поместить | /фильтр/ {filter_ID} ?verb’delete | Удалить фильтр | |
| удалить | /фильтр/{filter_ID} | ||
| ревизия | Получить | /аудит/список | Получить список проверенных объектов для текущего пользователя за последние 24h. |
| Получить | /аудит/объект/образец ID | Получить содержимое аудита для конкретного идентификатора | |
| Поместить | /аудит/список | Получить отфильтрованный список проверенных объектов. |
-
Web API Monitoring: How to Start and What Approach to Use
Прежде чем мы начнем с раздела Мониторинг веб-API, давайте кратко поговорим о подходах, которые обычно используются для обмена данными между различными типами программного обеспечения.
Трудно представить себе современную компанию, где все бизнес-процессы работают на одном программном продукте. Как правило, существует несколько настольных и веб-приложений, используемых для поддержки бизнес-операций на протяжении всего их жизненного цикла. Некоторые приложения из коробки способны взаимодействовать со связанными программными продуктами, в то время как другие нуждаются в дополнительной настройке или сторонних сервисах. Например, общие практики, которые были введены на рынке программного обеспечения для поддержки интеграции программного обеспечения:
- Веб-службы.
- Обмен файлами через FTP.
- Неструктурированные HTTP-запросы.
- Другие подходы, такие как веб-сокеты, выделенные порты и т. Д.
В то время как все другие подходы к интеграции программного обеспечения не имеют стандартизированных процессов обмена данными, веб-сервисы обеспечивают стандартизированный способ интеграции. Веб-служба — это технология, которая позволяет приложениям взаимодействовать друг с другом по сети. Проще говоря, веб-сервис — это адрес в Интернете, ссылка, к которую можно получить доступ для получения данных или выполнения действия. Обычно веб-службы, которые запускаются по протоколу HTTP, называются веб-API. Преимущество использования HTTP в качестве транспортного протокола заключается в том, что он делает веб-службы независимыми от языков программирования. В случае веб-служб клиент, делающий запрос к ресурсу, и сервер API, предоставляющий ответ, могут использовать любой язык программирования или фреймворк. Таким образом, не имеет значения, разрабатываются ли приложения, которые мы хотим подключить, с использованием одних и тех же языков программирования или нет.
Веб-API обычно реализуются с использованием следующих технологий:
- XML-RPC (eXtensible Markup Language Remote Procedure Call) – протокол, использующий HTTP в качестве транспортного протокола и XML для кодирования вызовов.
- JSON-RPC (JSON Remote Procedure Call) – аналог XML-RPC, за исключением сообщений, передаваемых в формате JSON.
- SOAP (Simple Object Access Protocol) — стандартизированный протокол, использующий WSDL (web Services Description Language) на основе XML для описания структуры сообщения.
- REST (Representational State Transfer) – не протокол, а архитектура программного взаимодействия в сети, основанная на методах протокола HTTP.
- Специализированные протоколы, предназначенные для работы над конкретной задачей, такой как GraphQL, который используется для создания запроса к серверу API и загрузки данных из этого API в клиентское приложение.
Что такое мониторинг API?
После реализации веб-API для приложения и принятия возможности выхода на бирж необходимо убедиться, что все функции API работают в соответствии с бизнес-логикой приложения. Кроме того, отслеживание производительности веб-API имеет решающее значение независимо от того, являетесь ли вы потребителем службы API самостоятельно или предоставляете службу сторонним приложениям. Любое снижение производительности службы API может привести к значительным потерям для связанных предприятий и повлиять на взаимодействие с пользователями.
Основная цель API Monitoring — заблаговременно находить и исправлять все ошибки в api по мере их возникновения и даже до того, как пользователи их заметят.
Зачем нужно отслеживать API вашего веб-приложения или веб-сайта? Почему тестирования пользовательского интерфейса недостаточно, чтобы убедиться, что веб-приложение работает правильно? Тестирование пользовательского интерфейса действительно является лучшим способом моделирования реального поведения пользователя (см. преимущества тестирования веб-приложений в реальных браузерах с помощью Dotcom-Monitor EveryStep Scripting Tool). Тем не менее, функциональность веб-сайта, которую мы обычно отслеживаем через пользовательский интерфейс, как правило, уже может быть проверена тестами мониторинга API. Например, вызов API, который загружает список товаров в наличии в интернет-магазине, был изменен на серверной части, но остался прежним в пользовательском интерфейсе, и система не сможет вернуть список при соответствующем действии пользователя на веб-сайте. В этом случае мониторинг пользовательского интерфейса вернет ошибку, но истинный источник ошибки не будет обнаружен (это может быть проблема с подключением, перегрузка сервера, ошибки пользовательского интерфейса, неправильный вызов API и т. Д.). С другой стороны, мониторинг веб-API покажет, что вызов конечной точки целевого API не возвращает ответ. Для дополнительной проверки результатов вызова API можно использовать проверку содержимого ответа.
Как работает мониторинг API?
Мониторинг веб-API фокусируется на ресурсах и доступе к этим ресурсам. В веб-API ресурсы представляют различные типы информации. Доступ к ресурсам можно получить через URL-адреса (унифицированные указатели ресурсов). При переходе по определенному URL-адресу в браузере вы подключаетесь к ресурсу, соответствующему этому URL-адресу. То же самое происходит, когда вы отправляете API-запрос на URL-адрес ресурса из таких приложений, как Postman или с помощью CURL. Чтобы веб-службе было понятно, какое действие вы хотите выполнить с ресурсом, используются методы HTTP, включая GET (чтение), POST (создание), PUT (обновление) и DELETE (удаление). Подробное объяснение того, как использовать Dotcom-Monitor для мониторинга RESTful API, см. в разделе Полезная нагрузка REST — как отправить в веб-API.
За каждым запросом последует ответ от сервера API. Ответ — это данные, возвращаемые API в ответ на запрос. Ответы могут возвращать различные данные, включая объект JSON.
Весь путь к ресурсу, который включает параметры запроса и предоставляет доступ к ресурсу, называется конечной точкой веб-API. Например, конечная точка, в которую отправляется вызов API, может выглядеть следующим образом:
http://example.com/wp-json/wp/v2/tests
Проще говоря, конечные точки — это то, что мы проверяем при выполнении вызовов мониторинга веб-API для наших веб-сайтов и приложений. Как правило, шаги мониторинга конечных точек API включают в себя:
- Запрос к конечной точке.
- Ответ от сервера API.
- Проверка и анализ ответов.
Преимущества использования Dotcom-Monitor в качестве инструмента мониторинга API
Dotcom-Monitor — это комплексное решение, которое можно использовать для всех типов мониторинга веб-API (см. раздел Как настроить мониторинг веб-служб SOAP и мониторинг веб-API REST). Помимо мониторинга API, Dotcom-Monitor предоставляет инструменты мониторинга для веб-приложений, веб-сайтов, отдельных веб-страниц, веб-серверов и других типов веб-ресурсов.
Чтобы вывести процесс мониторинга на новый уровень, Dotcom-Monitor позволяет пользователям тестировать свои целевые веб-приложения в реальном окне браузера. Тестирование на основе браузера гарантирует, что тест мониторинга выполняется как можно ближе к реальному сценарию и повторяет реальный пользовательский опыт. Вы можете выбрать между несколькими браузерными движками для запуска вашего приложения или веб-сайта, включая настольные и мобильные браузерные движки.
Подробные отчеты о производительности с поэлементными каскадными диаграммами, скриншотами и видео, записанными во время сеансов мониторинга, дают вам полное представление о том, что именно происходит за кулисами пользовательского интерфейса – какие элементы замедляют работу вашего приложения и вызывают ошибки и узкие места в его производительности.
Высокоспециализированная система оповещения Dotcom-Monitor предоставляет вам эффективную службу оповещений. Система может быть настроена на отправку оповещений на выделенные адреса при обнаружении ошибок во время мониторинга. Ознакомьтесь с поддерживаемыми механизмами оповещения в статье Механизмы доставки оповещений нашей базы знаний.