Dotcom-Monitor admite la adición de varios destinos en el mismo dispositivo (consulte el artículo Adición de varios destinos dentro de un solo dispositivo para obtener más detalles). Sin embargo, a menos que los destinos estén estrechamente relacionados y dependa unos de otros (por ejemplo, la supervisión de las transacciones del sitio web o la API web que requiere autenticación), le recomendamos que cree un destino por dispositivo.

En pocas palabras, todas las alertas, informes y paneles se crean en el nivel de dispositivo. Por ejemplo, las alertas se desencadenan en un estado de error de dispositivo, pero no en un error detectado al ejecutar una tarea individual. Por el contrario, un dispositivo de supervisión con una sola tarea se puede configurar para generar una notificación de alerta inmediatamente cada vez que el sistema detecta un error al ejecutar la tarea y le proporciona datos detallados de informe elemento por elemento.

Si necesita agrupar lógicamente los dispositivos de supervisión dentro del servicio Dotcom-Monitor, use el etiquetado en lugar de configurar un dispositivo de varios objetivos.

Limitaciones de alertas

Cuando tenga varios destinos de supervisión configurados como tareas independientes en el mismo dispositivo de supervisión, en caso de error recibirá una notificación de alerta que identificará el nombre del dispositivo y el nombre de la tarea con errores. Parece suficiente, sin embargo, una tarea normalmente devuelve resultados de una serie de elementos web dependientes. Por lo tanto, tenemos 3 niveles reales de herencia, pero solo 2 niveles (los niveles de dispositivo y nombre de tarea) presentados en una notificación de alerta. En el caso de que algunos de los elementos web respondieran con errores, solo verá el nombre de la tarea, pero no los detalles en el elemento web que produjo un error.

Una cosa más a mencionar es que las tareas en un dispositivo se ejecutan secuencialmente. Suponiendo que tiene 3 solicitudes HTTP configuradas como tareas independientes dentro del mismo dispositivo. Cada tarea tiene un tiempo de espera de finalización de 120 segundos. El sistema ejecutará las tareas en el orden en que se configuraron en el dispositivo. Si el primer servicio de destino deja de responder, con dicha configuración se enviará una notificación de alerta solo después de 6 minutos desde la detección de errores. En el caso de configurar cada solicitud HTTP en un dispositivo independiente, se generará la misma alerta después de 2 minutos tan pronto como el dispositivo relacionado informe del error.

Limitaciones de informes

Obtener un informe elemento por elemento también es un desafío en el caso de los dispositivos multi-objetivo. Dado que el tiempo de actividad, el rendimiento, los informes de SLA y nuestros paneles en línea se ejecutan en el nivel de dispositivo, no obtendrá ninguna visibilidad de las tareas de supervisión. Por ejemplo, si una de las direcciones URL de destino de su dispositivo de varios objetivos genera un error, el dispositivo se marcará como DOWN en los informes, independientemente del estado de otras tareas en el dispositivo. Por lo tanto, de un vistazo, no tendrá información completa sobre el rendimiento real de cada objetivo individual dentro de su dispositivo multi-objetivo. Sin embargo, todavía puede encontrar la desestabilización por tareas en el informe en línea relacionado.

Aumento del tiempo de ejecución

Otro problema está relacionado con el orden secuencial dotcom-monitor ejecuta tareas en un dispositivo de monitoreo. Por lo tanto, si tiene su dispositivo configurado para monitorear cada minuto, pero la primera tarea de monitoreo es el tiempo de espera, es posible que la siguiente tarea desde el dispositivo no se ejecute durante otros 5-10 minutos.