Los REST extremos de API le permiten crear condiciones para sus políticas. Este glosario contiene los nombres y descripciones de cada uno de los campos que puede utilizar para definir o actualizar una condición.
Antes de usar la API REST
La API REST ya no es la forma preferida de gestionar sus alertas mediante programación. Para obtener más contexto, lea la Introducción a las API de .
Campos obligatorios y opcionales
La API incluye cuatro tipos de condición de alerta:
- APM
- Servicios externos
- NRQL
- Monitoreo sintetico
Todos los campos utilizados con un tipo de condición específico son obligatorios excepto estos campos opcionales:
enabled
(por defecto esfalse
)runbook_url
user_defined
Definiciones de campo
No todos los campos enumerados en este glosario son obligatorios para todos los tipos de condición. El tipo de condición para el cual se debe utilizar un campo aparece en cada descripción.
Este campo le permite asignar una condición a una instancia de JVM o a una aplicación completa. Esta puede ser una de las cadenas:
instancia
aplicación
Usado para:
Condiciones
Condiciones de la entidad
Para métricas de salud JVM y basadas en instancias, consulte también
violation_close_timer
.
Este es el estado de su condición de alerta y es opcional. El valor predeterminado es false
.
Este campo se puede utilizar para habilitar o deshabilitar una condición para períodos de mantenimiento o prueba.
Usado para:
- Condiciones
- Condiciones de servicio externo
- Condiciones NRQL
- Monitoreo de condiciones sintéticas
Esta es una matriz de ID de entidad que identifican los objetos que serán monitoreados con su condición. Estos pueden ser ID de la aplicación, ID browser , ID de clave de transacción, ID de servicios externos, etc.
Estos se ingresan como una serie de números enteros separados por comas si hay más de uno.
Usado para:
- Condiciones
- Condiciones de servicio externo
Cuánto tiempo esperar, en segundos, después de que nuestra plataforma reciba el último punto de datos antes de considerar la señal como perdida. Esto se basa en la hora a la que llegan los datos y no en la marca de tiempo de los datos. El valor predeterminado es nulo. Agregue un valor para habilitar la pérdida de detección de señal.
Usado para:
- Condiciones NRQL
Cuando true
, esto cierra todos los incidentes actualmente abiertos cuando no se escucha ninguna señal dentro del tiempo expiration_duration
.
El valor predeterminado es false
.
Usado para:
- Condiciones NRQL
Cuando es cierto, esto abre un incidente de pérdida de señal cuando no hay señal dentro del tiempo expiration_duration
.
El valor predeterminado es false
.
Usado para:
- Condiciones NRQL
Esta es la URL del servicio externo que se va a monitorear. Esta cadena no debe incluir el protocolo. Por ejemplo, utilice example.com
, no https://example.com
.
Usado para:
- Condiciones de servicio externo
El campo metric se utiliza para tres categorías de alerta. El parámetro exacto disponible para su uso depende de la configuración en el campo de tipo . Estos se enumeran a continuación según su campo de tipo de alerta.
El valor especificado en el campo tipo controla cuál de los parámetros se puede especificar. El campo de tipo y los nombres parameter correspondientes disponibles se enumeran en la siguiente tabla. Sólo se podrá especificar uno.
| Parámetro |
---|---|
apm_app_metric |
|
apm_kt_metric |
|
browser_metric |
|
browser_metric_baseline |
|
mobile_metric |
|
El valor especificado en el campo tipo controla cuál de los parámetros se puede especificar. El campo de tipo y los nombres parameter correspondientes disponibles se enumeran en la siguiente tabla. Sólo se podrá especificar uno.
| Parámetro |
---|---|
apm_external_service |
|
apm_app_metric_baseline |
|
mobile_external_service |
|
Este es el GUID del monitoreo sintético para alertar.
Usado para:
- Monitoreo de condiciones sintéticas
Este título de condición le permitirá identificarla en la UI.
Siga las pautas para que esto sea descriptivo pero breve.
Usado para:
- Condiciones
- Condiciones de servicio externo
- Condiciones NRQL
- Monitoreo de condiciones sintéticas
Esta es la consulta NRQL que alerta al monitor como parte de una condición NRQL.
Usado para:
- Condiciones NRQL
En desuso en favor de un aggregation_method
con un aggregation_delay
o aggregation_timer
. Este es el período de tiempo (en minutos) en el que se evalúa la consulta NRQL especificada. since_value
debe estar entre 1
y 20
.
Usado para:
- Condiciones NRQL
La URL del runbook que se mostrará en la notificación. Este campo es opcional.
Usado para:
- Condiciones
- Condiciones de servicio externo
- Condiciones NRQL
- Monitoreo de condiciones sintéticas
El tiempo en segundos que se debe esperar a que la ventana de agregación se llene con datos. Requerido cuando se usan tipos CADENCE o evento aggregation_method
. El valor predeterminado es 120 seconds.
Se utiliza con métodos de agregación de cadencia y flujo de eventos.
Usado para:
- Condiciones NRQL
New Relic agrega datos en ventanas y necesita determinar cuándo termina la ventana actual y comienza la siguiente. El aggregation_method
es la lógica que nos indica cuándo tenemos todos los datos para una ventana de agregación determinada. Una vez que se cierra la ventana, los datos se agregan en un solo punto y se evalúan según el umbral.
Este campo es opcional. Se puede especificar uno de los tres valores siguientes:
EVENT_FLOW
: (Predeterminado) Cada ventana de agregación esperará hasta que comience a ver llegar la marca de tiempo que haya superado su propia configuración de retraso. Una vez que esto ocurre, los datos se publican. Depende de la marca de tiempo de los datos que llegan, por lo que el tiempo de reloj ya no es relevante. Funciona mejor para fuentes que llegan con frecuencia y con baja dispersión de eventos (alto rendimiento métrico).CADENCE
: Lógica clásica de New Relic donde cada ventana de evaluación espera exactamente tanto tiempo como la configuraciónaggregation_delay
, utilizando el tiempo de reloj como temporizador. Se requiereaggregation_delay
al usar esta opción. Los datos que lleguen demasiado tarde se descartarán, lo que puede provocar alertas falsas.EVENT_TIMER
: Cada ventana de agregación tiene un temporizador, establecido en el valoraggregation_timer
. El temporizador comienza a funcionar tan pronto como aparece el primer punto de datos para esa ventana de agregación (según la timestamp del punto de datos). Elaggregation_timer
se restablece para cada nuevo punto de datos que llega para esa ventana. Una vez queaggregation_timer
llega a 0, se publica la ventana de agregación. Ideal para datos dispersos y por lotes, como integración en la nube y log de errores poco frecuentes.El valor predeterminado es Event flow.
Usado para:
Condiciones NRQL
El tiempo en segundos que se debe esperar después de recibir cada punto de datos para garantizar que se procese todo el lote. Requerido cuando se utiliza el tipo EVENT_TIMER
aggregation_method
. El valor predeterminado es 60 seconds.
Usado para:
- Condiciones NRQL
La transmisión recopila datos de alerta en períodos de tiempo específicos antes de ejecutar la función en la consulta NRQL. Estas ventanas de tiempo son personalizables.
Los puntos de datos se recopilan juntos según su marca de tiempo y se informan como un lote. La ventana de agregación personalizable proporciona mayor flexibilidad y menos incidentes falsos al alertar sobre puntos de datos irregulares o menos frecuentes.
En la UI, en Advanced signal settings, este es el campo Aggregation window.
El valor predeterminado es 60 seconds. El máximo es de 6 horas.
Usado para:
- Condiciones NRQL
De forma predeterminada, las ventanas de agregación se agrupan de forma secuencial. Esto puede generar gráficos con picos cada vez que se inicia una ventana y otra.
Utilice slide_by
para crear ventanas deslizantes. Las ventanas agregadas deslizantes se superponen, creando gráficos más fluidos. El intervalo slide_by
establece la duración de la superposición.
En la UI, en Advanced signal settings, haga clic en el botón Use sliding window aggregation para habilitar las ventanas deslizantes.
El valor predeterminado se basa en la duración de la ventana actual. El intervalo slide_by
debe dividirse equitativamente entre la duración de su ventana de agregación. El intervalo slide_by
también debe ser menor que la duración de la ventana.
En desuso en favor de un aggregation_method
con un aggregation_delay
o aggregation_timer
. La compensación es cuánto tiempo esperamos por los datos tardíos antes de evaluar cada ventana de agregación. Esperar más proporciona una señal más precisa pero aumenta la latencia. El valor predeterminado es 3 aggregation windows.
Usado para:
- Condiciones NRQL
Para datos esporádicos, puedes evitar alertas falsas llenando los espacios (ventanas vacías) con datos de Sintético.
none
: (Predeterminado) Utilice 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 abrirá un incidente.static
: utilice 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 defillValue
que especifica qué valor estático se debe utilizar. El valor predeterminado es 0.last_value
: Utilice esto para insertar el último valor visto antes de que se produzca la evaluación. Mantenemos el estado del último valor visto durante 2 horas.En la UI, en Advanced signal settings, este es el campo Fill data gaps with.
Usado para:
Condiciones NRQL
Este es el valor utilizado por el valor personalizado fill_option
. El valor predeterminado es 0
.
Usado para:
- Condiciones NRQL
Este es el tiempo (en minutos) que tarda la condición en persistir antes de desencadenar un evento. Corresponde a la duración establecida al agregar un umbral en la UI.
Usado para:
- Condiciones
- Condiciones NRQL
Esto determina qué comparación se utilizará entre el valor value_function y terms[threshold] para activar un evento. Corresponde a la operación seleccionada al agregar un umbral en la UI. Debe ser una de las siguientes cadenas:
arriba
above_or_equals (NRQL conditions only)
abajo
below_or_equals (NRQL conditions only)
igual
not_equals (NRQL conditions only)
Usado para:
Condiciones
Condiciones de servicio externo
Condiciones NRQL
Esto corresponde al nivel de gravedad seleccionado al configurar los valores de umbral para la condición en la UI. Esta debe ser una de las siguientes cadenas:
crítico
advertencia
Usado para:
Condiciones
Condiciones de servicio externo
Condiciones NRQL
Este es el umbral con el que se debe comparar value_function con el uso de terms[operator] para que se active un evento. Corresponde al valor numérico especificado en la UI al agregar los valores de umbral.
Este es un valor numérico y debe ser 0 (cero) o mayor.
Usado para:
- Condiciones
- Condiciones de servicio externo
- Condiciones NRQL
Esto corresponde a la configuración realizada en la UI al agregar los valores de umbral. Las opciones son:
todo (correspondiente a
for at least
en la UI)cualquiera (correspondiente a
at least once in
en la UI)Usado para:
Condiciones
Condiciones de servicio externo
Condiciones NRQL
Esto define el tipo de métrica que se utilizará para la alerta. El contenido permitido para el campo de métrica depende del valor type elegido.
Hay dos categorías de productos :
Para esta categoría, type se establece en una de las siguientes cadenas que indican el tipo de condición de alerta.
| Usar |
---|---|
apm_app_metric | La métrica de la aplicación activará una alerta. |
apm_app_metric_baseline | La métrica de la aplicación APM activará una alerta (utilizando un umbral de anomalía). |
apm_kt_metric | La métrica de transacción clave de APM activará una alerta. |
browser_metric | La métrica browser activará una alerta. |
browser_metric_baseline | La métrica browser activará una alerta (utilizando un umbral de anomalía). |
mobile_metric | La métrica móvil activará una alerta. |
Usado para:
- Condiciones
Para esta categoría, type se establece en una de las siguientes cadenas que indican el tipo de condición de servicio externo.
| Usar |
---|---|
apm_external_service | La métrica externa de APM activará una alerta. |
mobile_external_service | La métrica externa móvil activará una alerta. |
Usado para:
- Condiciones de servicio externo
Este es el nombre de un metric personalizado definido por el usuario que se utilizará para determinar si se debe activar un evento.
El user_defined[value_function] asociado con la métrica se compara con el valor terms[threshold] al evaluar si se debe desencadenar un incidente. La comparación se realiza utilizando el operador definido por terms[operator].
Usado para:
- Condiciones
- Condiciones de servicio externo
- Monitoreo de condiciones sintéticas
Este es el valor numérico obtenido de la métrica personalizada especificada por user_defined[metric].
Se compara con el valor terms[threshold] al evaluar si se debe desencadenar un incidente. La comparación se realiza utilizando el operador definido por terms[operator].
Deberá especificarse alguna de estas función de valor:
promedio
mín.
máx.
total
sample_size
Usado para:
Condiciones
Cuando se utiliza para una condición NRQL, las opciones son:
- single_value (la condición se evalúa en función del valor devuelto de cada consulta)
- sum (la condición se evalúa en función de la suma de los valores devueltos de cada consulta durante la duración especificada)
Úselo para cerrar automáticamente el incidente basado en instancia después de la cantidad de segundos especificada.
El valor predeterminado es 259,200 seconds (3 días). El máximo es 30 días.
Usado para:
- Condiciones de ubicación
- Condiciones NRQL
Úselo para cerrar automáticamente el incidente basado en instancia, incluido el incidente métrico de salud de JVM, después de la cantidad de horas especificada. Debe ser entre 1 y 720 horas. El valor predeterminado es 72 horas.
Usado para:
apm_app_metric
(concondition_scope
establecido eninstance
)apm_jvm_metric