Crea tu primera alerta

Primero, vaya al gráfico etiquetado Web transactions time y haga clic en create an alert condition.

Es importante darle un nombre descriptivo a su condición de alerta. Supongamos que nombra esta condición response time y luego crea otra condición para una aplicación completamente diferente y etiqueta esa condición también como response time . 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íamos a esta condición Response time: Example-app.

Una vez que haya nombrado su condición, puede realizar cambios en la consulta NRQL si lo desea. Para su primera alerta, le recomendamos no ajustar la consulta de NRQL y dejar esta sección como está, pero si desea obtener más información sobre cómo usar NRQL para personalizar sus consultas, visite nuestros documentos.

Su equipo está creando esta condición de alerta para que se le notifique si el tiempo de transacción web demora más de lo habitual. Pero digamos que no le importa cuánto tiempo de transacción web sea más largo y solo quiere saber si el tiempo de transacción se está comportando de manera anormal. Para este caso de uso específico, recomendamos utilizar nuestro anomaly threshold. Nuestra detección de anomalías evalúa constantemente sus datos para comprender cómo se comporta normalmente su sistema. Al establecer un umbral de anomalía, puede utilizar nuestra detección de anomalías para alertar a su equipo si el tiempo de transacción web se desvía del rendimiento esperado. Dado que solo desea saber si el tiempo de transacción web se está comportando de manera inusual, seleccionará upper and lower porque desea recibir una notificación de todas las desviaciones. Pero, si solo desea alertar si el tiempo de transacción web demora más de lo habitual, seleccionará upper only.

A continuación, debe establecer el nivel de prioridad. El nivel de prioridad determina qué creará un evento de alerta. Recomendamos configurar el nivel de prioridad como critical para su primera alerta. Puede obtener más información sobre los niveles de prioridad en nuestra documentación de condiciones de alerta.

A continuación, debe elegir qué define un critical anomaly threshold breach. Para esta primera alerta, recomendamos usar nuestra configuración predeterminada y ajustarla a sus necesidades según sea necesario. Por lo tanto, deje la configuración para abrir un evento de alerta "cuando una consulta devuelve un valor que se desvía del valor predicho: for at least five minutes en 3 standard deviations".

Obtenga más información sobre la anomalía en nuestra documentación sobre anomalías.

/ <img title="Configure your anomaly thresholds" alt="A screenshot demonstrating how to configure custom anomalies" src="/images/alerts_screenshot-crop_configure-your-anomaly-thresholds.webp" /> /

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ó. Los umbrales de alerta estáticos son mucho más personalizables, y los recomendamos si tiene un conocimiento sólido de sus datos y de lo que está buscando.

Obtenga más información sobre nuestra condición de alerta estática en nuestros documentos NRQL.

A veces, una señal entrante puede perderse, y es importante entender si se trata simplemente de un retraso o de un indicio de un problema mayor. Nuestro lost signal threshold nos permite saber cuántos segundos debe esperar el sistema desde el momento en que se detectó el último punto de datos antes de considerar que la señal se ha perdido. Si la señal no regresa antes del límite de tiempo que configuraste, tienes algunas opciones: abrir un nuevo evento de alerta, cerrar todos los eventos de alerta abiertos y/u omitir la apertura de un evento de alerta cuando se espera que la señal finalice. Haga clic aquí para obtener más información sobre sus opciones de umbral de pérdida de señal.

Establecer su umbral de señal perdida requiere conocimiento de su sistema y de lo que desea comprender. En el caso del tiempo de transacción web, digamos que New Relic recopila una señal cada minuto. Una señal perdida podría indicar un problema de latencia mucho mayor. Por lo tanto, le recomendamos configurar la hora según su nivel de comodidad y luego marcar la casilla open a new lost signal alert event.

/ <img title="" alt="" src="/images/alerts_screenshot-crop_lost-signal-threshold.webp"/> /

/ <img title="Window duration" alt="A screenshot depicting advanced custom settings for an alert condition." src="/images/alerts_screenshot-crop_window-duration.webp" /> /

Configurar la duración de la ventana para su condición de alerta le indica a New Relic cómo agrupar sus datos. Si está creando una condición de alerta para un conjunto de datos que envía una señal a New Relic una vez cada hora, querrá establecer la duración de la ventana en algo más cercano a sesenta minutos porque ayudará a detectar patrones y comportamientos inusuales. Pero, si está creando una condición de alerta para el tiempo de transacción web y New Relic recopila una señal para esos datos cada minuto, le recomendamos configurar la duración de la ventana en un minuto.

Para su primera alerta, le recomendamos seguir con nuestra configuración predeterminada, pero cuanto más se familiarice con la creación de una condición de alerta, le recomendamos que personalice estos campos según su propia experiencia.

