Saber cuándo algo falla en tu aplicación antes de que los usuarios lo noten es una ventaja competitiva enorme. New Relic ofrece un sistema de alertas robusto que permite configurar políticas sobre lo que estás monitoreando, notificarte a ti y a tu equipo en tiempo real, y actuar de inmediato. Comprender la estructura detrás de estas alertas es el primer paso para aprovecharlas al máximo.
¿Cuál es la anatomía de una alerta en New Relic?
Una alerta en New Relic es administrada por una política [0:08]. La política funciona como un contenedor que agrupa una o más alertas, y está compuesta por dos elementos fundamentales:
- Condiciones: definen qué situación debe ocurrir para disparar la alerta. Por ejemplo, que más del 0.1% de las transacciones estén recibiendo errores.
- Canales de notificación: determinan el medio por el cual se informa al equipo, ya sea por Slack, correo electrónico, webhooks o una aplicación móvil [1:48].
Cuando una condición se cumple y se cruza un umbral, se genera lo que se conoce como un issue o problema [1:08]. Este problema desencadena una notificación a través de un flujo de trabajo o workflow, que es el mecanismo encargado de avisar cuándo y cómo recibirás la notificación [1:30].
¿Cómo se ve una política de alerta en la práctica?
Imagina una política llamada "For Me Policy" [1:52]. Esta contiene una condición que indica: "más del 0.1% de las transacciones están recibiendo errores". Al cumplirse esa condición, se activa un workflow que envía la notificación al canal elegido. Lo importante es que, sin importar el medio, el usuario esté enterado de lo que sucede en su aplicación en todo momento.
¿Qué son las preferencias de incidentes y cómo funcionan?
Las preferencias de incidentes determinan con qué frecuencia y de qué forma se tomarán en cuenta los incidentes dentro de una política [2:20]. New Relic ofrece tres tipos:
¿Cuándo usar la preferencia por política, por condición o por incidente?
-
Por política (per policy): es la opción por defecto [2:32]. Se abre un solo incidente a la vez para toda la política. Resulta útil para combinar violaciones relacionadas en un único problema, lo que se traduce en recibir un solo correo con varios problemas agrupados. Esto te ahorra tiempo y te da una visión completa en una sola notificación [2:46].
-
Por condición (per condition): abre un incidente a la vez para cada condición contenida en la política [3:14]. Es ideal cuando tienes políticas con condiciones que se enfocan en entidades que realizan el mismo trabajo. Por ejemplo, si tienes hosts que sirven a las mismas aplicaciones y el CPU supera el 50% en cualquier host de un cluster denominado "Cluster ABC", varios incidentes se abren al mismo tiempo y se agrupan en un solo problema [3:38]. Recibirás una misma notificación con todos los problemas agrupados.
-
Por incidente (per incident): abre un incidente por cada infracción individual de la política [4:04]. Esto significa que recibirás un correo por cada violación que ocurra. Puede resultar abrumador porque no se agrupan las notificaciones y tu bandeja de entrada puede llenarse rápidamente. Sin embargo, es especialmente útil cuando tienes un proceso supercrítico detenido. Imagina que tu aplicación de ventas dejó de funcionar: necesitas ser notificado cada vez que sea necesario hasta que se resuelva el problema [4:30].
¿Cómo elegir la preferencia de incidente adecuada?
No existe una respuesta única. La elección depende de los requerimientos específicos de tu proyecto. Si necesitas una vista consolidada, la preferencia por política es tu mejor aliado. Si monitoreas entidades similares, opta por condición. Y si la criticidad del proceso lo exige, la notificación por incidente garantiza que nada pase desapercibido.
Antes de decidir, analiza el nivel de criticidad de cada componente de tu aplicación y el volumen de notificaciones que tu equipo puede gestionar sin perder efectividad. ¿Ya tienes configuradas alertas en tu proyecto? Comparte tu experiencia y cuéntanos qué preferencia de incidente te ha funcionado mejor.
