• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

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

In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.

Criar um problema

Criar condição de alerta NRQL

Você pode usar a consulta NRQL para criar condição do alerta. Depois de definir seu sinal, você poderá definir ainda mais seus níveis de aviso e limite crítico. Isso determina quando um incidente de alerta é criado. Para obter mais informações sobre os principais conceitos relacionados à condição do alerta NRQL e ao alerta de streaming, consulte Alerta de streaming: termos e conceitos-chave.

Crie uma condição do alerta NRQL a partir de uma política

Vá para one.newrelic.com > All capabilities > Alerts > Alert Conditions & Policies para criar uma condição do alerta NRQL a partir de uma política. Em seguida, clique em + New alert condition.

Vá para one.newrelic.com > All capabilities > Alerts > Alert Conditions & Policies > + New alert condition.

Siga esses passos.

Crie uma condição a partir de um gráfico

A maioria dos nossos gráficos, com exceção de alguns mais antigos, permite criar uma condição a partir deles.

Para criar uma condição do alerta NRQL a partir de um gráfico:

  1. Vá para one.newrelic.com > All capabilities > APM & Services e selecione um aplicativo.

  2. No painel esquerdo, selecione Metrics explorer e adicione sua configuração.

  3. No canto direito do gráfico, clique no botão ícone e selecione Create alert condition.

  4. Siga as etapas explicadas em Criar uma condição do alerta NRQL a partir de uma política, mas esteja ciente de que a etapa 1 é um pouco diferente porque, agora, a consulta é construída com os dados que você configurou anteriormente.

Sintaxe de alerta NRQL

Aqui está a sintaxe básica para criar todas as condições do alerta NRQL.

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

Clause

Notes

SELECT function(attribute)

Required

As funções suportadas que retornam números incluem:

  • apdex

  • average

  • count

  • latest

  • max

  • min

  • percentage

  • percentile

  • sum

  • uniqueCount

    Dica

    Se você usar o agregador percentile em uma condição do alerta facetada com muitas facetas, isso poderá causar este erro:

    An error occurred while fetching chart data.

    Se você vir esse erro, use average .

FROM data type

Required

Vários tipos de dados podem ser destino.

Tipos de dados suportados:

  • Evento
  • Metric (Os pontos de dados RAW serão retornados)

WHERE attribute [comparison] [AND|OR ...]

Use a cláusula WHERE para especificar uma série de uma ou mais condições. Todos os operadores são suportados. É usado para filtrar os dados retornados na consulta.

FACET atributo

Inclua uma cláusula FACET opcional na sintaxe NRQL dependendo do tipo de limite (estático ou anomalia).

Use a cláusula FACET para separar seus resultados por atributo e alertar cada atributo de forma independente. Nenhuma cláusula LIMIT é permitida, mas todas as consultas receberão o máximo de facetas possíveis.

A consulta facetada pode retornar no máximo 5.000 valores para condições estáticas e de anomalia .

Importante

Se a consulta retornar mais que o número máximo de valores, a condição do alerta não poderá ser criada. Se você criar a condição e a consulta retornar mais que esse número posteriormente, o alerta falhará. Modifique sua consulta para que ela retorne um número menor de valores.

Reformatando NRQL incompatível

Alguns elementos do NRQL usados nos gráficos não fazem sentido no contexto do alerta de streaming. Aqui está uma lista dos elementos incompatíveis mais comuns e sugestões para reformatar uma consulta de alerta NRQL para obter o mesmo efeito.

Element

Notes

SINCE e UNTIL

Exemplo:

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

As condições NRQL produzem um fluxo interminável de resultados de consulta em janela, portanto, as palavras-chave SINCE e UNTIL para definir o escopo da consulta até um momento específico não são compatíveis. Por conveniência, removemos automaticamente SINCE e UNTIL de uma consulta ao criar uma condição no contexto de um gráfico.

TIMESERIES

Na consulta NRQL, a cláusula TIMESERIES é usada para retornar dados como uma série temporal dividida por um período de tempo especificado.

Para condições NRQL e se não estiver usando agregação de janela deslizante, a propriedade equivalente a TIMESERIES é a duração da janela de agregação de dados. Se você estiver usando agregação de janela deslizante, a propriedade equivalente será o valor da agregação de janela deslizante.

