Cette section aide les développeurs de logiciels qui souhaitent développer des applications en utilisant des outils de surveillance Dotcom-Monitor.
Il existe plusieurs façons d’afficher et d’interagir avec les données de surveillance au-delà de l’interface du site Web Dotcom-Monitor, notamment l’utilisation du flux XML pour consommer des données et l’interaction avec l’API Dotcom-Monitor pour surveiller et mettre à jour les agents de surveillance installés.
Avec le flux XML, les développeurs peuvent s’abonner aux données souhaitées et les présenter dans leur propre format à l’aide de leurs propres rapports personnalisés. Voir L’utilisation de l’outil XML Reporting Service (XRS) pour plus de détails.
Les utilisateurs de l’API Dotcom-Monitor peuvent créer leurs propres scripts ou applications personnalisés pour interagir avec les paramètres et afficher les données surveillées dans leur propre environnement personnalisé. Notre système utilise l’API REST qui permet l’interaction avec le site Web Dotcom-Monitor par programmation en utilisant les méthodes les plus populaires pour travailler avec des données via des requêtes HTTP (S) (GET, POST, PUT, DELETE). Presque tous les objets Dotcom-Monitor sont accessibles via l’API REST et presque tous les aspects des fonctionnalités du service Dotcom-Monitor sont gérés. En utilisant les appels d’API, les développeurs peuvent créer et supprimer des appareils et des tâches, les reporter et les démarrer, créer et gérer des groupes d’alertes, des modèles, des filtres et des planificateurs, obtenir des informations sur l’état des appareils ainsi que de nombreuses autres options.
En général, l’API Dotcom-Monitor peut être utilisée dans les tâches suivantes :
- Intégration tierce avec la solution dotcom-monitor monitoring.
- Téléchargement et téléchargement de données.
- Modification des données.
Les actions les plus courantes exécutées via l’API REST :
- Accès aux listes de plates-formes de surveillance, d’appareils, de cibles, de planificateurs, d’emplacements, de groupes d’alertes, de filtres, de modèles d’alerte.
- Accès à des informations détaillées sur les plates-formes, les appareils et les cibles.
- Modification des appareils, des cibles, des planificateurs, des groupes et modèles d’alertes, des filtres.
- Création d’un nouvel objet dotcom-Monitor (périphériques, cibles, planificateurs, etc.).
- Gestion des objets d’audit.
API collector personnalisée
L’API MetricsView séparée est un ensemble de méthodes pour télécharger des mesures à partir de n’importe quelle source, quelle que soit la plate-forme dans Dotcom-Monitor inc. pour un traitement et une analyse plus ultérieurs.
L’API Dotcom-Monitor est divisée en 10 types de ressources :
- Plate-forme: Toutes les tâches de surveillance relèvent de l’une des cinq plates-formes différentes.
- Appareils: Un périphérique surveillé est un «ensemble» organisé de tâches de surveillance qui contient soit une seule tâche de surveillance, une séquence de tâches de surveillance, un script de surveillance qui comprend des tâches, ou une combinaison des trois.
- Tâches: Une tâche est une activité de surveillance unique, comme la surveillance d’une cible (URL, Serveur de messagerie, serveur FTP, etc.).
- Fréquence: Définit la fréquence d’exécution des sessions de suivi.
- Horaire: Un calendrier détaille quand une tâche sera ou ne sera pas exécuté.
- Lieu: Un emplacement de surveillance disponible au sein du réseau de surveillance mondial Dotcom-Monitor.
- Groupe d’alerte: La mise en place d’un groupe place les destinataires d’un rapport et/ou d’une alerte dans un groupe. Chaque destinataire du groupe peut avoir un modèle d’alerte unique.
- Modèle d’alerte: Le modèle définit le format des alertes.
- Filtre: Un filtre est un ensemble de règles qui déterminent comment les réponses de surveillance sont traitées et affichées.
- Vérification : Fournit des informations historiques sur chaque modification de compte.
Vous devez être authentifié dans Dotcom-Monitor avant toute demande d’API. L’authentification expire après 60 secondes d’inactivité.
Le tableau ci-dessous indique quel type de demande et action sont pris en charge par chaque type de ressource. Consultez la section Méthodes de surveillance pour obtenir des descriptions détaillées.
| Type de ressource | Méthode de demande | URI(s) | description |
|---|---|---|---|
| plateforme | Avoir | /plates-formes | Liste de retour des plateformes disponibles |
| appareil | Avoir | /appareils/{platform} | Obtenez la liste des appareils par plate-forme. |
| Avoir | /appareil/{deviceId} | Obtenez des informations sur l’appareil | |
| Publier | /devices?verb=PUT | Créer un nouvel appareil | |
| mettre | /appareils | ||
| Publier | /dispositif/ {deviceId} /DisableAlert/ | Alertes désactiver | |
| Publier | /appareil/{deviceId} | Modifier l’appareil | |
| Publier | /device/ {deviceId} ?verb=delete | Supprimer l’appareil | |
| supprimer | /appareil/{deviceId} | ||
| tâche | Avoir | /appareil/ {deviceid} /tâches | Obtenez la liste des tâches sous un appareil |
| Publier | /tasks?verb=PUT | Créer une nouvelle tâche | |
| mettre | /tâches | ||
| Avoir | /tâche/{TaskId} | Obtenez des informations sur les tâches | |
| Publier | /tâche/{TaskId} | Modifier la tâche | |
| Publier | /task/ {TaskId} ?verb=delete | Supprimer la tâche | |
| supprimer | /tâche/{TaskId} | ||
| Fréquence | Avoir | /fréquences/{platform_name} | Obtenez freq disponible. par plate-forme. |
| programmateur | Avoir | /horaires | Obtenez la liste des horaires |
| Avoir | /Scheduler/{Scheduler_ID} | Obtenez des informations spécifiques sur les chéanciers | |
| Publier | /schedulers?verb=PUT | Créer un nouveau calendrier | |
| mettre | Planificateurs | ||
| Publier | /scheduler/{ Œdidid du planningr} | Modifier le calendrier | |
| Publier | /Scheduler/ {Scheduler_Id} ?verb=delete | Supprimer le calendrier | |
| supprimer | /Scheduler/{Scheduler_Id} | ||
| Emplacement | Avoir | /emplacements/{platform_name} | Obtenez la liste des emplacements disponibles |
| Groupe d’alerte | Avoir | /groupes | Obtenez la liste des groupes d’alerte |
| Publier | /groupes?verb=PUT/groupes | Créer un groupe d’alerte | |
| mettre | groupes/groupes | ||
| Avoir | /Groupe/{Group_ID} | Obtenez des informations de groupe d’alerte | |
| Publier | /Groupe/{Group_ID} | Modifier le groupe d’alerte | |
| Publier | /Groupe/ {Group_Id} ?verb=delete | Supprimer le groupe | |
| supprimer | Groupe/{Group_Id} | ||
| Modèle d’alerte | Avoir | /modèles | Obtenez la liste des modèles d’alerte |
| Publier | /templates?verb=PUT/templates | Créer un nouveau modèle d’alerte | |
| mettre | /modèles/modèles | ||
| Avoir | /modèle/{Template_ID} | Obtenez des informations sur le modèle d’alerte | |
| Publier | /modèle/{Template_ID} | Modifier le modèle d’alerte | |
| Publier | /template/ {Template_Id} ?verb=delete | Supprimer le modèle | |
| supprimer | /modèle/{Template_Id} | ||
| filtre | Avoir | /filtres | Obtenez la liste des filtres |
| Publier | /filtres?verb=PUT | Créer un nouveau filtre | |
| mettre | /filtres | ||
| Avoir | /filtre/{filter_ID} | Obtenez des informations spécifiques sur le filtre | |
| Publier | /filtre/{filter_ID} | Modifier le filtre | |
| Publier | /filtre/ {filter_ID} ?verb=delete | Supprimer le filtre | |
| supprimer | /filtre/{filter_ID} | ||
| audit | Avoir | /audit/liste | Obtenez des objets audités liste pour l’utilisateur actuel pour les dernières 24h. |
| Avoir | /audit/objet/{sample ID} | Obtenez le contenu de l’audit pour l’iD particulier | |
| Publier | /audit/liste | Obtenez la liste filtrée des objets audités. |
-
Web API Monitoring: How to Start and What Approach to Use
Avant de commencer avec la rubrique Surveillance des API Web, parlons brièvement des approches couramment utilisées pour échanger des données entre différents types de logiciels.
Il est difficile d’imaginer une entreprise moderne où tous les processus métier s’exécutent sur un seul produit logiciel. En règle générale, plusieurs applications de bureau et Web sont utilisées pour soutenir les opérations commerciales tout au long de leur cycle de vie. Certaines applications sont en mesure d’interagir avec des produits logiciels associés, tandis que d’autres ont besoin d’une configuration supplémentaire ou de services tiers. Par exemple, les pratiques courantes qui ont été introduites sur le marché des logiciels pour soutenir l’intégration de logiciels sont les suivantes :
- Services Web.
- Échange de fichiers via FTP.
- Requêtes HTTP non structurées.
- D’autres approches telles que les sockets Web, les ports dédiés, etc.
Alors que toutes les autres approches d’intégration logicielle n’ont pas de processus normalisés d’échange de données, les services Web fournissent un moyen normalisé d’intégration. Un service Web est une technologie qui permet aux applications de communiquer entre elles sur un réseau. En termes simples, un service Web est une adresse sur Internet, un lien accessible pour obtenir des données ou effectuer une action. En règle générale, les services Web qui s’exécutent sur HTTP sont appelés API Web. L’avantage de l’utilisation de HTTP comme protocole de transport est qu’elle rend les services Web indépendants des langages de programmation. Dans le cas des services Web, le client qui effectue la demande à la ressource et le serveur d’API fournissant la réponse peuvent utiliser n’importe quel langage de programmation ou infrastructure. De cette façon, peu importe si les applications que nous voulons connecter sont développées en utilisant les mêmes langages de programmation ou non.
Les API Web sont généralement implémentées à l’aide des technologies suivantes :
- XML-RPC (eXtensible Markup Language Remote Procedure Call) – le protocole qui utilise HTTP comme protocole de transport et XML pour coder les appels.
- JSON-RPC (JSON Remote Procedure Call) – un analogue de XML-RPC, sauf que les messages sont transférés au format JSON.
- SOAP (Simple Object Access Protocol) – le protocole standardisé qui utilise WSDL (Web Services Description Language) basé sur XML pour décrire une structure de message.
- REST (Representational State Transfer) – pas un protocole mais une architecture d’interaction logicielle dans un réseau basée sur les méthodes du protocole HTTP.
- Protocoles spécialisés conçus pour travailler sur une tâche spécifique, tels que GraphQL qui est utilisé pour créer une requête sur un serveur d’API et charger des données de cette API vers une application cliente.
Qu’est-ce que la surveillance des API ?
Une fois que vous avez implémenté une API Web pour votre application et que vous envisagez de passer en public, vous devez vous assurer que toutes les fonctions d’API fonctionnent conformément à la logique métier de votre application. En outre, garder un œil sur les performances de votre API Web est crucial, que vous soyez vous-même un consommateur du service d’API ou que vous fournissiez le service à des applications tierces. Toute dégradation des performances de votre service d’API peut entraîner des pertes importantes pour les entreprises associées et affecter l’expérience de vos utilisateurs.
L’objectif principal de la surveillance des API est de trouver et de corriger de manière proactive toutes les erreurs au sein de votre API au fur et à mesure qu’elles se produisent et même avant que vos utilisateurs ne les remarquent.
Pourquoi avons-nous besoin de surveiller l’API de votre application Web ou de votre site Web ? Pourquoi le test de l’interface utilisateur n’est-il pas suffisant pour s’assurer que votre application web fonctionne correctement ? Le test de l’interface utilisateur est vraiment le meilleur moyen de simuler le comportement réel de l’utilisateur (voir les avantages du test d’application Web dans un navigateur réel avec Dotcom-Monitor EveryStep Scripting Tool). Toutefois, les fonctionnalités du site Web que nous avons tendance à surveiller via l’interface utilisateur peuvent généralement déjà être vérifiées par des tests de surveillance de l’API. Par exemple, un appel d’API qui charge la liste des éléments en stock sur le magasin en ligne a été modifié sur le serveur principal mais est resté le même sur l’interface utilisateur et le système ne pourra pas renvoyer la liste sur l’action de l’utilisateur correspondante sur le site Web. Dans ce cas, la surveillance de l’interface utilisateur renvoie l’erreur, mais la véritable source de l’erreur ne sera pas détectée (il peut s’agir d’un problème de connectivité, d’une surcharge du serveur, d’erreurs d’interface utilisateur, d’un appel d’API incorrect, etc.). De l’autre côté, la surveillance de l’API Web montre que l’appel au point de terminaison de l’API cible ne retourne pas la réponse. Pour une vérification supplémentaire des résultats d’appel d’API, la validation du contenu de la réponse peut être utilisée.
Comment fonctionne la surveillance des API ?
La surveillance des API Web se concentre sur les ressources et l’accès à ces ressources. Dans l’API Web, les ressources présentent différents types d’informations. Les ressources sont accessibles via des URL (Uniform Resource Locators). Lorsque vous accédez à une URL particulière dans votre navigateur, vous vous connectez à la ressource qui correspond à cette URL. La même chose se produit lorsque vous envoyez une demande d’API à une adresse URL de la ressource à partir de telles applications comme Postman ou à l’aide de CURL. Pour que le service Web définisse clairement l’action que vous souhaitez effectuer sur la ressource, les méthodes HTTP sont utilisées, notamment GET (lecture), POST (création), PUT (mise à jour) et DELETE (suppression). Consultez Charge utile REST – Comment envoyer à l’API Web pour obtenir des explications détaillées sur l’utilisation de Dotcom-Monitor pour surveiller les API RESTful.
Chaque demande sera suivie d’une réponse du serveur d’API. La réponse est les données retournées par l’API en réponse à la demande. Les réponses peuvent retourner différentes données, y compris un objet JSON.
Le chemin d’accès complet à la ressource qui inclut les paramètres de demande et fournit l’accès à la ressource est appelé point de terminaison d’API Web. Par exemple, le point de terminaison à qui envoyer un appel d’API peut ressembler à ceci :For example, the endpoint to send an API call to can look like this:
http://example.com/wp-json/wp/v2/tests
En termes simples, les points de terminaison sont ce que nous vérifions lors de l’exécution d’appels de surveillance d’API Web pour nos sites Web et applications. En général, les étapes de surveillance des points de terminaison d’API incluent :In general, API endpoint monitoring steps include:
- Demande à un point de terminaison.
- Réponse du serveur d’API.
- Vérification et analyse des réponses.
Avantages de l’utilisation de Dotcom-Monitor comme outil de surveillance d’API
Dotcom-Monitor est une solution complète qui peut être utilisée pour tous les types de surveillance d’API Web (voir comment configurer la surveillance des services Web SOAP et la surveillance de l’API Web REST). Outre la surveillance de l’API, Dotcom-Monitor fournit des outils de surveillance pour les applications Web, les sites Web, les pages Web uniques, les serveurs Web et d’autres types de ressources Web.
Pour amener le processus de surveillance à un nouveau niveau, Dotcom-Monitor permet aux utilisateurs de tester leurs applications Web cibles dans une fenêtre de navigateur réelle. Les tests basés sur un navigateur garantissent que le test de surveillance est exécuté aussi près que possible d’un scénario réel et répète l’expérience utilisateur réelle. Vous pouvez choisir entre un certain nombre de moteurs de navigateur pour exécuter votre application ou votre site Web, y compris les moteurs de navigateur de bureau et mobile.
Des rapports de performances détaillés avec des graphiques en cascade élément par élément, des captures d’écran et des vidéos enregistrées pendant les sessions de surveillance vous donnent une compréhension complète de ce qui se passe exactement dans la scène de l’interface utilisateur – quels éléments ralentissent votre application et provoquent des erreurs et des goulots d’étranglement dans ses performances.
Le système d’alerte Dotcom-Monitor hautement personnalisé vous fournit un service de notification d’alerte efficace. Le système peut être configuré pour envoyer des notifications d’alerte aux adresses dédiées lorsque des erreurs sont détectées lors de la surveillance. Consultez les mécanismes d’alerte pris en charge dans l’article Mécanismes de remise d’alertes de notre Base de connaissances.