Crear condición de alerta NRQL

Puede utilizar la consulta NRQL para crear una condición de alerta. Una vez que haya definido su señal, puede definir aún más sus niveles de umbral crítico y de advertencia. Esto determina cuándo se crea un incidente de alerta. Para obtener más información sobre conceptos clave relacionados con NRQL condición de alerta y alerta de transmisión, consulte Alerta de transmisión: términos y conceptos clave.

Crear una condición de alerta NRQL a partir de una política

Vaya a one.newrelic.com > All capabilities > Alerts & AI > Alert Conditions & Policies para crear una condición de alerta NRQL a partir de una política. Luego, haga clic en + New alert condition.

Sigue estos pasos.

Crear una condición a partir de un gráfico

La mayoría de nuestros gráficos, con excepción de algunos más antiguos, le permiten crear una condición a partir de ellos.

Para crear una condición de alerta NRQL a partir de un gráfico:

1. Vaya a one.newrelic.com > All capabilities > APM & Services y seleccione una aplicación.

2. En el panel izquierdo, seleccione Metrics explorer y agregue su configuración.

3. En la esquina derecha del gráfico, haga clic en icono y seleccione Create alert condition.

   

4. Siga los pasos explicados en Crear una condición de alerta NRQL a partir de una política , pero tenga en cuenta que el paso 1 es un poco diferente porque, ahora, la consulta se crea con los datos que configuró previamente.

Sintaxis de alerta NRQL

Aquí está la sintaxis básica para crear todas las condiciones de alerta NRQL.

SELECT function(attribute)
    FROM Event
    WHERE attribute [comparison] [AND|OR ...]

Reformatear NRQL incompatible

Algunos elementos de NRQL utilizados en los gráficos no tienen sentido en el contexto de la alerta de transmisión. A continuación se incluye una lista de los elementos incompatibles más comunes y sugerencias para reformatear una consulta de alerta NRQL para lograr el mismo efecto.

SELECT percentile(largestContentfulPaint, 75) FROM PageViewTiming WHERE (appId = 837807) SINCE yesterday

SELECT count(foo), average(bar), max(baz) from Transaction

SELECT count(foo) from Transaction

SELECT average(bar) from Transaction

SELECT max(baz) from Transaction

SELECT count(*) from Transaction TIMESERIES 1 minute SLIDE BY 5 minutes

Ejemplos de umbrales de alerta NRQL

A continuación se muestran algunos casos de uso comunes para condiciones NRQL. Estas consultas funcionarán para tipos de condiciones estáticas y anormales.

SELECT average(duration) FROM Transaction WHERE account_id in (91290, 102021, 20230)

SELECT percentile(duration, 95) FROM Transaction WHERE name LIKE 'Controller/checkout/%'

SELECT percentile(duration, 95) FROM Transaction

SELECT percentile(databaseDuration, 75) FROM Transaction

SELECT max(duration) FROM Transaction

SELECT average(duration) FROM Transaction

SELECT percentage(count(*), WHERE duration > 2) FROM Transaction

SELECT percentage(count(*), WHERE http.statusCode = '500') FROM Transaction

SELECT apdex(duration, t:0.5) FROM Transaction WHERE appName like '%prod%'

Condiciones NRQL y orden de consulta de operaciones.

De forma predeterminada, la duración de la ventana de agregación es de 1 minuto, pero puede cambiar la ventana para adaptarla a sus necesidades. Cualquiera que sea la ventana de agregación, New Relic recopilará datos para esa ventana utilizando la función en la consulta de la condición NRQL. Nuestros sistemas analizan y ejecutan la consulta en el siguiente orden:

1. FROM cláusula. ¿Qué tipo de evento es necesario capturar?
2. WHERE cláusula. ¿Qué se puede filtrar?
3. SELECT cláusula. ¿Qué información debe devolverse del conjunto de datos ahora filtrado?

Ejemplo: valor nulo devuelto

Digamos que esta es su consulta de condición de alerta:

SELECT count(*) FROM SyntheticCheck WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED'

Si no hay errores en la ventana de agregación:

1. El sistema ejecutará la cláusula FROM capturando todos los eventos SyntheticCheck de su cuenta.
2. Luego ejecutará la cláusula WHERE para filtrar esos eventos buscando solo los que coincidan con el nombre del monitor y el resultado especificado.
3. Si aún quedan eventos por analizar después de completar las operaciones FROM y WHERE , se ejecutará la cláusula SELECT . Si no queda ningún evento restante, la cláusula SELECT no se ejecutará.

