Nombres de campos API de condición de alerta

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 administrar su alerta mediante programación. Para obtener más contexto, lea la Introducción a las API de y la inteligencia aplicada.

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 es false)
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.

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.

`type`	Parámetro
apm_app_metric	apdex error_percentage response_time_web response_time_background throughput_web throughput_background user_defined
apm_kt_metric	apdex error_percentage error_count response_time rendimiento
browser_metric	end_user_apdex total_page_load page_rendering web_application red dom_processing request_queuing ajax_response_time page_views_with_js_errors page_view_throughput ajax_throughput user_defined
browser_metric_baseline	page_view_throughput average_response_time ajax_response_time ajax_application_time
mobile_metric	Base de datos imágenes json, red view_loading network_error_percentage status_error_percentage user_defined

`type`	Parámetro
apm_external_service	apdex error_percentage response_time_web response_time_background throughput_web throughput_background user_defined
apm_app_metric_baseline	external_service_transaction_time error_count database_transaction_time throughput_web response_time_web non_web_transaction_time web_transaction_database_time non_web_transaction_database_time
mobile_external_service	response_time_average response_time_minimum response_time_maximum rendimiento network_failure_percentage http_status_error_percentage

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ón aggregation_delay , utilizando el tiempo de reloj como temporizador. Se requiere aggregation_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 valor aggregation_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). El aggregation_timer se restablece para cada nuevo punto de datos que llega para esa ventana. Una vez que aggregation_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 registro de errores poco frecuentes.
El valor predeterminado es Event flow.
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.

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 de fillValue 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

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

`type`	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.

`type`	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

Te ofrecemos esta traducción automática para facilitar la lectura.

Nombres de campos API de condición de alerta

Antes de usar la API REST .css-21sua1{background:none;border:none;width:0;padding:0;}

Campos obligatorios y opcionales

Definiciones de campo

activado

entidad

expiration[expiration_duration]

expiration[close_violations_on_expiration]

expiration[open_violation_on_expiration]

external_service_url

métrica

monitor_id

nombre

nrql[query]

nrql[since_value]

runbook_url

signal[aggregation_delay]

signal[aggregation_method]

signal[aggregation_timer]

signal[aggregation_window]

signal[slide_by]

signal[evaluation_offset]

signal[fill_option]

signal[fill_value]

terms[duration]

terms[operator]

terms[priority]

terms[threshold]

terms[time_function]

tipo

user_defined[metric] (opcional)

user_defined[value_function] (opcional)

value_function

violation_time_limit_seconds

violation_close_timer

Antes de usar la API REST