Cette section aide les développeurs de logiciels qui souhaitent développer des applications à l’aide des outils de surveillance Dotcom-Monitor. Veuillez ouvrir un ticket de support pour activer l’accès à l’API Dotcom-Monitor à partir de vos adresses IP.

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.

Ajout d’un identificateur unique d’intégration

Pour configurer une intégration avec Dotcom-Monitor, vous devez avoir accès à un compte Dotcom-Monitor actif et créer un identifiant Web API Unique à utiliser dans la demande d’authentification :

  1. Connectez-vous au compte Dotcom-Monitor.
  2. Dans Dotcom-Monitor, créez un UID d’intégration sous Configure > Integrations.

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.

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.