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 du site Web ou l’API Web nécessitant une authentification), nous vous recommandons de créer une cible par appareil.

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 périphérique de surveillance, en cas d’erreur, vous recevez une notification d’alerte qui identifie le nom du périphérique 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. Nous avons donc trois niveaux réels d’héritage, mais seulement deux niveaux (les niveaux Device et Task Name) présentés dans une notification d’alerte. Dans le cas où certains éléments Web répondent avec des erreurs, vous ne verrez que le nom de la tâche, mais pas les détails sur l’élément Web qui a provoqué une erreur.

Un autre élément à mentionner est que les tâches dans un appareil sont exécutées séquentiellement. Par exemple, supposons que vous ayez trois requêtes HTTP configurées en tant que tâches distinctes au sein du même appareil. En outre, chaque tâche a un délai d’achèvement de 120 secondes. Le système exécutera les tâches dans l’ordre dans lequel elles sont configurées dans l’appareil. Si le premier service cible cesse de répondre, une notification d’alerte ne sera envoyée qu’après six minutes à compter de la détection de l’erreur. Dans le cas de la configuration de chaque requête HTTP sous un périphérique distinct, la même alerte sera générée après deux minutes dans le cas où le périphérique associé signale une erreur.

Limites de la production de rapports

L’obtention d’un rapport élément par élément est également difficile dans le cas d’appareils multi-cibles. Étant donné que nos rapports Uptime, Performance, SLA et Online Dashboards s’exécutent au niveau de l’appareil, vous n’aurez aucune visibilité sur les tâches de surveillance. Par exemple, si l’une des URL cibles de votre appareil multi-cible génère une erreur, le périphérique sera marqué comme DOWN dans les rapports, quel que soit l’état des autres tâches dans 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. Toutefois, vous pouvez toujours trouver les performances cibles individuelles par tâches dans le rapport en ligne associé.

Augmentation du temps d’exécution

Une autre considération est liée à l’ordre séquentiel dans lequel Dotcom-Monitor exécute des tâches dans un périphérique de surveillance. Par exemple, si votre appareil est configuré pour surveiller toutes les minutes, mais que la première tâche de surveillance expire, la tâche suivante à partir de l’appareil peut ne pas être exécutée avant 5 à 10 minutes.