Condición de alerta

Puede utilizar una consulta NRQL para definir las señales que desea que utilice una condición de alerta como base para su alerta. Para este ejemplo, utilizará esta consulta:

SELECT average(duration)
FROM PageView
WHERE appName = 'WebPortal'

El uso de esta consulta para su condición de alerta le indica a New Relic que desea conocer la latencia o duración promedio para cargar páginas dentro de su aplicación WebPortal . Las alertas proactivas sobre latencia, una de las principales señales doradas, proporcionan alertas tempranas de posible degradación.

Puede obtener más información sobre cómo utilizar NRQL, el lenguaje de consulta de New Relic, consulte nuestra documentación de NRQL.

La duración de la ventana define cómo New Relic agrupa sus datos para su análisis en una condición de alerta. Elegir la configuración correcta depende de la frecuencia de sus datos y del nivel de detalle deseado:

• High-frequency data (for example, pageviews every minute): establezca la duración de la ventana para que coincida con la frecuencia de los datos (1 minuto en este caso) para obtener Insights en tiempo real sobre fluctuaciones y tendencias.

• Low-frequency data (for example, hourly signals): elija una duración de ventana que capture suficientes datos para revelar patrones y anomalías (por ejemplo, 60 minutos para señales horarias).

  Recuerde, puede personalizar la duración de la ventana según sus necesidades y experiencia. Recomendamos utilizar los valores predeterminados al iniciar y experimentar a medida que se sienta más cómodo creando condiciones de alerta.

Los métodos de agregación tradicionales pueden resultar insuficientes cuando se trata de datos escasamente poblados o que muestran fluctuaciones significativas entre intervalos. A continuación se explica cómo utilizar la agregación de ventanas deslizantes para analizar dichos datos y activar alertas oportunas de manera efectiva:

1. Smooth out the noise: Comience creando una ventana de agregación grande. Esta ventana (por ejemplo, 5 minutos) actúa como un búfer, suavizando el "ruido" inherente o la variabilidad de sus datos. Esto ayuda a prevenir alertas espurias provocadas por picos o caídas aisladas.

2. Avoid lag with a sliding window: Si bien una ventana grande ayuda en el análisis de datos, si espera a que transcurra todo el intervalo antes de verificar el umbral, puede experimentar retrasos significativos en la notificación de alerta. Recomendamos ventanas correderas más pequeñas (por ejemplo, un minuto). Imagine esta ventana deslizante como un marco en movimiento que escanea sus datos dentro de la ventana de agregación más grande. Cada vez que el cuadro avanza en su intervalo menor, calcula un valor agregado (por ejemplo, promedio).

3. Set your threshold duration: Ahora puede definir su umbral de alerta dentro del contexto de la ventana deslizante más pequeña. Esto le permite activar alerta rápidamente cuando el valor agregado en el cuadro actual se desvía significativamente del rango deseado sin sacrificar el efecto de suavizado de la ventana más grande.

   Importante

   Los clientes con planes de precios de Calcular avanzados y básicos pueden incurrir en cargos CCU adicionales al emplear la agregación de ventana deslizante. Si bien este método mejora el análisis de datos al suavizar las fluctuaciones, su uso puede generar mayores costos en comparación con otros métodos. Para obtener más detalles, consulte la sección de precios de ventanas corredizas. Para determinar si tiene planes de precios de Calcular avanzados o básicos, consulte su pedido.

   Puede obtener más información sobre la agregación de ventanas deslizantes en este tutorial de NRQL.

En general, recomendamos utilizar el método de transmisión event flow . Esto es mejor para los datos que ingresan a su sistema de manera frecuente y constante. Hay casos específicos en los que event timer podría ser un mejor método a elegir, pero para su primera alerta, recomendamos nuestro método predeterminado, event flow. Recomendamos ver este breve vídeo (aprox. 5:31 minutos) para comprender mejor qué método de transmisión elegir.

La característica de demora en la condición de alerta protege contra posibles problemas que surjan de una recopilación de datos inconsistente. Actúa como un buffer, permitiendo tiempo adicional para que los datos lleguen y se procesen antes de activar una alerta. Esto ayuda a prevenir el falso positivo y garantiza una creación de incidentes más precisa.

Cómo funciona:

La configuración de retraso adecuada se determina evaluando la coherencia de los datos entrantes:

• Datos consistentes: una configuración de retraso más baja es suficiente si los puntos de datos llegan consistentemente con una marca de tiempo dentro de un solo minuto.

• Datos inconsistentes: si los puntos de datos llegan con una marca de tiempo que abarca varios minutos en el pasado o en el futuro, es necesaria una configuración de retraso más alta para dar cabida a la inconsistencia.

  Creando un búfer:

• La configuración de retraso seleccionada introduce un período de espera antes de que la condición de alerta evalúe los datos con respecto al umbral definido.

• Este búfer da tiempo para que se resuelvan las discrepancias de datos, lo que reduce la probabilidad de alertas engañosas.