histogram()

A função de agregação histogram() é usada para gerar o histograma.

histogram() não é compatível com alertas NRQL: as agregações do histograma não podem ser formatadas como uma série temporal. Para criar um alerta a partir de uma parte de um histograma (por exemplo, percentil 95), use a função de agregação percentile() .

bytecountestimate(), cardinality()

Estas funções ainda não são suportadas para alertas NRQL.

Múltiplas funções de agregação

Cada condição só pode destinar um único valor agregado. Para alertar sobre vários valores simultaneamente, será necessário decompô-los em condições individuais dentro da mesma política.

Consulta original:

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

Decomposto:

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

COMPARE WITH

A cláusula COMPARE WITH é usada para comparar os valores de dois intervalos de tempo diferentes. Este tipo de consulta é incompatível com alertas NRQL. Recomendamos usar uma condição de anomalia do alerta para detectar dinamicamente o Desvio para um sinal específico.

SLIDE BY

A cláusula SLIDE BY oferece suporte a um recurso conhecido como janelas deslizantes. Com janelas deslizantes, SLIDE BY os dados são reunidos em "janelas" de tempo que se sobrepõem entre si. Essas janelas podem ajudar a suavizar gráficos de linha com muita variação nos casos em que o agregado móvel (como uma média móvel) é mais importante do que agregados de janelas estreitas de tempo.

Você pode ativar janelas deslizantes na interface. Ao criar ou editar uma condição, vá para Adjust to signal behavior > Data aggregation settings > Use sliding window aggregation.

Por exemplo, para criar uma condição do alerta equivalente a

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

Você usaria uma janela de agregação de dados com duração de 5 minutos, com uma janela de agregação deslizante de 1 minuto.

LIMIT

Na consulta NRQL, a cláusula LIMIT é usada para controlar a quantidade de dados que uma consulta retorna, seja o número máximo de valores de faceta retornados por FACET consulta ou o número máximo de itens retornados por SELECT \* consulta.

LIMIT não é compatível com alertas NRQL: a avaliação é sempre realizada no conjunto completo de resultados.

Subconsultas

As subconsultas não são compatíveis com streaming porque a execução da subconsulta requer diversas passagens pelos dados.

JOINs de subconsulta

Os JOINS de subconsulta não são compatíveis com alerta de streaming porque a execução da subconsulta requer múltiplas passagens pelos dados.

Exemplos de limite de alerta NRQL

Aqui estão alguns casos de uso comuns para condições NRQL. Estas consultas funcionarão para tipos de condições estáticas e de anomalia.

Condições NRQL e ordem de operações de consulta

Por padrão, a duração da janela de agregação é de 1 minuto, mas você pode alterar a janela de acordo com suas necessidades. Qualquer que seja a janela de agregação, o New Relic coletará dados para essa janela usando a função na consulta da condição NRQL. A consulta é analisada e executada por nossos sistemas na seguinte ordem:

  1. FROM cláusula. Qual tipo de evento precisa ser capturado?
  2. WHERE cláusula. O que pode ser filtrado?
  3. SELECT cláusula. Quais informações precisam ser retornadas do conjunto de dados agora filtrado?

Exemplo: valor nulo retornado

Digamos que esta seja a sua consulta de condição de alerta:

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

Se não houver falhas na janela de agregação:

  1. O sistema executará a cláusula FROM capturando todos os eventos SyntheticCheck da sua conta.
  2. Em seguida, ele executará a cláusula WHERE para filtrar esses eventos, procurando apenas aqueles que correspondem ao nome do monitor e ao resultado especificado.
  3. Se ainda houver eventos para verificar após a conclusão das operações FROM e WHERE , a cláusula SELECT será executada. Se não houver nenhum evento restante, a cláusula SELECT não será executada.

Isso significa que agregadores como count() e uniqueCount() nunca retornarão um valor zero. Quando há uma contagem de 0, a cláusula SELECT é ignorada e nenhum dado é retornado, resultando em um valor de NULL.

Exemplo: valor zero retornado

Se você tiver uma fonte de dados que fornece zeros numéricos legítimos, a consulta retornará valores zero e não valores nulos.

