Anatomía de alertas y políticas en New Relic

Las alertas en New Relic te avisan cuando algo está fallando en tu aplicación y te permiten configurar políticas sobre lo que monitoreas. Aquí entenderás la anatomía completa: qué es una política, cómo se construyen las condiciones, qué disparan los incidentes y cuál preferencia elegir según tu caso. Es contenido pensado para quienes administran observabilidad y necesitan decidir cómo recibir notificaciones sin saturar al equipo.

¿Qué es una alerta en New Relic y cómo se estructura?

Una alerta es administrada por una policy, que funciona como contenedor de una o más alertas. Esa política se compone de dos piezas que trabajan en conjunto: las condiciones y los canales de notificación.

Las condiciones definen el mensaje que quieres que llegue al usuario cuando algo se sale de lo normal. Los canales son el medio por donde llega ese aviso, ya sea Slack, email, webhooks o una app móvil. Sin uno no funciona el otro.

¿Qué es una política de alerta? Es un contenedor que agrupa una o más condiciones de monitoreo y define cómo se notifica cuando se cruza un umbral.

¿Cuándo se convierte una condición en un issue?

Cuando se cruza el umbral que definiste en una condición, New Relic abre un issue o problema [01:13]. Por ejemplo, si quieres ser notificado cuando ocurran menos de 10 transacciones por hora en tu aplicación, ese es el umbral que dispara el problema.

Un problema, a su vez, desencadena un workflow o flujo de trabajo que se encarga de enterar a tu equipo. Piénsalo así: la condición detecta, el issue registra y el workflow avisa.

¿Cómo se ve una política de alerta en la práctica?

Imagina una política llamada Form Policy con una condición que dice: más del 0.1% de las transacciones están recibiendo errores [02:14]. Ese cruce de umbral abre un issue y dispara el workflow, que decide cuándo y por dónde te notifica.

El medio puede ser email, Slack, webhooks o una aplicación móvil. Lo central es que como usuario te enteres de lo que está pasando en tu aplicación.

¿Qué son las preferencias de incidentes y cuál elegir?

Las preferencias de incidentes determinan qué tan seguido se toma en cuenta un incidente dentro de una póliza [02:53]. New Relic ofrece tres tipos y cada uno responde a una necesidad distinta.

• Per policy: la opción por defecto.
• Per condition: una por cada condición contenida.
• Per incident: una por cada infracción individual.

Elegir bien depende del nivel de criticidad y del volumen de notificaciones que tu equipo puede manejar sin saturarse.

¿Cómo funciona la preferencia per policy?

Es la opción que New Relic usa por defecto. Abre un solo incidente a la vez para toda la póliza, lo que la hace útil para combinar violaciones relacionadas dentro de un mismo incidente.

En la práctica, recibes un correo que puede incluir varios problemas ocurriendo al mismo tiempo. Si se cumplen una o más condiciones, todo se agrupa en una sola notificación. Esto ahorra tiempo y evita el ruido innecesario en tu bandeja.

¿Cuándo conviene per condition y per incident?

La preferencia per condition abre un incidente a la vez por cada condición contenida en la póliza. Es útil cuando tienes condiciones enfocadas en entidades que hacen el mismo trabajo, como hosts que sirven a las mismas aplicaciones.

Un ejemplo claro: una condición que vigila si el CPU supera el 50% en cualquier host dentro de un cluster llamado cluster ABC [03:37]. Varios incidentes se abren al mismo tiempo y se agrupan en un solo problema, así recibes una notificación con todos los casos juntos.

La preferencia per incident es la más peculiar: abre un incidente por cada infracción de la política. Eso significa un correo por cada violación que ocurra, sin agrupación.

¿Cuándo usar per incident en New Relic? Cuando tienes un proceso crítico que no puede caerse, como ventas en producción. Necesitas saber de cada violación al instante, aunque sature la bandeja.

Piensa en una app como Food Me que deja de vender: ese es el corazón del negocio y necesita ser notificado cada vez que falle hasta que se resuelva. Aquí per incident deja de ser abrumador y se vuelve indispensable.

Antes de descartar cualquier preferencia, analiza los requerimientos reales de tu aplicación y decide cuál se ajusta mejor al riesgo que estás dispuesto a tolerar. ¿Qué preferencia usas tú en tus políticas? Cuéntame en los comentarios.