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.

/ <img title="ajustar la configuración de alertas" alt="Una captura de pantalla que muestra la configuración avanzada de señales." src="/images/alerts_screenshot-crop_fine-tune-alert-signals.webp" /> /

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 función de retraso en las condiciones de alerta protege contra posibles problemas derivados de una recopilación de datos inconsistente. Actúa como un búfer, permitiendo tiempo adicional para que los datos lleguen y sean procesados antes de activar una alerta. Esto ayuda a prevenir falsos positivos y asegura una creación de eventos de alerta 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 evento de alerta cuando una consulta devuelva un valor que se desvíe del valor predicho durante al menos cinco minutos en tres desviaciones 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 en su totalidad ni determina qué comportamiento es inusual basándose en el historial de su sistema. En su lugar, un umbral estático abrirá un evento de alerta siempre que su sistema se comporte de manera diferente a los criterios que 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.

La detección de valor atípico identifica entidades que se comportan de manera significativamente diferente a sus pares en un momento específico. A diferencia de la detección de anomalías que busca patrones inusuales a lo largo del tiempo, la detección de valor atípico se centra en la desviación dentro de un grupo empleando el clúster DBSCAN.

Este tipo de umbral es ideal para:

• Identificar servidores con un consumo de recursos inusual en comparación con su clúster.

• Detección de brokers de Kafka que no procesan los mensajes correctamente

• Identificación de escenarios de "vecinos ruidosos" en entornos multiinquilino

  Parámetro de configuración clave:

• Epsilon: Distancia máxima entre puntos en el mismo grupo

• Puntos mínimos: Puntos mínimos requeridos para formar un grupo (recomendado > 3)

• Grupos de evaluación: Análisis de segmentos por facetas como el entorno o la región.

  Obtenga más información sobre la detección de valor atípico en nuestra documentación de detección de valor atípico.

En New Relic, las entidades se asocian con estados de salud codificados por colores. Puede ver el estado actual de estas entidades desde sus respectivos índices y mapas. Cuando una condición de alerta se asocia a una entidad, el estado de salud de la entidad es determinado por la condición de alerta. Si la alerta activa un evento de alerta, el estado de salud de la entidad cambia según el nivel de gravedad del evento de alerta.

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 pérdida de señal determina cuánto tiempo esperar antes de considerar que una señal faltante se ha perdido. Si la señal no regresa dentro de ese tiempo, puede elegir abrir un nuevo evento de alerta o cerrar los relacionados. También puede optar por omitir la apertura de un evento de alerta 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 datos de telemetría correspondientes enviados a New Relic también se detendrán. El monitoreo de esta pérdida de señal puede servir como un sistema de alerta temprana para dichas interrupciones.

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 la creación de 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.
   • Contras: Agrupa todos los eventos de alerta bajo un problema, incluso si son activados por diferentes condiciones. No es ideal para cuestiones de múltiples vistas de página.

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. Una incidencia para cada evento de alerta:

   • 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 la creación de políticas aquí.

Un evento de alerta se cierra automáticamente cuando la señal objetivo regresa a un estado de no infracción durante el período indicado en los umbrales 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 ha aumentado a más de 3 segundos, el evento de alerta se cerrará automáticamente cuando duration sea igual o inferior a 3 segundos durante 5 minutos consecutivos.

Cuando un evento de alerta 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 restablece y se reinicia desde el momento en que finalizó el evento de alerta anterior.

   Todas las condiciones tienen una configuración de límite de tiempo de eventos de alerta que fuerza automáticamente el cierre de un evento de alerta 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 evento de alerta abierto cuando la señal no devuelve datos es configurando un umbral de loss of signal. Consulte la sección de umbral de señal perdida anterior para obtener más detalles.

Dado que está creando una condición de alerta que le avisa si hay problemas de latencia con su aplicación WebPortal, querrá asegurarse de que sus desarrolladores tengan toda la información necesaria cuando se les notifique sobre este evento de alerta. Utilizarás flujos de trabajo para notificar a un canal de Slack del equipo cuando se cree un evento de alerta.

Obtén más información sobre las descripciones de eventos de alerta personalizadas en nuestra documentación.

/ <img title="página de detalles de la alerta" alt="Una captura de pantalla que muestra el paso final para crear una condición de alerta: la página de detalles de la alerta" src="/images/alerts_screenshot-crop_adding-alert-details-to-an-alert-condition.webp" /> /

Usar la plantilla de título es opcional, pero lo recomendamos. Una condición de alerta define un conjunto de umbrales que desea monitorear. Si se supera cualquiera de esos umbrales, se crea un evento de alerta. 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.