Estructura y Configuración de Alertas en New Relic
Clase 13 de 23 • Curso de Ingeniería en Observabilidad con New Relic
Resumen
¿Qué son las alertas en New Relic?
Las alertas en New Relic son una herramienta crucial que te permite mantener el control sobre el estado de tu aplicación. Este sistema está diseñado para notificarte cuando algo falla, permitiendo configuraciones detalladas para un monitoreo efectivo. Con New Relic, podrás anticipar problemas antes de que crezcan y afectar la experiencia del usuario final.
¿Cómo se estructuran las alertas?
Una alerta en New Relic es gestionada a través de una política. Esta política actúa como un contenedor para administrar una o más alertas, lo que facilita la organización y gestión de los monitoreos. Las políticas están compuestas por dos elementos principales:
-
Condiciones: Son las reglas que activan las alertas. Estas condiciones pueden monitorear métricas y definir umbrales que, al ser cruzados, generan un problema o "issue". Por ejemplo, si tu aplicación ejecuta menos de 10 transacciones por hora, puedes configurarlo para que te notifique, permitiéndote tomar medidas correctivas.
-
Canales de notificación: Son los medios a través de los cuales se te notificará sobre un problema. Puede ser por correo electrónico, mensajes en Slack, notificaciones móviles, entre otros.
¿Cuáles son los tipos de preferencias de incidentes?
New Relic ofrece distintos tipos de preferencias de incidentes que determinan la frecuencia y la manera en que se te notifica. Elegir la preferencia adecuada es clave para una gestión eficiente de incidentes. Aquí te presentamos los tres principales tipos:
-
Per Policy (Por política): Este es el tipo predeterminado. Se abre un incidente por toda la política, lo que permite combinar violaciones relacionadas en un solo reporte. Esto puede ser ventajoso, ya que varios problemas se pueden incluir en un único correo, ahorrándote tiempo y brindándote una visión consolidada de los problemas.
-
Per Condition (Por condición): Aquí se abre un incidente por cada condición dentro de la política. Esto es útil cuando se monitorean entidades que realizan la misma labor, por ejemplo, varios hosts que ejecutan la misma aplicación. Pueden generarse múltiples incidentes agrupados en un solo problema.
Ejemplo: Si el uso del CPU excede el 50% en cualquier host de un clúster denominado 'clúster ABC', se abrirán varias alertas individuales, las cuales se agruparán en un solo problema para notificación.
-
Per Incident (Por incidente): Se genera un nuevo incidente por cada violación detectada. Puede resultar abrumador si se genera un correo por cada problema, pero es útil para procesos críticos donde cada error necesita atención inmediata, como cuando el proceso esencial de una aplicación está detenido.
¿Cómo se aplica en la práctica?
Un ejemplo concreto de una política de alerta es "FoodMe Policy", diseñada para monitorear aplicaciones críticas como FoodMe App. En este caso, si más del 0,1% de las transacciones resultan en errores, esto activará una notificación de flujo de trabajo para asegurar que te enteres de inmediato y puedas actuar en consecuencia.
¿Por qué es importante elegir bien la preferencia de incidentes?
Al elegir una preferencia de incidentes adecuada, garantizas que el sistema de alertas sea eficiente y te brinde la información que realmente necesitas. Si no cuentas con la estrategia adecuada, puedes ser inundado con notificaciones, lo que puede provocar que incidentes importantes no reciban la atención que merecen. Por eso, analiza las necesidades específicas de tu negocio y tu aplicación para elegir la opción más conveniente.
Consejos prácticos para configurar alertas efectivas
- Personaliza las condiciones para cada tipo de monitoreo: No todas las aplicaciones o servicios son iguales. Ajusta las condiciones para reflejar verdaderamente lo que es crítico para ti.
- Selecciona los canales de notificación adecuados: Elige canales que sean efectivos para tu equipo, asegurando que las alertas se reciban y atiendan rápidamente.
- Revisa y ajusta las políticas regularmente: A medida que tu aplicación y la infraestructura evolucionan, también deberían hacerlo tus políticas de alerta.