Application Real-Time Monitoring Service:Políticas de notificación

Requisitos previos

Ya creó los destinatarios de notificación. Para obtener más información, consulte Manage notification recipients.

Crear una política de notificación

1. Inicie sesión en la consola de ARMS. En el panel de navegación izquierdo, seleccione Alert Management > Notification Policies.

2. En la página Notification Policies, haga clic en Create Notification Policy.

3. En la parte superior de la página Create Notification Policy, introduzca un nombre para la política.

4. En la sección Matching Rule, defina las reglas de coincidencia para los eventos de alerta.

   Importante

   Una política de silencio tiene prioridad sobre una política de notificación. Si un evento de alerta coincide con una política de silencio, se silencia y no se evalúa contra ninguna política de notificación. Para crear una política de silencio, consulte Silence policies.

   1. Seleccione un origen de datos.

      <!--@div {"id":"info_h7b_azv_s3w","data-tag="info"}-->

      • Specific source: filtra los eventos de alerta de una integración específica.

      • No preset source: filtra los eventos de alerta de todas las integraciones.

   2. Establezca las expresiones de las reglas de coincidencia. Puede usar etiquetas personalizadas o seleccionar entre las etiquetas existentes.

      Las etiquetas existentes incluyen:

      • Etiquetas de las métricas en una expresión de regla de alerta. Para conocer cómo crear etiquetas para una regla de alerta de Managed Service for Prometheus, consulte Create a Prometheus alert rule.

      • El sistema ARMS proporciona las siguientes etiquetas predeterminadas.

        Categoría	Etiqueta	Descripción
        Campos comunes	alertname	Nombre de la alerta.
        	clustername	Nombre del clúster.
        	severity	Nivel de gravedad: P1 P2 P3 P4 Default
        	namespace	namespace.
        	pod_name	Nombre del Pod.
        Campos predefinidos del sistema	_aliyun_arms_integration_name	Nombre de la integración. El nombre de integración predeterminado para las alertas reportadas por ARMS es ARMS-DEFAULT.
        	_aliyun_arms_involvedObject_id	ID del objeto de la alerta.
        	_aliyun_arms_involvedObject_name	Nombre del objeto de la alerta.
        	_aliyun_arms_region_id	ID de la región.
        	_aliyun_arms_alert_rule_id	ID de la regla de alerta.
        	_aliyun_arms_alert_type	Tipo de regla de alerta: 101: alerta de Prometheus 5: alerta de Application Monitoring 4: alerta de Browser Monitoring
        Otros campos	_arms_contact_group_v2_id	ID del grupo de contactos (v2) para las notificaciones de alerta. ARMS añade esta etiqueta automáticamente a las etiquetas del evento de alerta. Su valor corresponde al identificador del grupo de contactos v2 que se muestra en la página Alarm Management > Notification Objects > Contact Group de la consola. Cuando se crea automáticamente una política de notificación mediante la integración con ACK, esta etiqueta se utiliza para hacer coincidir la política sin necesidad de configuración manual. Esta etiqueta difiere de ContactGroupId de v1 que devuelve la API. Es visible en el campo commonLabels de la carga útil de la notificación del webhook.

      Comportamiento de visualización de etiquetas

      Las etiquetas que se muestran en la página de análisis de eventos de alerta provienen de las etiquetas de métricas de la regla de alerta activada y de los campos predefinidos del sistema. Distintos eventos de alerta pueden contener diferentes campos de etiqueta, ya que las reglas involucradas se asocian con distintas métricas y tipos de recursos. Si un evento no incluye un campo determinado, no mostrará esa etiqueta. Por lo tanto, algunas etiquetas aparecen en un evento y no en otro; este es el comportamiento esperado y no un error del sistema.

      Por ejemplo, un evento incluye la etiqueta pod_name solo cuando la alerta involucra un recurso Pod. Las alertas que no involucran un Pod no muestran esta etiqueta.

      Nota

      • Para exigir que una alerta coincida con todas las condiciones de una regla (lógica AND), haga clic en Add Condition.

      • Para exigir que una alerta coincida con cualquier regla (lógica OR), haga clic en Add Rule para crear una nueva regla.

      • El tamaño total de configuración de todas las reglas de coincidencia en una política de notificación no puede superar los 64 KB. Este límite admite aproximadamente 100 reglas, según su complejidad. Si se supera, la configuración fallará. Para evitarlo, cree una nueva política de notificación para las reglas adicionales.

      Nota

      Cuando una política de notificación contiene reglas de coincidencia basadas en dimensiones de clúster u objeto —por ejemplo, al usar la etiqueta _aliyun_arms_involvedObject_id para coincidir con el ID de un clúster de Kubernetes—, las reglas de alerta asociadas con ese clúster u objeto se vinculan automáticamente a la política de notificación. No necesita configurar una política de notificación en cada regla de alerta individual.

      Esto resulta especialmente útil en escenarios masivos, como las reglas de alerta creadas automáticamente por Container Service for Kubernetes (ACK). Solo necesita configurar reglas de coincidencia basadas en etiquetas en la política de notificación para asociar automáticamente todas las reglas de alerta relevantes a la vez, sin editarlas una por una.

      Las reglas de alerta creadas automáticamente por un clúster de ACK incluyen la etiqueta generada por el sistema _arms_contact_group_v2_id, cuyo valor es un ID de grupo de contactos. Las políticas de notificación usan esta etiqueta para hacer coincidir las reglas y enrutar las notificaciones de alerta al grupo de contactos especificado. El valor de la etiqueta corresponde al ID del grupo de contactos que se muestra en la página Alarm Management > Notification Objects > Contact Group de la consola de ARMS. El sistema genera esta etiqueta automáticamente y no es necesario añadirla de forma manual.

   3. Haga clic en Next.

5. En la sección Event Group, configure cómo se agrupan los eventos de alerta y luego haga clic en Next.

   • Do not group: cada evento de alerta se envía como una notificación independiente.

   • Set grouping fields: agrupa en una sola notificación los eventos de alerta que tienen valores idénticos en los campos especificados.

6. En la sección Notification Objects, configure los siguientes parámetros.

   1. Haga clic en +Add Notification Recipient para seleccionar un destinatario de notificación.

      Tipos de destinatarios de notificación:

      • Contact: también debe seleccionar un método de notificación (llamada telefónica, mensaje de texto o correo electrónico) para el contacto seleccionado.

      • Contact Group: también debe seleccionar un método de notificación (llamada telefónica, mensaje de texto o correo electrónico) para el grupo de contactos seleccionado.

      • On-call Schedule: también debe seleccionar un método de notificación (llamada telefónica, mensaje de texto o correo electrónico) para el calendario de guardias seleccionado.

      • DingTalk/Lark/WeCom: envía notificaciones a un canal de DingTalk, Lark o WeCom.

      • General Webhook: envía notificaciones a una URL de webhook específica.

   2. Seleccione si desea enviar una notificación de recuperación después de resolver una alerta.

      Send recovery notification: cuando se habilita, se envía una notificación de recuperación después de resolver todos los eventos de una alerta. Luego, la alerta se marca automáticamente como Resolved.

   3. Establezca una plantilla de notificación. Para obtener más información, consulte Configure notification and webhook templates.

   4. Defina un periodo de notificación para enviar alertas únicamente dentro de la ventana de tiempo especificada.

   5. Opcional: Seleccione un sistema de tickets al cual enviar las alertas. Para obtener detalles sobre cómo integrar un sistema de tickets, consulte Integrations.

   6. Haga clic en Next.

7. En la sección Repeat/Escalate/Recover Policy, configure si desea repetir las notificaciones o usar una política de escalamiento para una alerta, y luego haga clic en Next.

   • Repetir notificaciones para una alerta: cuando se habilita, las notificaciones de las alertas no resueltas se reenvían con la frecuencia especificada hasta que se resuelve la alerta.

   • Política de escalamiento:

     Si selecciona No escalation policy, la notificación se envía solo una vez para una alerta no resuelta.

     Si selecciona Use escalation policy, la notificación se envía a otros destinatarios según la política de escalamiento.

   • Recuperación manual: cuando se habilita, las alertas no se resuelven automáticamente, incluso si no se activan nuevos eventos durante el periodo de recuperación automática de la integración. Debe resolver estas alertas de forma manual.

8. En la sección Action Integration, configure las acciones automatizadas que se ejecutan cuando se activa o se resuelve una alerta. Para obtener más información, consulte Execute an alert plan by using an ARMS action integration.

9. Haga clic en Save para crear la política.

Gestionar políticas de notificación

Después de crear una política de notificación, esta se muestra en la página Notification Policies. En la página Notification Policies, puede realizar las siguientes operaciones:

• Editar una política de notificación: haga clic en el nombre de la política o en Edit en la columna Actions. Después de aplicar los cambios, haga clic en Save.

• Habilitar o deshabilitar una política de notificación: en la columna Status, active o desactive el interruptor.

• Eliminar una política de notificación: haga clic en Delete en la columna Actions y luego en Confirm.

• Copiar una política de notificación: haga clic en Copy en la columna Actions para duplicar la política.

Preguntas frecuentes

P: ¿Cómo configuro distintos métodos de notificación para diferentes niveles de gravedad de alerta dentro de una misma política de notificación?

R: Puede añadir varias Actions dentro de la misma política de notificación para implementar notificaciones diferenciadas. Para cada acción, configure sus condiciones de coincidencia (por ejemplo, gravedad P1 o P2) y seleccione el canal de notificación correspondiente (por ejemplo, llamada telefónica o grupo de DingTalk). Este enfoque elimina la necesidad de crear una política de notificación independiente para cada nivel de gravedad.

P: ¿Por qué el intervalo real de notificación difiere del intervalo de repetición configurado?

R: El intervalo real de notificación se ve afectado por varios factores superpuestos:

• Ciclo de comprobación de alertas de Prometheus: de forma predeterminada, Prometheus comprueba las alertas cada 1 minuto.

• Mecanismo "Check after data is complete": este mecanismo está habilitado de forma predeterminada. Añade tiempo de procesamiento adicional para garantizar que los datos de alerta estén completamente disponibles antes de que el sistema evalúe nuevos eventos.

• Retraso por agregación de eventos y procesamiento del sistema: se produce un retraso adicional durante la agregación de eventos y el procesamiento posterior.

Debido a estos efectos acumulativos, el intervalo real puede ser mayor que el valor configurado. Por ejemplo, un intervalo configurado de 1 minuto puede dar como resultado un intervalo efectivo de 3 minutos.

Además, las notificaciones de recuperación se recalculan con base en la marca de tiempo del último evento de alerta. Si las alertas se siguen activando, las notificaciones de recuperación se retrasarán en consecuencia.

P: ¿Se puede eliminar el ID de usuario de Alibaba Cloud que aparece al final de los mensajes SMS de alerta de ARMS?

R: No. El texto "This message was configured in ARMS by Alibaba Cloud user: xxxxxx" es un formato fijo del sistema y no se puede eliminar mediante configuración.