Dotcom-Monitor prend en charge l’ajout de plusieurs cibles sous le même périphérique (voir l’article Ajout de plusieurs cibles dans un seul périphérique pour plus de détails). Toutefois, à moins que les cibles ne soient étroitement liées et dépendent les unes des autres (par exemple, la surveillance des transactions de site Web ou l’API WEB qui nécessite une authentification), nous vous recommandons de créer une cible par appareil.

En un mot, toutes les alertes, les rapports et les tableaux de bord sont créés au niveau de l’appareil. Par exemple, les alertes sont déclenchées sur un état d’erreur de périphérique, mais pas sur une erreur détectée lors de l’exécution d’une tâche individuelle. En revanche, un périphérique de surveillance avec une seule tâche peut être configuré pour générer une notification d’alerte immédiatement chaque fois que le système détecte une erreur lors de l’exécution de la tâche et vous fournit des données de rapport détaillées élément par élément.

Si vous devez regrouper logiquement les périphériques de surveillance dans le service Dotcom-Monitor, utilisez le balisage au lieu de configurer un périphérique multi-cibles.

Limitations des alertes

Lorsque plusieurs cibles de surveillance sont configurées en tant que tâches distinctes sous le même appareil de surveillance, en cas d’erreur, vous recevrez une notification d’alerte qui identifiera le nom de l’appareil et le nom de la tâche ayant échoué. Cela semble suffisant, mais une tâche retourne généralement les résultats d’un certain nombre d’éléments Web dépendants. Ainsi, nous avons 3 niveaux réels d’héritage, mais seulement 2 niveaux (les niveaux Device et Task Name) présentés dans une notification d’alerte. Dans le cas où certains éléments web ont répondu par des erreurs, vous verrez uniquement le nom de la tâche, mais pas les détails sur l’élément web qui a provoqué une erreur.

Une autre chose à mentionner est que les tâches d’un appareil sont exécutées de manière séquentielle. En supposant que vous avez 3 requêtes HTTP configurées en tant que tâches distinctes au sein du même appareil. Chaque tâche a un délai d’exécution de 120 secondes. Le système exécutera les tâches dans l’ordre dans lequel elles ont été configurées dans l’appareil. Si le premier service cible cesse de répondre, avec une telle configuration, une notification d’alerte ne sera envoyée qu’après 6 minutes à compter de la détection d’erreur. Dans le cas de la configuration de chaque requête HTTP sous un appareil distinct, la même alerte sera générée après 2 minutes dès que l’appareil associé signale l’erreur.

Limites de la production de rapports

L’obtention d’un rapport élément par élément est également difficile dans le cas d’équipements multi-cibles. Étant donné que uptime, performance, rapports SLA et nos tableaux de bord en ligne s’exécutent au niveau de l’appareil, vous n’obtiendrez aucune visibilité sur les tâches de surveillance. Par exemple, si l’une des URL cibles de votre équipement multi-cibles génère une erreur, l’appareil sera marqué comme BAS dans les rapports, quel que soit l’état des autres tâches de l’appareil. Ainsi, en un coup d’œil, vous n’aurez pas d’informations complètes sur les performances réelles de chaque cible individuelle au sein de votre appareil multi-cibles. Cependant, vous pouvez toujours trouver la déstabilisation par des tâches dans le rapport en ligne associé.

Augmentation du temps d’exécution

Un autre problème est lié à l’ordre séquentiel des tâches dotcom-monitor exécute des tâches dans un périphérique de surveillance. Ainsi, si votre appareil est configuré pour surveiller toutes les minutes, mais que la première tâche de surveillance expire, la tâche suivante de l’appareil peut ne pas être exécutée pendant encore 5 à 10 minutes.