Condição do alerta nomes de campos da API

Os endpoints REST da API permitem criar condições para suas políticas. Este glossário contém os nomes e as descrições de cada um dos campos que você pode usar para definir ou atualizar uma condição.

Antes de usar a API REST

A API REST não é mais a forma preferencial de gerenciar programaticamente seu alerta. Para mais contexto, leia a introdução à API para e inteligência aplicada.

Campos obrigatórios e opcionais

A API inclui quatro tipos de condição do alerta:

APM
Serviços externos
NRQL
Monitoramento sintético

Todos os campos usados com um tipo de condição específico são obrigatórios, exceto estes campos opcionais:

enabled (o padrão é false)
runbook_url
user_defined

Definições de campo

Nem todos os campos listados neste glossário são obrigatórios para todos os tipos de condição. O tipo de condição para o qual um campo deve ser usado está listado em cada descrição.

O campo metric é usado para três categorias de alerta. O parâmetro exato disponível para uso depende da configuração no campo tipo . Eles estão listados abaixo de acordo com o campo do tipo de alerta.

O valor especificado no campo de tipo controla qual parâmetro pode ser especificado. O campo de tipo e os nomes parameter disponíveis correspondentes estão listados na tabela a seguir. Apenas um pode ser especificado.

`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 taxas de transferência
browser_metric	end_user_apdex total_page_load page_rendering web_application rede 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	banco de dados imagens json, rede 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 taxas de transferência network_failure_percentage http_status_error_percentage

O New Relic agrega dados em janelas e precisa determinar quando a janela atual termina e a próxima começa. O aggregation_method é a lógica que nos informa quando temos todos os dados para uma determinada janela de agregação. Depois que a janela é fechada, os dados são agregados em um único ponto e avaliados em relação ao limite.

Este campo é opcional. Um dos três valores a seguir pode ser especificado:

EVENT_FLOW: (Padrão) Cada janela de agregação aguardará até começar a ver a chegada do carimbo de data/hora que ultrapassou sua própria configuração de atraso. Quando isso ocorrer, os dados serão publicados. Depende do carimbo de data/hora dos dados recebidos, portanto o tempo transcorrido não é mais relevante. Funciona melhor para fontes que chegam com frequência e com baixa propagação de eventos (métrica de alto throughput).
CADENCE: Lógica clássica do New Relic onde cada janela de avaliação espera exatamente o tempo que a configuração aggregation_delay , usando o tempo transcorrido como cronômetro. aggregation_delay é necessário ao usar esta opção. Os dados que chegarem tarde demais serão descartados, o que pode causar alertas falsos.
EVENT_TIMER: cada janela de agregação possui um cronômetro, definido com o valor aggregation_timer . O cronômetro começa a funcionar assim que o primeiro ponto de dados aparece para essa janela de agregação (com base no timestamp de data/hora do ponto de dados). O aggregation_timer é redefinido para cada novo ponto de dados que chega nessa janela. Quando aggregation_timer atingir 0, a janela de agregação será publicada. Ideal para dados esparsos e em lote, como integração na nuvem e log de erros pouco frequentes.
O padrão é Event flow.
Usado para:
Condições NRQL

O alerta de streaming reúne dados em períodos específicos antes de executar a função na consulta NRQL. Essas janelas de tempo são personalizáveis.

Os pontos de dados são coletados juntos com base em seu carimbo de data/hora e relatados em lote. A janela de agregação personalizável oferece maior flexibilidade e menos incidentes falsos ao alertar sobre pontos de dados irregulares ou menos frequentes.

Na interface, em Advanced signal settings, este é o campo Aggregation window .

O padrão é 60 seconds. O máximo é de 6 horas.

Usado para:

Condições NRQL

Por padrão, as janelas de agregação são agrupadas sequencialmente. Isso pode levar a gráficos pontiagudos sempre que uma janela é iniciada e outra é iniciada.

Use slide_by para criar janelas deslizantes. As janelas agregadas deslizantes se sobrepõem, criando gráficos mais suaves. O intervalo slide_by define a duração da sobreposição.

Na interface, em Advanced signal settings, clique no botão de alternância Use sliding window aggregation para ativar as janelas deslizantes.

O padrão é baseado na duração atual da janela. O intervalo slide_by deve ser dividido igualmente pela duração da janela de agregação. O intervalo slide_by também deve ser menor que a duração da janela.

Para dados esporádicos, você pode evitar falsos alertas preenchendo as lacunas (janelas vazias) com dados Sintético.

none: (Padrão) Use isto se não quiser realizar nenhuma ação em janelas de agregação vazias. Na avaliação, uma janela de agregação vazia redefinirá o temporizador de duração limite. Por exemplo, se uma condição disser que todas as janelas de agregação devem ter pontos de dados acima do limite durante 5 minutos, e 1 das 5 janelas de agregação estiver vazia, então a condição não abrirá um incidente.
static: use isto se desejar inserir um valor estático personalizado nas janelas de agregação vazias antes de serem avaliadas. Esta opção tem um parâmetro adicional obrigatório de fillValue que especifica qual valor estático deve ser usado. O padrão é 0.
last_value: Use isto para inserir o último valor visto antes da avaliação ocorrer. Mantemos o estado do último valor visto por 2 horas.
Na interface, em Advanced signal settings, este é o campo Fill data gaps with .
Usado para:
Condições NRQL

Isso determina qual comparação será usada entre os valores value_function e terms[threshold] para acionar um evento. Corresponde à operação selecionada ao adicionar um limite na interface. Deve ser uma das seguintes strings:

acima
above_or_equals (NRQL conditions only)
abaixo
below_or_equals (NRQL conditions only)
igual
not_equals (NRQL conditions only)
Usado para:
Condições
Condições de serviço externo
Condições NRQL

Isso define o tipo de métrica que será usada para o alerta. O conteúdo permitido para o campo de métrica depende do valor type escolhido.

Existem duas categorias de produtos :

Para esta categoria, type é definido como uma das sequências a seguir indicando o tipo de condição do alerta.

`type`	Usar
apm_app_metric	a métrica do aplicativo acionará um alerta.
apm_app_metric_baseline	A métrica do aplicativo APM acionará um alerta (usando um limite de anomalia).
apm_kt_metric	A métrica de transação principal do APM acionará um alerta.
browser_metric	A métrica do browser acionará um alerta.
browser_metric_baseline	A métrica do browser acionará um alerta (usando um limite de anomalia).
mobile_metric	A métrica mobile acionará um alerta.

Usado para:

Condições

Para esta categoria, type é definido como uma das sequências a seguir, indicando o tipo de condição de serviço externo.

`type`	Usar
apm_external_service	A métrica externa do APM acionará um alerta.
mobile_external_service	A métrica externa mobile acionará um alerta.

Usado para:

Condições de serviço externo

Este é o nome de um metric customizado definido pelo usuário a ser usado para determinar se um evento deve ser acionado.

O user_defined[value_function] associado à métrica é comparado com o valor terms[threshold] ao avaliar se um incidente deve ser acionado. A comparação é realizada utilizando o operador definido por terms[operator].

Usado para:

Condições
Condições de serviço externo
Condições de monitoramento sintético

Esta tradução de máquina é fornecida para sua comodidade.

Condição do alerta nomes de campos da API

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

Campos obrigatórios e opcionais

Definições de campo

habilitado

entidade

expiration[expiration_duration]

expiration[close_violations_on_expiration]

expiration[open_violation_on_expiration]

external_service_url

métrica

monitor_id

nome

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 a API REST