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 preferida de gerenciar programaticamente seus alertas. Para obter mais contexto, leia a introdução à API de .
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_urluser_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.
Este campo permite definir o escopo de uma condição para uma instância da JVM ou para um aplicativo inteiro. Esta pode ser uma das strings:
instância
aplicativo
Usado para:
Condições
Condições da entidade
Para métricas de integridade baseadas em instância e JVM, consulte também
violation_close_timer.
Este é o status da sua condição do alerta e é opcional. O padrão é false.
Este campo pode ser utilizado para habilitar ou desabilitar uma condição para períodos de manutenção ou testes.
Usado para:
- Condições
- Condições de serviço externo
- Condições NRQL
- Condições de monitoramento sintético
Este é um array de IDs de entidades que identificam os objetos que serão monitorados com sua condição. Podem ser ID do aplicativo, IDs de browser, IDs principais de transação, IDs de serviços externos, etc.
Eles são inseridos como uma série de números inteiros separados por vírgula, se houver mais de um.
Usado para:
- Condições
- Condições de serviço externo
Quanto tempo esperar, em segundos, após o último ponto de dados ser recebido pela nossa plataforma antes de considerar o sinal perdido. Isso se baseia na hora em que os dados chegam e não no carimbo de data/hora dos dados. O padrão é nulo. Adicione um valor para ativar a detecção de perda de sinal.
Usado para:
- Condições NRQL
Quando true, isso fecha todos os incidentes atualmente abertos quando nenhum sinal é ouvido dentro do tempo expiration_duration .
O padrão é false.
Usado para:
- Condições NRQL
Quando verdadeiro, isso abre um incidente de perda de sinal quando não há sinal dentro do tempo expiration_duration .
O padrão é false.
Usado para:
- Condições NRQL
Esta é a URL do serviço externo a ser monitorado. Esta string não deve incluir o protocolo. Por exemplo, use example.com, não https://example.com.
Usado para:
- Condições de serviço externo
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.
| Parâmetro |
|---|---|
apm_app_metric |
|
apm_kt_metric |
|
browser_metric |
|
browser_metric_baseline |
|
mobile_metric |
|
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.
| Parâmetro |
|---|---|
apm_external_service |
|
apm_app_metric_baseline |
|
mobile_external_service |
|
Este é o GUID do monitoramento sintético para alertar.
Usado para:
- Condições de monitoramento sintético
Este título de condição permitirá identificá-la na interface.
Siga as diretrizes para torná-lo descritivo, mas curto.
Usado para:
- Condições
- Condições de serviço externo
- Condições NRQL
- Condições de monitoramento sintético
Esta é a consulta NRQL que alerta o monitor como parte de uma condição NRQL.
Usado para:
- Condições NRQL
Obsoleto em favor de um aggregation_method com um aggregation_delay ou aggregation_timer. Este é o período (em minutos) para avaliar a consulta NRQL especificada. since_value deve estar entre 1 e 20.
Usado para:
- Condições NRQL
A URL do runbook a ser exibida na notificação. Este campo é opcional.
Usado para:
- Condições
- Condições de serviço externo
- Condições NRQL
- Condições de monitoramento sintético
O tempo em segundos de espera até que a janela de agregação seja preenchida com dados. Obrigatório ao usar os tipos CADENCE ou evento aggregation_method . O padrão é 120 seconds.
Usado com métodos de fluxo de eventos e agregação de cadência.
Usado para:
- Condições NRQL
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çãoaggregation_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 valoraggregation_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). Oaggregation_timeré redefinido para cada novo ponto de dados que chega nessa janela. Quandoaggregation_timeratingir 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 tempo em segundos de espera após o recebimento de cada ponto de dados, para garantir que todo o lote seja processado. Obrigatório ao usar o tipo EVENT_TIMER aggregation_method . O padrão é 60 seconds.
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.
Obsoleto em favor de um aggregation_method com um aggregation_delay ou aggregation_timer. A compensação é quanto tempo esperamos pelos dados atrasados antes de avaliar cada janela de agregação. Esperar mais fornece um sinal mais preciso, mas aumenta a latência. O padrão é 3 aggregation windows.
Usado para:
- Condições NRQL
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 defillValueque 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
Este é o valor usado pelo valor personalizado fill_option . O padrão é 0.
Usado para:
- Condições NRQL
Este é o tempo (em minutos) para a condição persistir antes de disparar um evento. Corresponde à duração definida ao adicionar um limite na interface.
Usado para:
- Condições
- Condições NRQL
Este campo permite controlar o impacto de uma condição do alerta no estado de saúde da entidade associada. Para garantir que o status de saúde da entidade associada permaneça inalterado, mesmo quando incidentes de alerta forem acionados, defina-o como true. Corresponde à alternância Do not report system health status ao definir o limite para o alerta na interface.
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
Isto corresponde ao nível de gravidade selecionado ao definir os valores limite para a condição na interface. Esta deve ser uma das seguintes strings:
crítico
aviso
Usado para:
Condições
Condições de serviço externo
Condições NRQL
Este é o limite que o value_function deve ser comparado ao uso do terms[operator] para que um evento seja acionado. Corresponde ao valor numérico especificado na interface ao adicionar os valores limite.
Este é um valor numérico e deve ser 0 (zero) ou maior.
Usado para:
- Condições
- Condições de serviço externo
- Condições NRQL
Isto corresponde às configurações feitas na interface ao adicionar os valores limite. As opções são:
todos (correspondente a
for at leastna interface)qualquer (correspondente a
at least once inna interface)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.
| 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.
| 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
Este é o valor numérico obtido da métrica personalizada especificada por user_defined[metric].
Ele é 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].
Uma destas funções de valor deve ser especificada:
média
min
máx.
total
sample_size
Usado para:
Condições
Quando usado para uma condição NRQL, as opções são:
- single_value (a condição é avaliada com base no valor retornado de cada consulta)
- soma (a condição é avaliada com base na soma dos valores retornados de cada consulta durante a duração especificada)
Use para fechar automaticamente o incidente baseado em instância após o número de segundos especificado.
O padrão é 259,200 seconds (3 dias). O máximo é 30 dias.
Usado para:
- Condições de localização
- Condições NRQL
Use para fechar automaticamente o incidente baseado em instância, incluindo o incidente métrico de integridade da JVM, após o número de horas especificado. Deve estar entre 1 e 720 horas. O padrão é 72 horas.
Usado para:
apm_app_metric(comcondition_scopedefinido comoinstance)apm_jvm_metric