Condición de alerta

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 información valiosa 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.

   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.

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.
   • Consulte los documentos de condición de alerta para obtener más detalles sobre los niveles de prioridad.

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 de los umbrales 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 you set.

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.

El umbral de pérdida de señal determina cuánto tiempo esperar antes de considerar perdida una señal faltante. Si en ese tiempo no vuelve la señal, podrás optar por abrir un nuevo incidente o cerrar alguno relacionado. Establezca el umbral según el comportamiento esperado de su sistema y la frecuencia de recopilación de datos. Por ejemplo, si una pérdida de señal para pageviews podría indicar un problema de latencia, establezca un umbral con el que se sienta cómodo y marque la casilla para abrir un nuevo incidente de pérdida de señal.

Es esencial darle un nombre descriptivo a su condición de alerta. Digamos que nombra esta condición pageviews y luego crea otra condición para una aplicación completamente diferente y etiqueta esa condición también como pageviews . Si esto ocurre, no podrá distinguir qué condición corresponde a cada aplicación. Por lo tanto, asegúrese de darle a su afección un nombre específico y único. En este caso, llamarías a esta condición pageviews: 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 el comportamiento de infracción es "pageviews es inferior a 300 al menos una vez cada 5 minutos", el incidente se cerrará automáticamente cuando pageviews sea igual o superior a 300 durante cinco 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 el cierre automático 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.

Si desea vincular a un runbook, puede colocar la URL en el campo URL del runbook.