Digamos que esta seja sua consulta de condição do alerta e que MyCoolEvent seja um atributo que às vezes pode retornar um valor zero.

SELECT average(MyCoolAttribute) FROM MyCoolEvent

Se, na janela de agregação que está sendo avaliada, houver pelo menos uma instância de MyCoolEvent e se o valor médio de todos os atributos MyCoolAttribute dessa janela for igual a zero, então será retornado um valor 0 . Se não houver nenhum evento MyCoolEvent durante esse minuto, então um NULL será retornado devido à ordem das operações.

Exemplo: valor nulo vs. valor zero retornado

Para determinar como os valores nulos serão tratados, ajuste as configurações de perda de sinal e preenchimento de lacunas na condição do alerta interface.

Você pode evitar valores NULL totalmente com um atalho de ordem de consulta de operações. Para fazer isso, use uma subcláusula filter e inclua todos os elementos de filtro dentro dessa subcláusula. O corpo principal da consulta deve incluir uma cláusula WHERE que defina pelo menos uma entidade para que, para qualquer janela de agregação onde o monitor realize uma verificação, o sinal seja vinculado a essa entidade. A cláusula SELECT será então executada e aplicará os elementos de filtro aos dados retornados pelo corpo principal da consulta, que retornará um valor de 0 se os elementos de filtro não resultarem em dados correspondentes.

Aqui está um exemplo para alertar sobre FAILED resultados:

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

Neste exemplo, uma janela com um resultado bem-sucedido retornaria 0, permitindo que o limite da condição fosse resolvido por conta própria.

Para obter mais informações, confira nossa postagem no blog sobre resolução de problemas para valores zero versus valores nulos.

Alerta NRQL de agregação aninhada

As consultas de agregação aninhadas são uma forma poderosa de consultar seus dados. No entanto, eles têm algumas restrições que é importante observar.

Dicas de criação de condição NRQL

Aqui estão algumas dicas para criar e usar uma condição NRQL:

Tema

Pontas

Tipos de condição

Os tipos de condição NRQL incluem estática e anomalia.

Crie uma descrição

Para condições NRQL, você pode criar uma descrição personalizada para adicionar a cada incidente. As descrições podem ser aprimoradas com substituição de variáveis com base em metadados no incidente específico.

Resultados da consulta

Consulta deve retornar um número. A condição avalia o número retornado em relação ao limite que você definiu.

Período de tempo

As condições NRQL avaliam os dados com base em como eles são agregados, usando janelas de agregação de 30 segundos a 120 minutos, em incrementos de 15 segundos. Para obter melhores resultados, recomendamos usar os métodos de agregação de fluxo de eventos ou temporizador de eventos.

Para o método de agregação de cadência, a cláusula SINCE ... UNTIL implícita que especifica qual minuto avaliar é controlada pela configuração de atraso/temporizador . Como os dados muito recentes podem estar incompletos, você pode querer consultar os dados de 3 minutos atrás ou mais, especialmente para:

  • Aplicativo que é executado em vários hosts.

  • SyntheticCheck dados: os tempos limite podem levar 3 minutos, portanto, 5 minutos ou mais são recomendados.

    Além disso, se uma consulta gerar dados intermitentes, considere usar a opção de sinal avançado slide by .

Limite de sinal perdido (perda de detecção de sinal)

Você pode usar a detecção de perda de sinal para alertar quando seus dados (um sinal de telemetria) devem ser considerados perdidos. Uma perda de sinal pode indicar que um serviço ou entidade não está mais online ou que um trabalho periódico falhou na execução. Você também pode usar isso para garantir que os incidentes de dados esporádicos, como contagens de erros, sejam fechados quando nenhum sinal estiver chegando.

Configurações avançadas de sinal

Essas configurações oferecem opções para lidar melhor com sinais de dados de streaming contínuos que às vezes podem estar faltando. Essas configurações incluem a duração da janela de agregação, o atraso/temporizador e uma opção para preencher lacunas de dados. Para obter mais informações sobre como usá-los, consulte Configurações avançadas de sinal.

Configurações de condição

Use Condition settings para:

  • Crie um nome de condição conciso e descritivo.

  • Forneça uma descrição personalizada do incidente para a condição na página

    Add details

    que será incluída nos incidentes e na notificação.

  • Adicione a URL do runbook para incluir os procedimentos da sua organização para lidar com incidentes. Você também pode adicionar essas informações à descrição personalizada do incidente.