Está creando una condición de alerta para notificar a su equipo sobre cualquier problema de latencia con la aplicación WebPortal . En este ejemplo, su aplicación envía constantemente datos de New Relic. Hay un flujo constante de señales que se envían desde su aplicación a New Relic y no se espera que haya una brecha en la señal, por lo que no necesitará seleccionar una estrategia para llenar las brechas.

Las estrategias para llenar vacíos abordan escenarios en los que la recopilación de datos puede ser intermitente o incompleta. Proporcionan un método para sustituir puntos de datos faltantes con valores estimados, asegurando que la condición de alerta pueda seguir funcionando eficazmente incluso con lagunas en el flujo de datos.

Cuándo dejar de rellenar huecos:

• Consistent data flow: Si su aplicación envía datos constantemente a New Relic sin los espacios esperados, como en el caso de la aplicación WebPortal, generalmente no es necesario completar los espacios. En tales casos, dejar la estrategia para llenar vacíos en ninguna suele ser el enfoque más apropiado.

  Consideraciones clave:

• Popular use case: Un uso común para rellenar espacios es insertar un valor de 0 para ventanas sin datos recibidos.

• Anomaly thresholds: El valor de llenado de espacios se interpreta como el número de desviación estándar desde el último valor observado cuando se utiliza el umbral de anomalía. Por ejemplo, llenar los vacíos con un valor de 0 replicaría el último valor visto, asumiendo efectivamente que no hay cambios.

  Obtenga más información sobre las estrategias para llenar espacios en nuestros documentos sobre señales perdidas.

Las alertas entre cuentas en New Relic le permiten configurar condiciones de alerta que monitorean datos de una cuenta diferente a aquella en la que está configurada la alerta. Esta característica permite una mayor flexibilidad en el monitoreo y la gestión de la dependencia entre múltiples cuentas dentro de New Relic.

Para obtener más información, consulte Alerta entre cuentas.

Los umbrales de anomalía son ideales cuando le preocupa más la desviación de los patrones esperados que los valores numéricos específicos. Le permiten monitor actividades inusuales sin necesidad de establecer límites predefinidos. La detección de anomalías de New Relic analiza dinámicamente sus datos a lo largo del tiempo, adaptando el umbral para reflejar el comportamiento en evolución del sistema.

Configurar la detección de anomalías:

1. Elija superior o inferior:

   • Seleccione superior e inferior para estar alerta sobre cualquier desviación mayor o menor de lo esperado.
   • Seleccione solo superior para centrarse únicamente en valores inusualmente altos.

2. Asignar prioridad:

   • Establezca el nivel de prioridad en crítico para su alerta inicial a fin de garantizar la atención a problemas potenciales.

3. Definir criterios de incumplimiento:

   • Comience con la configuración predeterminada: abra un incidente cuando una consulta devuelva un valor que se desvíe del valor previsto durante al menos cinco minutos en tres desviación estándar.
   • Personalice estas configuraciones según sea necesario para alinearlas con su aplicación específica y sus requisitos de alerta.

   Puede obtener más información sobre los niveles de prioridad en nuestros documentos de condición de alerta.

   Obtenga más información sobre el umbral de anomalía y los comportamientos del modelo en nuestra documentación sobre anomalías.

A diferencia del umbral de anomalía, un umbral estático no analiza su conjunto de datos como un todo y determina qué comportamiento es inusual en función del historial de su sistema. En cambio, un umbral estático abrirá un incidente cada vez que su sistema se comporte de manera diferente a los criterios que usted estableció.

Debe establecer el nivel de prioridad tanto para la anomalía como para el umbral estático. Consulte la sección anterior para obtener más detalles.

En New Relic, las entidades están asociadas con el estado de salud codificado por colores. Puedes ver el estado actual de estas entidades desde sus respectivos índices y mapas. Cuando una condición de alerta está asociada a una entidad, el estado de salud de la entidad está determinado por la condición de alerta. Si la alerta desencadena un incidente, el estado de salud de la entidad cambia según el nivel de gravedad del incidente.

Si desea que la condición de alerta no afecte el estado de salud de la entidad asociada, habilite el interruptor Do not report system health status . Esto es útil cuando desea monitorear una entidad sin afectar su estado de salud general.

Predictive Alerts de New Relic analiza datos históricos para predecir tendencias futuras. Si la predicción muestra que el umbral estático puede romper pronto, recibirá una notificación de alerta, lo que le da la oportunidad de actuar antes de que se produzcan interrupciones.

Para obtener más información, consulte la documentación de alertas predictivas.

Para habilitar alertas predictivas para su condición de alerta, realice los siguientes pasos:

1. En la sección Set condition thresholds , seleccione el tipo de condición de umbral como Static.

2. Para las alertas predictivas, habilite el interruptor Predict future behavior .

