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 incidente. Recomendamos establecer su nivel de prioridad como critical para su primera alerta. Puede obtener más información sobre los niveles de prioridad en nuestros documentos de condición de alerta.

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

Obtenga más información sobre la anomalía 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ó. Los umbrales de alerta estática son mucho más personalizables y los recomendamos si tiene un buen conocimiento 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 se puede perder una señal entrante y es importante comprender si se trata simplemente de un retraso o una indicación de un problema más amplio. Nuestro loss 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 perdió. Si la señal no regresa antes del límite de tiempo que establezca, puede elegir una o ambas de dos acciones: abrir un nuevo incidente y/o cerrar todos los incidentes abiertos. Puede cerrar cualquier incidente abierto relacionado si la señal perdida reemplaza a otro incidente en esta entidad, o si la pérdida de señal era esperada.

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

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 detectar un incidente, la condición de alerta recopila los datos durante un período de tiempo conocido como aggregation window. Un retraso adicional permite que lleguen puntos de datos más lentos 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 característica de retraso lo protege contra la recopilación de datos inconsistentes. Le da a la condición de alerta un poco de margen de maniobra antes de decidir crear un incidente. Si en un minuto determinado sus datos llegan a New Relic con una marca de tiempo de solo un minuto, entonces una configuración de retraso bajo es suficiente. Por otro lado, si durante ese minuto New Relic recibe puntos de datos con marca de tiempo de varios minutos después o de varios minutos adelante, entonces su señal es más inconsistente y necesitará una configuración de retraso más alta.

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, una política está conectada al flujo de trabajo y al control de flujo de trabajo con qué frecuencia se nos notifica sobre cualquier incidente. Es un delicado equilibrio entre garantizar que conozcamos cualquier problema con el tiempo de transacción web lo más rápido posible y asegurarnos de que no recibamos tantas alertas que hagan que nuestros desarrolladores se cansen 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.

En primer lugar, puede crear una política que solo adjunte un único problema por política (la opción predeterminada). Un tema por política reduce el ruido pero también requiere acción inmediata. Pero esto significa que si ha adjuntado varias condiciones a esta política, no solo a Response time: Example app, pase lo que pase, todos los incidentes de esta política se agruparán en un solo problema.

O podríamos crear un problema por condición. Esto significa que cada vez que la condición Response time: Example app abre un incidente, todos esos incidentes 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 monitor los problemas de latencia con el tiempo de transacción web.

O podríamos crear un problema para cada incidente. 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 incidente se cerrará automáticamente cuando la señal objetivo regrese a un estado sin infracción durante el período de tiempo 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 "el tiempo de transacción web es superior a 0,50 segundos al menos una vez cada 5 minutos", entonces el incidente se cerrará automáticamente cuando el tiempo de transacción web sea igual o inferior a .50 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 forzará el cierre automático de un incidente 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 algún problema 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 incidente. Usaremos 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.