Mi primera etiqueta

Un caso de uso común de alertas que pueden ser utilizadas en correlación, son las asociadas a un servidor o host en particular. Para esto se puede crear una etiqueta que marque todas las alertas con algún valor dentro de su variable personalizada "host".

Como primer paso, no es necesario seleccionar el flujo específico donde la alerta debe ser recibida, con lo que tendríamos la siguiente configuracion:

Para más detalles, revisar la sección del etiquetador.

Mi primer transformador

Siguiendo el mismo caso, ahora queremos agregar un campo generalizado a todas las alertas de tipo Host para facilitar su filtrado o categorización posterior.

Los transformadores nos permiten realizar exactamente esto, como en el siguiente ejemplo:

Este transformador agregara el campo "area_encargada"="Infraestructura" a cualquier alerta recibida que se etiquete como "DOC-Host".

Los transformadores no solo nos permiten agregar o modificar los campos personalizados de la alerta, si no que tambien pueden ser usados para asignar el servicio/flujo de notificación de una alerta. Dando la posibilidad de crear enrutamiento de notificaciones en base a etiquetas.

Para más detalles, revisar la seccion especifica del Transformador

Mi primera lógica de negocio

Existen multiples razones por las que un host o servidor puede generar alertas: error de PING, uso de memoria o CPU, espacio en disco, etc.

Si como administrador nos interesa saber si el host esta funcionando correctamente o no, independiente del problema especifico. Para ello podemos crear una logica de negocio que agrupe todas las alertas de un mismo host y nos entregue el estado global de este.

Un ejemplo de configuración que logra esto, sería:

• Agrupa cualquier evento con la etiqueta DOC-Host y, en base al campo personalizado del nombre "host" que ésta incluya se asignará automáticamente a un elemento de lógica de negocio.

• Si existen 1 o más componentes hijos en estado CRITICAL, la lógica de negocio también pasará a estado CRITICAL. Por lo tanto cualquier alerta, nos informara de un problema global del host X.

• Ante un cambio de estado, se enviará una alerta al flujo 24Cevent alertas_infraestructura.

Para más detalles, revisar la seccion especifica de las Logicas de negocio

Ejemplo de alerta

Con esto ya tenemos un flujo completo de correlación listo para procesar alertas. Si enviamos la siguiente alerta a 24Cevent:

 { "access_token": "AGREGAR_API_TOKEN", "message": "Memoria utilizada en servidor es mayor al 95%", "servicio": "alertas_generales", "external_id": "host001_ram", "criticidad": "critical", "custom": { "host": "host001", "domain": "test.com", "timestamp": 1782296701, "random": 986542 } } 

Podemos ver que el detalle de la alerta (en la vista de Operación) incluye el campo extra agregado por nuestro transformador:

Y que la Página de Estado muestra la lógica de negocio DOC-Logica Hosts - host001 creada automaticamente para agrupar cualquier problema del host001 gracias a la configuracion con discriminador.