3. Establezca el tiempo de anticipación. Esto indica hasta qué punto en el futuro se debe buscar la predicción de infracciones. El tiempo máximo de anticipación es 360 veces la duración de la ventana.

4. Establezca el comportamiento previsto del evento de alerta, cuando la señal real cruza el umbral.

   • Cerrar la alerta prevista y abrir una alerta real.
   • Mantenga abierta la alerta prevista para reducir el ruido.

El umbral de señal perdida determina cuánto tiempo hay que esperar antes de considerar perdida una señal faltante. Si la señal no regresa dentro de ese tiempo, puedes optar por abrir un nuevo incidente o cerrar cualquiera de los relacionados. También puede optar por omitir la apertura de un incidente cuando se espera que una señal finalice. Establezca el umbral en función del comportamiento esperado de su sistema y la frecuencia de recopilación de datos. Por ejemplo, si un sitio web experimenta una pérdida total de tráfico o rendimiento, los telemetry data correspondientes enviados a New Relic también cesarán. El monitoreo de esta pérdida de señal puede servir como un sistema de alerta temprana para tales cortes.

Una de las mejores prácticas para la denominación de condiciones implica un formato estructurado que transmita información esencial de un vistazo. Incluya los siguientes elementos en los nombres de sus condiciones:

• Prioridad: indique la gravedad o urgencia de la alerta, como P1, P2, P3.

• Señal: Especifique la métrica o condición que se monitorea, como latencia promedio alta o rendimiento bajo.

• Entidad: Identifica el sistema, aplicación o componente afectado, como WebPortal App o servidor base de datos.

  Un ejemplo de un nombre de condición bien formado que sigue esta estructura sería P2 | High Avg Latency | WebPortal App.

Si ya tiene una política que desea conectar a una condición de alerta, seleccione la política existente.

Obtenga más información sobre cómo crear políticas aquí.

Equilibrar la capacidad de respuesta y la fatiga en su estrategia de alertas es crucial y usted ha establecido las consideraciones clave con respecto al pageview monitoreo de su aplicación WebPortal . Exploremos las opciones de políticas:

1. Un problema por política (predeterminado):

   • Ventajas: Reduce el ruido y garantiza una acción inmediata.
   • Desventajas: agrupa todos los incidentes bajo un mismo problema, incluso si se desencadenan por condiciones diferentes. No es ideal para problemas de visualización de páginas múltiples.

2. Un problema por condición:

   • Ventajas: Crea problemas separados para cada condición, ideal para aislar y abordar problemas de latencia específicos.
   • Contras: Puede generar más alerta, lo que podría provocar fatiga.

3. Un problema para cada incidente:

   • Ventajas: Proporciona detalles granulares para sistemas externos, pero no es óptimo para el consumo interno debido a una posible sobrecarga.
   • Desventajas: Es la opción más ruidosa y resulta complicado seguir tendencias más amplias y establecer prioridades de forma eficaz.

   Obtenga más información sobre cómo crear políticas aquí.

Un incidente se cierra automáticamente cuando la señal objetivo vuelve a un estado de no infracción durante el período indicado en el umbral de la condición. Este tiempo de espera se llama período de recuperación.

Por ejemplo, si está midiendo la latencia y el comportamiento de infracción es que duration para cargar páginas en su aplicación WebPortal aumentó a más de 3 segundos, el incidente se cerrará automáticamente cuando duration sea igual o inferior a 3 segundos durante 5 minutos consecutivos.

Cuando un incidente se cierra automáticamente:

1. La timestamp de cierre tiene una fecha retroactiva al inicio del período de recuperación.

2. La evaluación se reinicia y se reinicia desde que finalizó el incidente anterior.

   Todas las condiciones tienen una configuración de límite de tiempo de incidente que fuerza automáticamente el cierre de un incidente de larga duración.

   New Relic tiene un valor predeterminado automático de 3 días y recomienda que utilice nuestra configuración predeterminada para su primera alerta.

   Otra forma de cerrar un incidente abierto cuando la señal no devuelve datos es configurando un umbral loss of signal . Consulte la sección anterior sobre umbral de señal perdida para obtener más detalles.

Dado que está creando una condición de alerta que le permite saber si hay algún problema de latencia con su aplicación WebPortal , desea asegurarse de que sus desarrolladores tengan toda la información que necesitan cuando se les notifique sobre este incidente. Utilizará flujo de trabajo para notificar a un canal de Slack del equipo cuando se cree un incidente.

Obtenga más información sobre descripciones de incidentes personalizadas en nuestros documentos.

Usar la plantilla de título es opcional pero lo recomendamos. Una condición de alerta define un conjunto de umbrales que desea monitor. Si se traspasa alguno de esos umbrales, se crea un incidente. Las plantillas de títulos significativas lo ayudan a identificar problemas y resolver interrupciones más rápido.

Obtenga más información sobre las plantillas de títulos en nuestros documentos.

En este campo a menudo se vincula un runbook de operaciones que detalla los pasos de investigación, clasificación o remediación.