Criar condição de alerta NRQL

Recomendamos a criação de um alerta usando um NRQL condição do alerta. Este documento irá guiá-lo na formatação e configuração do seu NRQL condição do alerta para maximizar a eficiência e reduzir o ruído. Se você acabou de começar com New Relic ou ainda não criou uma condição do alerta, recomendamos começar com condição do alerta.

Você pode criar uma condição do alerta a partir de:

• Um gráfico
• Uma página de política
• A página Alert coverage gaps

Você também pode usar um de nossos criadores de alerta:

• Use Write your own query para criar alertas do zero.
• Use Guided modepara escolher entre as opções recomendadas e criar sua consulta NRQL para você.

Não importa onde você comece a criar uma condição de alerta, seja por meio de um gráfico ou escrevendo sua própria consulta, NRQL é o alicerce sobre o qual você pode definir seu sinal e definir seu limite.

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 min(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
  (
    SELECT min(cpuPercent) AS 'cpu'
    FROM SystemSample
    FACET hostname
  )

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

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 algumas ações.

• 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

  Quando um sinal é considerado perdido, você tem algumas opções:

  • Fechar todos os incidentes abertos atuais: Isso fecha todos os incidentes abertos relacionados a um sinal específico. Isso não necessariamente fechará todos os incidentes de uma condição. Se você estiver alertando sobre um serviço efêmero ou um sinal esporádico, você vai querer escolher esta ação para garantir que o incidente seja fechado corretamente. O nome do nó GraphQL para isso é closeViolationsOnExpiration.
  • Abrir novo incidente: Isso abrirá um novo incidente quando o sinal for considerado perdido. Esses incidentes indicarão que são devidos a uma perda de sinal. Com base nas suas preferências de incidente, isso deve acionar uma notificação. O nome do nó graphQL para isso é openViolationOnExpiration.
  • Ao habilitar ambas as ações acima, fecharemos todos os incidentes abertos primeiro e, em seguida, abriremos um novo incidente por perda de sinal.
  • Não abra o incidente "sinal perdido" no término esperado. Quando um sinal estiver previsto para terminar, você pode optar por não abrir um novo incidente. Isso é útil quando você sabe que um sinal será perdido em um determinado momento e não quer abrir um novo incidente para essa perda de sinal. O nome do nó GraphQL para isso é ignoreOnExpectedTermination.

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

1. Siga as instruções para criar um NRQL condição do alerta.
2. Na etapaSet thresholds você encontrará a opção Add lost signal threshold. Clique neste botão.
3. Defina o tempo de duração da expiração do sinal em minutos ou segundos no campo Consider the signal lost after .
4. Escolha o que você quer que aconteça quando o sinal for perdido. Você pode marcar qualquer uma ou todas as seguintes opções: Close all current open incidents, Open new "lost signal" incident, Do not open "lost signal" incident on expected termination. Elas controlam como a perda de sinal incidente será tratada para a condição.
5. Opcionalmente, você pode adicionar ou remover limites numéricos estáticos/anômalos. Uma condição que tem apenas um limite de perda de sinal e nenhum limite numérico estático/anômalo é válida e é considerada uma condição de perda de sinal "autônoma".

6. Continue seguindo os passos para salvar sua condição.
7. Se você selecionou Do not open "lost signal" incident on expected termination, deverá adicionar a tag termination: expected à entidade para evitar que um incidente de perda de sinal seja aberto. Veja como adicionar a tag diretamente na entidade.

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, Transaction, TransactionError 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

Condições HNR NRQL em modo guiado

O modo guiado de condição NRQL oferece uma experiência com curadoria para criar condições NRQL de infraestrutura "host não relatando" (HNR). Esta é a alternativa preferida à criação de condições de infraestrutura de "host sem relatórios".