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:
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 EventWHERE attribute [comparison] [AND|OR ...]
Clause | Notes |
---|---|
Required | As funções suportadas que retornam números incluem:
|
Required | Vários tipos de dados podem ser destino. Tipos de dados suportados:
|
| Use a cláusula |
| Inclua uma cláusula Use a cláusula A consulta facetada pode retornar no máximo 5.000 valores para condições estáticas e de anomalia . ImportanteSe 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 |
---|---|
| Exemplo:
As condições NRQL produzem um fluxo interminável de resultados de consulta em janela, portanto, as palavras-chave |
| Na consulta NRQL, a cláusula Para condições NRQL e se não estiver usando agregação de janela deslizante, a propriedade equivalente a |
| A função de agregação
|
| 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:
Decomposto:
|
| A cláusula |
| A cláusula 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
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. |
| Na consulta NRQL, a cláusula
|
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:
FROM
cláusula. Qual tipo de evento precisa ser capturado?WHERE
cláusula. O que pode ser filtrado?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:
- O sistema executará a cláusula
FROM
capturando todos os eventosSyntheticCheck
da sua conta. - 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. - Se ainda houver eventos para verificar após a conclusão das operações
FROM
eWHERE
, a cláusulaSELECT
será executada. Se não houver nenhum evento restante, a cláusulaSELECT
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
|
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:
|
Limites de condições | Veja os valores máximos. |
Estado de saúde | Para que uma NRQL condição de alerta status de saúde funcione corretamente, a consulta deve ter como escopo uma única entidade. Para fazer isso, use uma cláusula |
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 |
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 |
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 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
.
- 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 é
Importante
Para evitar que um incidente de perda de sinal seja aberto quando Do not open "lost signal" incident on expected termination, você deve adicionar a tag termination: expected
à entidade. Esta tag nos diz que esperávamos que o sinal terminasse. Veja como adicionar a tag diretamente na entidade.
Para criar um alerta NRQL configurado com detecção de perda de sinal na interface:
- Siga as instruções para criar um NRQL condição do alerta.
- Na etapaSet thresholds você encontrará a opção Add lost signal threshold. Clique neste botão.
- Defina o tempo de duração da expiração do sinal em minutos ou segundos no campo Consider the signal lost after .
- 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.
- 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".
Cuidado
Ao criar uma condição autônoma de perda de sinal, considere a consulta usada. Usar uma consulta complexa pode custar mais do que o necessário para monitor um sinal.
- Continue seguindo os passos para salvar sua condição.
- 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.
Dica
Você pode estar curioso para saber por que você desejaria ter Open new "lost signal" incident e Do not open "lost signal" incident on expected termination definidos como verdadeiros. Pense assim: você quer receber uma notificação quando perder o sinal. Só que você não quer uma notificação para o único momento em que sabe que o sinal vai parar porque você o programou. Nesse caso, você definiria ambos como verdadeiros e, quando esperasse que o sinal fosse perdido, adicionaria a tag termination: expected
à entidade relevante.
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, Transaction
, TransactionError
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
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".