Esto significa que agregadores como count() y uniqueCount() nunca devolverán un valor cero. Cuando hay un recuento de 0, la cláusula SELECT se ignora y no se devuelven datos, lo que da como resultado un valor de NULL.

Ejemplo: valor cero devuelto

Si tiene una fuente de datos que proporciona ceros numéricos legítimos, la consulta devolverá valores cero y no valores nulos.

Digamos que esta es su consulta de condición de alerta y que MyCoolEvent es un atributo que a veces puede devolver un valor cero.

SELECT average(MyCoolAttribute) FROM MyCoolEvent

Si, en la ventana de agregación que se está evaluando, hay al menos una instancia de MyCoolEvent y si el valor promedio de todos los atributos MyCoolAttribute de esa ventana es igual a cero, entonces se devolverá un valor 0 . Si no hay ningún evento MyCoolEvent durante ese minuto, entonces se devolverá un NULL debido al orden de las operaciones.

Ejemplo: valor nulo versus cero devuelto

Para determinar cómo se manejarán los valores nulos, ajuste la configuración de pérdida de señal y llenado de espacios en la UIde condición de alerta.

Puede evitar NULL valores por completo con un acceso directo de consulta de orden de operaciones. Para hacer esto, use una subcláusula filter y luego incluya todos los elementos de filtro dentro de esa subcláusula. El cuerpo principal de la consulta debe incluir una cláusula WHERE que defina al menos una entidad de modo que, para cualquier ventana de agregación donde el monitor realice una verificación, la señal estará vinculada a esa entidad. Luego, la cláusula SELECT se ejecutará y aplicará los elementos de filtro a los datos devueltos por el cuerpo principal de la consulta, que devolverá un valor de 0 si los elementos de filtro no dan como resultado datos coincidentes.

A continuación se muestra un ejemplo para alertar sobre FAILED resultados:

SELECT filter(count(*), WHERE result = 'FAILED') FROM SyntheticCheck WHERE monitorName = 'My Favorite Monitor'

En este ejemplo, una ventana con un resultado exitoso devolvería un 0, lo que permitiría que el umbral de la condición se resuelva por sí solo.

Para obtener más información, consulte nuestra publicación de blog sobre resolución de problemas para valores cero versus valores nulos.

Alerta NRQL de agregación anidada

Las consultas de agregación anidadas son una forma poderosa de consultar sus datos. Sin embargo, tienen algunas restricciones que es importante tener en cuenta.

SELECT max(cpu) FROM (FROM SystemSample SELECT min(cpuPercent) as 'cpu' FACET hostname) ​​​​

SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) as cpu TIMESERIES 30 seconds)​​

Consejos para la creación de condiciones NRQL

A continuación se ofrecen algunos consejos para crear y utilizar una condición NRQL:

Gestión de etiquetas en condiciones.

Cuando edita una condición NRQL existente, tiene la opción de agregar o eliminar la etiqueta asociada con la entidad de condición. Para hacer esto, haga clic en el botón Manage tags debajo del nombre de la condición. En el menú que aparece, agregue o elimine una etiqueta.

Las ediciones de condiciones pueden restablecer la evaluación de condiciones

Cuando edita la condición de alerta NRQL de algunas maneras específicas (que se detallan a continuación), sus evaluaciones se restablecen, lo que significa que cualquier evaluación hasta ese punto se pierde y la evaluación comienza de nuevo desde ese punto. Las dos formas en que esto le afectará son:

• Para el umbral "durante al menos x minutos": debido a que la ventana de evaluación se ha restablecido, habrá un retraso de al menos x minutos antes de que se pueda informar cualquier incidente.
• Para condiciones de anomalía: la condición comienza de nuevo y se pierde todo el aprendizaje de anomalías.

Las siguientes acciones provocan un restablecimiento de la evaluación de las condiciones NRQL:

• Cambiando la consulta
• Cambiar la ventana de agregación, el método de agregación o la configuración del temporizador/retardo de agregación
• Cambiar la configuración de "incidente cercano en pérdida de señal"
• Cambiar cualquier configuración de relleno de huecos
• Cambiar la dirección de la anomalía (si corresponde): superior, inferior o superior/inferior
• Cambiar el valor de umbral, la ventana de umbral o el operador de umbral
• Cambiar el intervalo de deslizamiento (solo en condiciones de agregación de ventanas deslizantes )

Las siguientes acciones (junto con cualquier otra acción no cubierta en la lista anterior) no restablecerán la evaluación:

• Cambiar la ventana de tiempo de pérdida de señal (duración de vencimiento)
• Cambiar la función de tiempo (cambiar "al menos" a "al menos una vez", o viceversa)
• Alternar la configuración "abrir incidente en caso de pérdida de señal"

Tipos de condición de alerta

Cuando crea una alerta NRQL, puede elegir entre diferentes tipos de condiciones:

Establecer el umbral de pérdida de señal

La pérdida de señal ocurre cuando ningún dato coincide con la condición NRQL durante un período de tiempo específico. Puede establecer la duración del umbral de pérdida de señal y también qué sucede cuando se cruza el umbral.

También puede administrar estas configuraciones utilizando la API GraphQL (recomendada) o la API REST. Vaya aquí para ver ejemplos específicos de API GraphQL.

Loss of signal settings:

La configuración de pérdida de señal incluye una duración de tiempo y dos acciones posibles.

• Signal loss expiration time

  • Etiqueta UI :

    Signal is lost after:

  • Nodo GraphQL: expiration.expirationDuration

  • La duración de la caducidad es un temporizador que se inicia y se reinicia cuando recibimos un punto de datos en el canal de alerta de transmisión. Si no recibimos otro punto de datos antes de que expire su 'tiempo de vencimiento', consideramos que esa señal se perdió. Esto puede deberse a que no se envían datos a New Relic o a que la cláusula WHERE de su consulta NRQL filtra esos datos antes de transmitirlos al canal de alerta. Tenga en cuenta que cuando tiene una consulta por facetas, cada faceta es una señal. Entonces, si alguna de esas señales finaliza durante la duración especificada, se considerará una pérdida de señal.

  • La pérdida del tiempo de vencimiento de la señal es independiente de la duración del umbral y se activa tan pronto como expira el temporizador.

  • La duración máxima de caducidad es de 48 horas. Esto es útil cuando se monitorea la ejecución de trabajos poco frecuentes. El mínimo son 30 segundos, pero recomendamos utilizar al menos 3-5 minutos.

• Loss of signal actions

  Una vez que se considera perdida una señal, puede cerrar un incidente abierto, abrir un incidente nuevo o ambos.

  • Cerrar todos los incidentes abiertos actuales: Cierra todos los incidentes abiertos que estén relacionados con una señal específica. No necesariamente cerrará todos los incidentes por una condición. Si está alertando sobre un servicio efímero o sobre una señal esporádica, querrá elegir esta acción para asegurarse de que el incidente se cierre correctamente. El nombre del nodo GraphQL para esto es "closeViolationsOnExpiration"
  • Abrir nuevo incidente: Esto abrirá un nuevo incidente cuando la señal se dé por perdida. Estas incidencias nos indicarán que se deben a una pérdida de señal. Según sus preferencias de incidentes, esto debería generar una notificación. El nombre del nodo GraphQL para esto es "openViolationOnExpiration"
  • Cuando habilita ambas acciones, primero cerraremos todos los incidentes abiertos y luego abriremos un nuevo incidente por pérdida de señal.

Para crear una alerta NRQL configurada con pérdida de detección de señal en la UI:

1. Para una política, cuando crea una condición, en

   Select a product

   , haga clic en

   NRQL

   y luego haga clic en

   Next, define thresholds

   .

2. Escriba una consulta NRQL que devuelva los valores sobre los que desea alertar.

3. Para

   Threshold type

   , seleccione

   Static

   o

   Anomaly

   .

4. Haga clic en

   + Add lost signal threshold

   y luego establezca el tiempo de duración de vencimiento de la señal en minutos o segundos en el campo

   Consider the signal lost after

   .

5. Elige lo que quieres que suceda cuando se pierda la señal. Puede marcar uno o ambos de

   Close all current open incidents

   y

   Open new "lost signal" incident

   . Estos controlan cómo se manejará el incidente de pérdida de señal para la condición.

6. Asegúrese de nombrar su condición antes de guardarla.

Incidente apertura por pérdida de señal cierre cuando:

• la señal vuelve. El incidente de señal perdida recién abierto se cerrará inmediatamente cuando se evalúen nuevos datos.

• expira la condición a la que pertenecen. De forma predeterminada, las condiciones caducan después de 3 días.

• cierras manualmente el incidente con la opción

  Close all current open incidents

  .

Configuración de señal avanzada

Al crear una condición NRQL, existen varias configuraciones de señal avanzadas:

• Duración de la ventana de agregación
• Agregación de ventanas deslizantes
• Método de transmisión
• Temporizador de retardo
• Llenar lagunas de datos
• Retraso en la evaluación

Para leer una explicación de qué son estas configuraciones y cómo se relacionan entre sí, consulte Conceptos de alertas de transmisión. A continuación encontrará instrucciones y consejos sobre cómo configurarlos.

Duración de la ventana de agregación

Puede configurar la duración de la ventana de agregación para elegir cuánto tiempo se acumulan los datos en una ventana de tiempo de transmisión antes de agregarlos. Puede configurarlo entre 30 segundos y 120 minutos. El valor predeterminado es un minuto.

Agregación de ventanas deslizantes

Puede utilizar ventanas deslizantes para crear gráficos más fluidos. Esto se hace creando ventanas de datos superpuestas.

Aprenda cómo configurar ventanas corredizas en este breve video (2:30 minutos):

Una vez habilitado, configure el "intervalo de diapositiva por" para controlar cuánto tiempo de superposición tienen sus ventanas agregadas. El intervalo debe ser más corto que la ventana de agregación y al mismo tiempo dividirse uniformemente en ella.

Método de transmisión

Elija entre tres métodos de agregación de transmisión para obtener los mejores resultados de evaluación para sus condiciones.

Temporizador de retardo

Puede ajustar el retraso/temporizador para coordinar nuestro algoritmo de alerta de transmisión con el comportamiento de sus datos. Si sus datos son escasos o inconsistentes, es posible que desee utilizar el método de agregación del temporizador de eventos.

Para el método de cadencia, la latencia total admitida es la suma de la duración de la ventana de agregación y el retraso.

Si el tipo de datos proviene de un agente de lenguaje APM y se agrega desde muchas instancias de aplicación (por ejemplo, Transactions, TransactionErrors, etc.), recomendamos usar el método de flujo de eventos con la configuración predeterminada.

Llenar lagunas de datos

El relleno de espacios le permite personalizar los valores que utilizará cuando sus señales no tengan ningún dato. Puede llenar los vacíos en sus flujos de datos con una de estas configuraciones:

• None

  : (Predeterminado) Elija esto si no desea realizar ninguna acción en ventanas de agregación vacías. Durante la evaluación, una ventana de agregación vacía restablecerá el temporizador de duración del umbral. Por ejemplo, si una condición dice que todas las ventanas de agregación deben tener puntos de datos por encima del umbral durante 5 minutos y 1 de las 5 ventanas de agregación está vacía, entonces la condición no será un incidente.

• Custom static value

  : elija esto si desea insertar un valor estático personalizado en las ventanas de agregación vacías antes de que se evalúen. Esta opción tiene un parámetro obligatorio adicional de fillValue (como se nombra en la API) que especifica qué valor estático se debe usar. El valor predeterminado es 0.

• Last known value

  : Esta opción inserta el último valor visto antes de que se produzca la evaluación. Mantenemos el estado del último valor visto durante un mínimo de 2 horas. Si la duración del umbral configurado es superior a 2 horas, este valor se mantiene durante esa duración.

Opciones para editar la configuración de la brecha de datos:

• En la UI de condiciones NRQL, vaya a

  Condition settings > Advanced signal settings > fill data gaps with

  y elija una opción.

• Si utiliza nuestra API Nerdgraph (preferida), este nodo se encuentra en: actor : account : alerts : nrqlCondition : signal : fillOption | fillValue

• NerdGraph es nuestra API recomendada para esto, pero si está utilizando nuestra API REST, puede encontrar esta configuración en el explorador de API REST en la sección

  "signal"

  de la API de condiciones alerta NRQL.

Retraso en la evaluación

Puede habilitar el indicador Use evaluation delay y configurar hasta 120 minutos para retrasar la evaluación de las señales entrantes.

Cuando se implementan nuevas entidades por primera vez, la utilización de recursos en la entidad suele ser inusualmente alta. En entornos de escala automática, esto puede crear fácilmente muchas alertas falsas. Al retrasar el inicio de la detección de alertas en señales emitidas por una nueva entidad, puede reducir significativamente la cantidad de falsas alarmas asociadas con el despliegue en entornos orquestados o de escala automática.

Opciones para habilitar el retraso de la evaluación:

• En la UI de condiciones NRQL, vaya a

  Adjust to signal behavior > Use evaluation delay

  .

• Si utiliza nuestra API Nerdgraph, este nodo se encuentra en: actor : account : alerts : nrqlCondition : signal : evaluationDelay