Alertas
Las alertas notifican a los operadores del sistema cuando ocurren ciertos eventos importantes o se alcanza un estado valioso en cualquier parte de una solución de IoT distribuida. Se aseguran de que los operadores se den cuenta de lo que deben observar sin moverse por el sistema para realizar revisiones periódicas.
Una alerta comprende:
| Triggers | Reglas de escalamiento |
| Reglas de notificación | Acciones correctivas |
Triggers de alerta
Cada alerta tiene uno o más factores desencadenantes que definen cuando aumentarlo. Estos pueden ser desencadenantes de evento o desencadenantes de estado.
Cada Trigger puede verificar uno o más dispositivos o recursos, por ejemplo, todos los dispositivos en un grupo. Combinado con la capacidad de configurar múltiples Triggers por alerta, esto permite una configuración muy flexible.
Triggers de eventos
Se activa un desencadenador de evento cuando un evento de un tipo en particular se ajusta a la condición de desencadenante. Esta condición se configura de manera flexible mediante una expresión, lo que permite una verificación compleja. Por ejemplo, un sistema de monitoreo de vehículo puede generar una alerta si el evento de "impacto" recibido desde un controlador de vehículo indica que la fuerza de impacto excede un umbral.
Los Triggers de eventos tienen soporte para la correlación de eventos, lo que permite que una alerta sea activada por el evento de un tipo y desactivada por el evento de otro tipo (evento correlacionado).
Cualquier Trigger de evento puede configurarse para activarse sólo si se produce una secuencia de eventos similares dentro de un marco de tiempo determinado.
Triggers de estado
Un Trigger de estado puede aumentarse en respuesta a un determinado estado o cualquier cambio en el estado de lo que se supervisa. Un Trigger de estado comprueba periódicamente el valor de la variable específica (también apuntada por una expresión personalizada).
Los Triggers de estado tienen un tiempo de histéresis configurable (banda muerta) para activar la alerta sólo si la condición dura más que un cierto período de tiempo. Por ejemplo, un gatillo de estado puede generar una alerta si la temperatura aumenta más de 120 grados durante más de 3 minutos. La histéresis de rearme separada también es compatible.
Las condiciones de los factores desencadenantes del estado se pueden comparar con las líneas base ajustadas dinámicamente, como el promedio mensual o el máximo del fin de semana. Además, los Triggers de estado admiten la detección de aleteo de valor (cambio frecuente) que se informa como un tipo de alerta por separado.
Reglas de notificación
Las notificaciones de alerta informan a los operadores sobre las condiciones de alerta y brindan información relacionada. Los tipos de notificación incluyen:
- Mensajes emergentes al operador (también pueden solicitar confirmación)
- Sonidos personalizados
- Notificaciones de Correo Electrónico. Las alertas pueden reconocerse respondiendo a los correos electrónicos de notificación
- Notificaciones por SMS
- Cualquier otro método de entrega de notificaciones, cómo enviar un mensaje de Skype o WhatsApp a través de una aplicación externa
Además, las acciones correctivas de alerta pueden implementar cualquier otro esquema de notificación.
Alertas activas
Una vez planteada una alerta,puede permanecer activa mientras su condición causante esté en vigencia o hasta que se reciba un evento correlacionado con el evento de activación. El servidor mantiene la lista de alerta activa global y rastrea las instancias activas asociadas a cada recurso y dispositivo. Las alertas activas con alta prioridad generalmente se visualizan en los paneles de descripción general del sistema.
Alertas pendientes y escaladas de alerta
Algunas alertas requieren reconocimientos. Las instancias de alerta no reconocidas se llaman alertas pendientes, y tales alertas se resaltan para atraer la atención del operador.
La escalada de alerta generalmente indica que la situación se ha vuelto crítica. Las alertas escaladas se resaltan en rojo. Hay dos reglas posibles para aumentar las alertas:
- La escalada basada en la cantidad ocurre cuando un número de alertas pendientes no reconocidas excede un cierto umbral
- La escalada basada en el tiempo se activa cuando una de las instancias de alerta pendientes no es reconocida dentro de un período de tiempo determinado
Ambos tipos de escalamiento pueden combinarse para una sola alerta.
Acciones correctivas
Cuando ocurre un cierto error, a menudo requiere un remedio específico. Por ejemplo, cuando la memoria disponible en un dispositivo se reduce, su base de datos interna debe descargarse o purgarse. Éste es siempre el caso: nunca es otra acción, cómo apagar el dispositivo o ejecutar un servo.
Debido a que es tan predecible, puede ser automatizado. Cualquier acción del sistema que esté disponible en la interfaz de usuario se puede iniciar automáticamente en respuesta a una alerta.
Si no hay operadores en servicio o las funciones del sistema están en modo independiente, la acción correctiva lanzada es "no interactiva" (también llamada "automática" o "sin cabeza"). También hay acciones correctivas "interactivas" que requieren la entrada del operador en tiempo real.
Algunas acciones correctivas interactivas:
- Iniciar un flujo de trabajo de resolución de incidentes dirigido por el operador personalizado
- Ejecutar una purga de base de datos, preguntando primero al operador: "¿Estás seguro?"
- Reiniciar un dispositivo de misión crítica solo después de recibir la confirmación del operador
Algunas acciones correctivas automáticas:
- Preparar un informe de estado sobre el dispositivo que causa una alerta y enviarlo por correo electrónico
- Ejecutando una aplicación externa que arregla el problema
- Crear un nuevo ticket en el sistema de Service Desk