A lo largo del día, los datos fluyen desde su aplicación a New Relic. En lugar de evaluar esos datos inmediatamente para eventos de alerta, las condiciones de alerta recopilan los datos durante un período de tiempo conocido como aggregation window. Un retraso adicional permite que los puntos de datos más lentos lleguen antes de que se agregue la ventana.

Las ventanas deslizantes son útiles cuando necesitas suavizar gráficos "puntiagudos". Un caso de uso común es utilizar ventanas deslizantes para suavizar gráficos de líneas que tienen mucha variación en períodos cortos de tiempo en los casos en que el agregado móvil es más importante que los agregados de ventanas de tiempo estrechas.

Recomendamos utilizar nuestra agregación de ventana deslizante si no espera tener un flujo de datos constante y consistente, pero espera algunas caídas y picos en los datos.

Puede obtener más información sobre la agregación de ventanas deslizantes en este tutorial de NRQL o viendo este vídeo.

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. Para entender mejor qué método de streaming elegir, te recomendamos ver este breve vídeo.

La función de retraso le protege contra la recolección de datos inconsistente. Le da a la condición de alerta un pequeño margen de maniobra antes de decidir crear un evento de alerta. Si en un minuto determinado sus datos llegan a New Relic con marcas de tiempo de un solo minuto, entonces una configuración de retraso bajo es suficiente. Por otro lado, si durante ese minuto New Relic recibe puntos de datos con marcas de tiempo de varios minutos atrás o varios minutos adelante, entonces su señal es más inconsistente y necesitará una configuración de retraso mayor.

Estamos creando una condición de alerta para notificar a nuestro equipo sobre cualquier problema de latencia con el tiempo de transacción web. En este caso, nuestra aplicación envía constantemente datos de New Relic. Hay un flujo constante de señales que se envían desde nuestra aplicación a New Relic y no se espera ninguna brecha en la señal, por lo que no necesitaremos seleccionar una estrategia para llenar las brechas. Para este caso de uso y para su primera alerta, recomendamos dejar gap-filling strategy configurado en none.

Si tiene un conjunto de datos más inconsistente que envía señales a New Relic una vez cada veinticuatro horas, le recomendamos personalizar esta característica según las necesidades específicas de su equipo.

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

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í.

Si queremos crear una nueva política para esta condición de alerta, esta es nuestra oportunidad. Recuerde que una política está conectada a flujos de trabajo, y los flujos de trabajo controlan la frecuencia con la que se nos notifica sobre cualquier evento de alerta. Es un delicado equilibrio entre garantizar que nos enteremos de cualquier problema con el tiempo de transacción web lo más rápido posible y asegurarnos de no recibir tantas alertas que nuestros desarrolladores experimenten fatiga y comiencen a perderse información importante debido a la sobrecarga de información.

Las políticas pueden contener una o varias condiciones. Si está buscando monitor la latencia web de transacciones, tiene algunas opciones.

Primero, puede crear una política que solo adjunte una única incidencia por política (la opción predeterminada). Un problema por política reduce el ruido, pero también requiere acción inmediata. Pero esto significa que si ha asociado múltiples condiciones a esta política, no solo a Response time: Example app, entonces, sin importar qué, todos los eventos de alerta en esta política se agruparán en una sola incidencia.

O podríamos crear una incidencia por condición. Esto significa que cada vez que la condición Response time: Example app abra un evento de alerta, todos esos eventos de alerta se agruparán en un problema conectado a nuestra condición. Para este caso de uso específico, debe elegir esta opción porque cumple con el objetivo principal, que es monitorear los problemas de latencia con el tiempo de transacción web.

O podríamos crear una incidencia para cada evento de alerta. Esta opción es la más ruidosa, pero puede funcionar bien si desea enviar información a un sistema externo.

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

Un evento de alerta se cerrará automáticamente cuando la señal objetivo vuelva a un estado de no infracción durante el período de tiempo indicado en los umbrales de la condición. Este tiempo de espera se llama período de recuperación.

Por ejemplo, si el comportamiento de infracción es "el tiempo de transacción web es superior a .50 segundos al menos una vez en 5 minutos", entonces el evento de alerta se cerrará automáticamente cuando el tiempo de transacción web sea igual o inferior a .50 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 para eventos de alerta que forzará automáticamente el cierre de un evento de alerta de larga duración.

   Automáticamente utilizamos 3 días de forma predeterminada y le recomendamos que utilice nuestra configuración predeterminada para su primera alerta.

Dado que estamos creando una condición de alerta que nos permite saber si hay problemas de latencia con el tiempo de transacción web, queremos asegurarnos de que nuestros desarrolladores tengan toda la información que necesitan cuando se les notifique sobre este evento de alerta. Vamos a usar 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.

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