Limites de condições

Veja os valores máximos.

Estado de saúde

Para que uma condição de alerta status de saúde do NRQL funcione corretamente, a consulta deve ter como escopo uma única entidade. Para fazer isso, use uma cláusula WHERE (por exemplo, WHERE appName = 'MyFavoriteApp') ou uma cláusula FACET para definir o escopo de cada sinal para uma única entidade (por exemplo, FACET hostname ou FACET appName).

Exemplos

Para mais informações, veja:

Gerenciando tags em condições

Ao editar uma condição NRQL existente, você tem a opção de adicionar ou remover a tag associada à entidade da condição. Para fazer isso, clique no botão Manage tags abaixo do nome da condição. No menu que aparece, adicione ou exclua uma tag.

As edições de condições podem redefinir a avaliação de condições

Ao editar a condição do alerta do NRQL de algumas maneiras específicas (detalhadas abaixo), suas avaliações são redefinidas, o que significa que qualquer avaliação até esse ponto é perdida e a avaliação recomeça a partir desse ponto. As duas maneiras pelas quais isso afetará você são:

  • Para o limite "por pelo menos x minutos": como a janela de avaliação foi redefinida, haverá um atraso de pelo menos x minutos antes que qualquer incidente possa ser relatado.
  • Para condições de anomalia: a condição recomeça e todo o aprendizado da anomalia é perdido.

As ações a seguir causam uma redefinição de avaliação para condições NRQL:

  • Alterando a consulta
  • Alterar a janela de agregação, o método de agregação ou a configuração de atraso/temporizador de agregação
  • Alterando a configuração "fecho incidente na perda de sinal"
  • Alterando quaisquer configurações de preenchimento de lacuna
  • Alterar a direção da anomalia (se aplicável) – superior, inferior ou superior/inferior
  • Alterar o valor limite, a janela limite ou o operador limite
  • Alterar o intervalo de deslizamento (somente em condições de agregação de janelas deslizantes )

As seguintes ações (juntamente com quaisquer outras ações não incluídas na lista acima) não redefinirão a avaliação:

  • Alteração da janela de tempo de perda de sinal (duração da expiração)
  • Alterar a função de tempo (alterar "pelo menos" para "pelo menos uma vez" ou vice-versa)
  • Alternando a configuração "incidente aberto em caso de perda de sinal"

Condição do alerta tipos

Ao criar um alerta NRQL, você pode escolher entre diferentes tipos de condições:

Condição NRQL dos tipos de alerta

Descrição

Estático

Este é o tipo mais simples de condição NRQL. Ele permite criar uma condição baseada em uma consulta NRQL que retorna um valor numérico.

Opcional: inclua uma cláusula FACET .

anomalia (anomalia dinâmica)

Usa uma condição autoajustável com base no comportamento anterior dos valores do monitor. Usa o mesmo formulário de consulta NRQL que o tipo estático, incluindo a cláusula opcional FACET .

Defina o limite de perda de sinal

Importante

O recurso de perda de sinal requer que um sinal esteja presente antes de poder detectar que o sinal foi perdido. Se você ativar uma condição enquanto um sinal não estiver presente, nenhuma perda de sinal será detectada e o recurso de perda de sinal não será ativado.

A perda de sinal ocorre quando nenhum dado corresponde à condição NRQL durante um período específico de tempo. Você pode definir a duração do limite de perda de sinal e também o que acontece quando o limite é ultrapassado.

Vá para one.newrelic.com > All capabilities > Alerts > Alert conditions (Policies) e depois + New alert condition. A perda de sinal está disponível apenas para condições NRQL.

Você também pode gerenciar essas configurações usando a API GraphQL (recomendado) ou a API REST. Clique aqui para obter exemplos específicos da API GraphQL.

Loss of signal settings:

As configurações de perda de sinal incluem uma duração de tempo e duas ações possíveis.

  • Signal loss expiration time

    • Rótulo de interface:

      Signal is lost after:

    • Nó GraphQL: expiration.expirationDuration

    • A duração da expiração é um temporizador que inicia e reinicia quando recebemos um ponto de dados no pipeline de alerta de streaming. Se não recebermos outro ponto de dados antes que o seu 'tempo de expiração' expire, consideramos que o sinal foi perdido. Isso pode ocorrer porque nenhum dado está sendo enviado para o New Relic ou a cláusula WHERE da sua consulta NRQL está filtrando esses dados antes de serem transmitidos para o pipeline de alerta. Observe que quando você tem uma consulta facetada, cada faceta é um sinal. Portanto, se qualquer um desses sinais terminar durante o período especificado, isso será considerado uma perda de sinal.

    • O tempo de expiração da perda do sinal é independente da duração do limite e é acionado assim que o temporizador expira.

    • A duração máxima de expiração é de 48 horas. Isto é útil no monitoramento para a execução de trabalhos pouco frequentes. O mínimo é 30 segundos, mas recomendamos usar pelo menos 3 a 5 minutos.

  • Loss of signal actions

    Depois que um sinal for considerado perdido, você poderá fechar o incidente aberto, abrir o novo incidente ou ambos.

    • Fechar todos os incidentes abertos atuais: Fecha todos os incidentes abertos relacionados a um sinal específico. Não fechará necessariamente todos os incidentes de uma condição. Se você estiver alertando sobre um serviço efêmero ou sobre um sinal esporádico, escolha esta ação para garantir que os incidentes sejam fechados corretamente. O nome do nó GraphQL para isso é "closeViolationsOnExpiration"
    • Abrir novos incidentes: abrirá um novo incidente quando o sinal for considerado perdido. Esses incidentes indicarão que são devidos a perda de sinal. Com base nas suas preferências de incidente, isso deverá acionar uma notificação. O nome do nó graphQL para isso é "openViolationOnExpiration"
    • Quando você habilita ambas as ações, fecharemos primeiro todos os incidentes abertos e depois abriremos um novo incidente por perda de sinal.

Para criar um alerta NRQL configurado com detecção de perda de sinal na interface:

  1. Para uma política, ao criar uma condição, em

    Select a product

    , clique em

    NRQL

    e em

    Next, define thresholds

    .

  2. Escreva uma consulta NRQL que retorne os valores sobre os quais você deseja alertar.

  3. Para

    Threshold type

    , selecione

    Static

    ou

    Anomaly

    .

  4. Clique em

    + Add lost signal threshold

    e defina o tempo de expiração do sinal em minutos ou segundos no campo

    Consider the signal lost after

    .

  5. Escolha o que você deseja que aconteça quando o sinal for perdido. Você pode verificar um ou ambos

    Close all current open incidents

    e

    Open new "lost signal" incident

    . Eles controlam como o incidente de perda de sinal será tratado para a condição.

  6. Certifique-se de nomear sua condição antes de salvá-la.

Incidente aberto por perda de sinal de fechamento quando:

  • o sinal volta. O incidente de sinal perdido recém-aberto será fechado imediatamente quando novos dados forem avaliados.

  • a condição a que pertencem expira. Por padrão, as condições expiram após 3 dias.

  • você fecha manualmente o incidente com a opção

    Close all current open incidents

    .

Dica

A detecção de perda de sinal não funciona em consultas NRQL que usam agregação aninhada ou subconsulta.

Configurações avançadas de sinal

Ao criar uma condição de alerta NRQL, use as configurações avançadas de sinal para controlar o streaming de dados de alerta e evitar alarmes falsos.

Ao criar uma condição NRQL, existem várias configurações avançadas de sinal:

  • Duração da janela de agregação
  • Agregação de janela deslizante
  • Método de streaming
  • Atraso/temporizador
  • Preencha lacunas de dados
  • Atraso na avaliação

Para ler uma explicação sobre o que são essas configurações e como elas se relacionam entre si, consulte Conceitos de alerta de streaming. Abaixo estão instruções e dicas sobre como configurá-los.

Duração da janela de agregação

Você pode definir a duração da janela de agregação para escolher por quanto tempo os dados serão acumulados em uma janela de tempo de streaming antes de serem agregados. Você pode configurá-lo para qualquer coisa entre 30 segundos e 120 minutos. O padrão é um minuto.

Agregação de janela deslizante

Você pode usar janelas deslizantes para criar gráficos mais suaves. Isso é feito criando janelas de dados sobrepostas.

