Este glosario define los términos del sistema de gestión de alertas de Application Real-Time Monitoring Service (ARMS).
Funcionamiento de la gestión de alertas
El sistema de gestión de alertas procesa los datos de monitoreo mediante un flujo de trabajo:
Una integración conecta un producto de monitoreo con el sistema de gestión de alertas.
El producto de monitoreo detecta un fallo (una anomalía en los datos de monitoreo) y envía un evento al sistema.
El sistema aplica reglas de deduplicación de eventos, agrupación de eventos y silenciamiento de eventos para reducir el ruido.
Una política de notificación evalúa los eventos y crea una alerta para aquellos que requieren resolución.
El sistema envía una notificación a los contactos asignados mediante los canales configurados.
Si nadie confirma o resuelve la alerta dentro del tiempo de espera de escalado, la política de escalado notifica a contactos adicionales.
Un contacto puede asignarse la alerta para asumir su responsabilidad, o bien el sistema puede resolver automáticamente la alerta cuando se recuperan todos los eventos relacionados.
Términos principales
|
Término |
Definición |
|
Alerta |
Evento que requiere la intervención de un contacto para resolverse. Las alertas solo se crean para eventos desencadenados por una política de notificación que necesitan resolución. |
|
Tarjeta de alerta |
Alerta con formato de tarjeta enviada por un chatbot en un grupo de DingTalk. Los contactos pueden consultar, gestionar y resolver alertas directamente desde la tarjeta. Configure el chatbot en la consola de ARMS. |
|
Sistema de gestión de alertas |
Función de gestión de alertas disponible en ARMS. |
|
Resolución automática de alertas |
Cuando se recuperan todos los eventos relacionados con una alerta, el sistema establece automáticamente el estado de la alerta como Resolved. |
|
Asignación de alerta |
Acción mediante la cual un contacto asume la responsabilidad de una alerta no resuelta y se convierte en su gestor. |
|
Fallo |
Anomalía en los datos de monitoreo que puede deberse a reglas de negocio. Cuando una herramienta de monitoreo detecta una anomalía, genera un evento. |
Términos de gestión de eventos
|
Término |
Definición |
|
Evento |
Registro enviado desde un producto de monitoreo integrado al sistema de gestión de alertas. Se crea una alerta por cada evento, a menos que este se suprima. |
|
Deduplicación de eventos |
Fusiona eventos duplicados provenientes de una integración en un solo evento. Solo se contabiliza el número de ocurrencias. |
|
Agrupación de eventos |
Consolida varios eventos relacionados en una única alerta. Esto reduce la cantidad de alertas que gestionan los contactos y resume la información clave para minimizar la fatiga por notificaciones. |
|
Silenciamiento de eventos |
Evita que se creen alertas para eventos específicos y poco relevantes. |
|
Recuperación automática de eventos |
Resuelve automáticamente un evento después de un periodo especificado. El periodo de recuperación predeterminado es de 5 minutos. |
Términos de notificación y escalado
|
Término |
Definición |
|
Contacto |
Ingeniero de operaciones y mantenimiento (O&M) encargado de gestionar alertas. Los contactos pueden consultar, gestionar y resolver alertas mediante DingTalk. |
|
Política de escalado |
Conjunto de reglas que define a qué contactos notificar y en qué orden cuando una alerta no se confirma ni se resuelve dentro del tiempo de espera de escalado. Es posible agregar una política de escalado a una política de notificación. |
|
Tiempo de espera de escalado |
Periodo tras el cual el sistema notifica a los contactos definidos en la política de escalado sobre alertas no confirmadas o no resueltas. Valor predeterminado: 10 minutos. Valor máximo: 90 minutos. |
|
Integración |
Proceso de conexión de un producto de monitoreo con el sistema de gestión de alertas, generalmente mediante API. La mayoría de los productos de monitoreo admiten integración. |
|
Notificación |
Mensaje enviado a los contactos cuando se activa una alerta. El mensaje contiene el objeto y el título de la alerta. Canales disponibles: mensaje de texto, correo electrónico, WeChat, grupo de DingTalk o webhook. |
|
Política de notificación |
Política que determina cómo consolidar eventos en alertas y cómo notificar a los contactos. Canales: llamada telefónica, mensaje de texto, correo electrónico o grupo de DingTalk. Los contactos reciben la notificación en un plazo de un minuto cuando surge una alerta que requiere resolución o atención. |
|
Reglas de repetición de escalado |
Si una alerta sigue sin resolverse después de que la política de escalado haya procesado todas sus reglas, el proceso de escalado se reinicia. Valor predeterminado: se repite una vez. Valor máximo: 9 veces. |
|
Usuario |
Cuenta de Alibaba Cloud o usuario de Resource Access Management (RAM). Los usuarios pueden crear, editar y modificar políticas de notificación, políticas de escalado e integraciones; también pueden consultar, gestionar y resolver alertas en la consola de ARMS. |
Términos de comparación de datos
Las reglas de alerta de ARMS admiten tres tipos de comparación de datos. Cada una compara los datos de una ventana de tiempo reciente con los de una ventana anterior. El valor comparado puede ser un promedio, una suma, un máximo o un mínimo.
|
Término |
Lógica de comparación |
|
Incremento/decremento respecto al periodo anterior (%) |
Compara los datos de los últimos N minutos (β) con los datos de los N minutos previos (α), es decir, el periodo comprendido entre hace 2N y N minutos. |
|
Incremento/decremento respecto a la hora anterior (%) |
Compara los datos de los últimos N minutos (β) con los datos de la misma ventana de N minutos en la hora anterior (α). |
|
Incremento/decremento respecto al día anterior (%) |
Compara los datos de los últimos N minutos (β) con los datos de la misma ventana de N minutos del día anterior (α). |
Política de corrección de datos de alertas
Cuando faltan datos de alertas o no es posible calcularlos, ARMS aplica una política de corrección para completar la información y evitar que se pasen por alto alertas importantes. Esta política cubre tres tipos de anomalías en los datos: datos faltantes, indicadores compuestos incalculables y comparaciones respecto al periodo anterior incalculables.
Opciones de corrección
|
Opción |
Comportamiento |
|
Fill with 0 |
Establece el valor faltante o incalculable en 0. |
|
Fill with 1 |
Establece el valor faltante o incalculable en 1. |
|
Fill with null (predeterminado) |
No se inserta ningún valor. La alerta no se activa. |
Escenarios
A continuación se presentan ejemplos que muestran cuándo aplica cada opción de corrección.
Datos faltantes
Una regla de alerta monitorea las vistas de página mediante Browser Monitoring y se activa si el total de vistas cae a 10 o menos dentro de un periodo (N=5). Si nadie visita la página, no se reportan datos y la alerta no se activa. Seleccione Fill with 0 para tratar la ausencia de datos como cero, lo cual cumple la condición de la alerta.
Indicador compuesto incalculable
Una regla de alerta monitorea el precio unitario en tiempo real de un producto mediante monitoreo personalizado. La variable a representa el precio total actual y la variable b representa la cantidad total actual de artículos. La regla se activa si el valor mínimo de a/b cae a 10 o menos dentro de un periodo (N=3). Si la cantidad total de artículos es 0, la división no se puede calcular y la alerta no se activa. Seleccione Fill with 0 para tratar el valor del indicador compuesto como 0, lo cual cumple la condición de la alerta.
Comparación respecto al periodo anterior incalculable
Una regla de alerta monitorea el uso de CPU mediante Application Monitoring y se activa si el uso promedio de CPU disminuye un 100 % respecto al periodo anterior dentro de un periodo (N=3). Si la CPU falla durante los últimos N minutos, no hay datos disponibles para el periodo actual y no es posible calcular el resultado de la comparación. Seleccione Fill with 1 para tratar el resultado de la comparación como una disminución del 100 %, lo cual cumple la condición de la alerta.