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 & AI > Alert Conditions & Policies para criar uma condição do alerta NRQL a partir de uma política. Em seguida, clique em + 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 ...]

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.

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

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

SELECT count(foo) from Transaction

SELECT average(bar) from Transaction

SELECT max(baz) from Transaction

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

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.

SELECT average(duration) FROM Transaction WHERE account_id in (91290, 102021, 20230)

SELECT percentile(duration, 95) FROM Transaction WHERE name LIKE 'Controller/checkout/%'

SELECT percentile(duration, 95) FROM Transaction

SELECT percentile(databaseDuration, 75) FROM Transaction

SELECT max(duration) FROM Transaction

SELECT average(duration) FROM Transaction

SELECT percentage(count(*), WHERE duration > 2) FROM Transaction

SELECT percentage(count(*), WHERE http.statusCode = '500') FROM Transaction

SELECT apdex(duration, t:0.5) FROM Transaction WHERE appName like '%prod%'

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.

SELECT max(cpu) FROM (FROM SystemSample SELECT min(cpuPercent) as 'cpu' FACET hostname) ​​​​

SELECT max(cpu) FROM (FROM Event SELECT min(cpuTime) as cpu TIMESERIES 30 seconds)​​

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

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

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:

Defina o limite de perda de sinal

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.

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

  .

Configurações avançadas de sinal

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.

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.

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.

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