Aprenda como configurar janelas deslizantes neste pequeno vídeo (2:30 minutos):

Uma vez ativado, defina o "intervalo de deslizamento" para controlar quanto tempo de sobreposição suas janelas agregadas têm. O intervalo deve ser menor que a janela de agregação e, ao mesmo tempo, dividir-se igualmente nela.

Importante

Imediatamente após você criar uma nova janela deslizante condição do alerta ou executar qualquer ação que possa causar uma redefinição de avaliação, sua condição precisará de tempo para criar um "buffer agregado" durante a primeira janela de agregação. Durante esse período, nenhum incidente será desencadeado. Depois que essa única janela de agregação tiver passado, um "buffer" completo terá sido construído e a condição funcionará normalmente.

Método de streaming

Escolha entre três métodos de agregação de streaming para obter os melhores resultados de avaliação para suas condições.

Atraso/temporizador

Você pode ajustar o atraso/temporizador para coordenar nosso algoritmo de alerta de streaming com o comportamento dos seus dados. Se seus dados forem esparsos ou inconsistentes, você pode usar o método de agregação de temporizador de evento.

Para o método de cadência, a latência total suportada é a soma da duração da janela de agregação e do atraso.

Se o tipo de dados vier de um agente de linguagem APM e for agregado de muitas instâncias de aplicativo (por exemplo, Transactions, TransactionErrors etc.), recomendamos usar o método de fluxo de eventos com as configurações padrão.

Importante

Ao criar condições NRQL para dados coletados de infraestrutura de integração na nuvem, como AWS CloudWatch ou Azure, recomendamos que você use o método de timer de evento.

Preencha lacunas de dados

O preenchimento de lacunas permite personalizar os valores a serem usados quando seus sinais não possuem dados. Você pode preencher lacunas em seus fluxos de dados com uma destas configurações:

  • None

    : (Padrão) Escolha esta opção 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 será um incidente.

  • Custom static value

    : escolha esta opção 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 (conforme nomeado na API) que especifica qual valor estático deve ser usado. O padrão é 0.

  • Last known value

    : esta opção insere o último valor visto antes da avaliação ocorrer. Mantemos o estado do último valor visto por no mínimo 2 horas. Se a duração do limite configurada for superior a 2 horas, esse valor será mantido durante essa duração.

Dica

O sistema de alerta preenche lacunas nos sinais reportados ativamente. Este histórico de sinais é eliminado após um período de inatividade e, para preencher lacunas, os pontos de dados recebidos após este período de inatividade são tratados como novos sinais. A duração da inatividade é de 2 horas ou a duração limite configurada, o que for maior.

Para saber mais sobre perda de sinal, preenchimento de lacunas e como solicitar acesso a esses recursos, veja este post do Fórum de Suporte.

Opções para editar configurações de lacuna de dados:

  • Na interface das condições NRQL, acesse

    Condition settings > Advanced signal settings > fill data gaps with

    e escolha uma opção.

  • Se estiver usando nossa API Nerdgraph (preferencial), este nó está localizado em: actor : account : alerts : nrqlCondition : signal : fillOption | fillValue

  • NerdGraph é nossa API recomendada para isso, mas se você estiver usando nossa API REST, poderá encontrar essa configuração no explorador da API REST na seção

    "signal"

    da API de condições NRQL de alerta.

Atraso na avaliação

Você pode ativar a sinalização Use evaluation delay e configurar até 120 minutos para atrasar a avaliação dos sinais recebidos.

Quando novas entidades são implantadas pela primeira vez, a utilização de recursos na entidade é muitas vezes invulgarmente elevada. Em ambientes de autoescala, isso pode facilmente criar muitos alertas falsos. Ao atrasar o início da detecção de alertas sobre sinais emitidos por novas entidades é possível reduzir significativamente o número de falsos alarmes associados à implantação em ambientes orquestrados ou de autoescala.

Opções para ativar o atraso na avaliação:

  • Na interface de condições NRQL, acesse

    Adjust to signal behavior > Use evaluation delay

    .

  • Se estiver usando nossa API Nerdgraph, este nó está localizado em: actor : account : alerts : nrqlCondition : signal : evaluationDelay

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.