Detecção de anomalia

A detecção de anomalia oferece à equipe um monitoramento flexível e adaptável para comportamentos incomuns nos sistemas. Em vez de depender de limites fixos, ela aprende os padrões normais dos dados e se ajusta automaticamente, reduzindo alarmes falsos e o excesso de alertas. É possível ajustar a sensibilidade, adicionar contexto personalizado às notificações de alerta e permitir que a New Relic aprenda as tendências de baseline automaticamente, ou definir as próprias.

Guia de início rápido

• Quando usar a detecção de anomalias
• Como funciona a detecção de anomalias
• Configurar limites
• Configurações de sazonalidade
• Direção da anomalia
• Entenda quando os alertas são acionados
• Condições de múltiplos sinais
• Ajuste os limites usando dados de sinal
• Solucionar problemas comuns

Quando usar a detecção de anomalia vs. limites estáticos

Os limites estáticos são fixados em números fixos. A detecção de anomalia avalia o comportamento matemático esperado de um sinal ao longo do tempo. Utilize esta tabela para escolher o modelo correto para a métrica:

Como funciona a detecção de anomalias

O New Relic avalia as tendências históricas para construir um baseline previsto e uma zona de variação aceitável (a faixa cinza) ao redor dele:

• Fase de aprendizado: o New Relic observa os dados por 1–4 semanas e aprende padrões como "as segundas-feiras são sempre movimentadas" ou "o tráfego cai às 18:00."
• Previsão: o sistema prevê qual deve ser o próximo ponto de dados, com base em padrões históricos.
• Zona de variação (faixa cinza): uma faixa de variação aceitável envolve a previsão. Pode ser considerado como uma estrada com guardrails — permanecer dentro dos guardrails é normal.
• Gatilho do alerta: um alerta é acionado apenas quando os dados reais saem da zona de variação e permanecem nela durante a duração especificada.

A New Relic também ajusta essas previsões automaticamente:

• Consistência de dados: métricas que permanecem em um intervalo estreito e previsível recebem faixas mais estreitas. Métricas ruidosas ou imprevisíveis recebem faixas mais largas, para evitar falsos alarmes.
• Flutuações cíclicas: o algoritmo procura padrões recorrentes com duração inferior a uma semana (como uma implantação na quarta-feira às 13h ou trabalhos em lote noturnos) e ajusta as previsões para corresponder.
• Idade dos dados: o New Relic calcula as previsões usando 1–4 semanas de histórico, dependendo da disponibilidade dos dados (as consultas que usam a cláusula FACET não são treinadas em dados armazenados e começam a aprender do zero). Quanto menos histórico um sinal tiver, mais a sua baseline flutuará. A precisão melhora à medida que mais dados se acumulam, e o New Relic dá mais peso aos dados recentes.

Configurar limites

Os limites de sensibilidade de anomalia controlam a facilidade com que os alertas são acionados. A sensibilidade mais alta captura alterações menores, mas pode criar mais alarmes falsos. A sensibilidade mais baixa alerta apenas sobre problemas maiores, mas pode perder problemas sutis.

Entender o gráfico de detecção de anomalias

Configurações de comportamento do gráfico:

• Janela de agregação: Aumentar isso torna a baseline mais estável e reduz a variação do sinal. Diminuí-lo resulta em um sinal com mais picos.
• Duração da janela: durações mais altas criam uma linha de sinal mais suave. Durações mais baixas resultam em um sinal mais pontiagudo e responsivo.

Controle de sensibilidade: faixas mais estreitas vs. mais largas

Isso controla diretamente a quantidade de alertas recebidos:

• Bandas mais estreitas (área cinza menor): mais próximo do baseline = mais eventos de alerta, porque os dados têm menos espaço para variação normal.
• Faixas mais largas (área cinza maior): mais distante da baseline = menos eventos de alerta, pois os dados podem variar mais antes de acionar alertas.

Exemplo: se a CPU normalmente opera a 50%:

• Banda mais estreita: alerta quando a CPU atinge 55% (mais sensível)
• Faixa mais larga: emite alertas quando a CPU atinge 70% (menos sensível).

É possível criar limites de sensibilidade de anomalia a partir de uma condição do alerta. Algumas dicas para definir limites de anomalia:

• Defina a sazonalidade para especificar um padrão de sazonalidade conhecido.
• Defina a direção da anomalia para monitorar eventos de alerta que ocorrem acima ou abaixo da anomalia.
• Use a barra deslizante para ajustar o limite de sensibilidade Critical, representado no gráfico de pré-visualização pela área cinza-clara ao redor do sinal. Quanto mais estreita for a faixa ao redor do sinal, mais sensível ela será e mais eventos de alerta gerará.
• Opcionalmente, adicione um limiteWarning (a área cinza mais escura ao redor do sinal) para receber notificações antecipadas antes que os problemas se tornem críticos. Isso proporciona tempo para investigar os problemas antes que eles acionem o alerta principal.

Siga estas etapas para criar uma condição de alerta de detecção de anomalia:

1. Vá para one.newrelic.com > All capabilities > Alerts > Alert Conditions.

2. Clique em + New alert condition > Use guided mode (ou no modo de consulta mais avançado).

3. Siga as etapas guiadas até chegar a Set thresholds.

4. Selecione Anomaly.

   

5. Na dropdown Calculate seasonality, escolha com que frequência os padrões de dados se repetem. Para mais detalhes, consulte Sazonalidade.

6. Na dropdown Threshold direction, escolha quando acionar alertas. Para mais detalhes, consulte Direção da anomalia.

7. Eventos de alerta abertos com um severity level. Escolher no dropdown:

   • Critical: Para problemas urgentes que exigem atenção imediata (faixa cinza-escura)
   • Warning: Para problemas menos urgentes que precisam de monitoramento (faixa cinza-clara, opcional)

   Um alerta de anomalia é acionado quando o sinal (linha verde) se afasta da baseline (linha preta pontilhada) por um número especificado de desvios-padrão. A área da faixa cinza representa o intervalo de limite.

   Importante

   Conceito crítico: o sinal deve permanecer em violação pela duração especificada antes de criar um evento de alerta — um pico breve que se autocorrige não acionará um. Consulte Entenda quando os alertas são acionados para ver a linha do tempo completa de como um alerta é aberto e fechado.

   Configurar as configurações de limite:

   • Escolher regras de tempo:

     • For at least - O sinal deve permanecer fora da banda durante todo o período antes de alertar. Reduz alarmes falsos.
     • At least once in - Alerta quando o sinal sai da banda dentro da janela de tempo. Detecção mais rápida.

   • Definir duração da violação: escolher no dropdown quanto tempo (em minutos) o sinal deve permanecer fora do limite:

     • Duração mais curta = mais eventos de alerta (mesmo violações breves acionam alertas)
     • Duração mais longa = menos eventos de alerta (apenas violações contínuas acionam alertas)

   • Definir nível de sensibilidade (desvios-padrão): Utilizar o controle deslizante para controlar o estreitamento da faixa:

     • Banda mais estreita (em direção a "mais eventos de alerta") = o sinal tem menos espaço para desvio, mais alertas
     • Faixa mais larga (em direção a "menos eventos de alerta") = o sinal tem mais espaço para desvio, menos alertas

   É possível adicionar mais um limite clicando em + Add threshold para criar níveis de aviso e críticos com diferentes configurações de sensibilidade.

8. Adicione os detalhes da condição do alerta e clique em Save condition.

Configurações de sazonalidade

A sazonalidade ajuda a detecção de anomalias a distinguir entre mudanças esperadas (como maior tráfego durante o horário comercial ou lentidão nos fins de semana) e problemas reais (como interrupções do sistema).

Direção da anomalia

É possível escolher se a condição deve procurar um comportamento que fique acima do valor previsto ("upper"), abaixo do valor previsto ("lower") ou ambos. Isso é escolhido com o seletor de direção de previsão, para qualquer condição — de sinal único ou de vários sinais.

Exemplos de casos de uso para isso:

• Você pode usar a configuração Superior para uma fonte de dados como taxa de erros, porque geralmente você só fica preocupado se ela aumentar e não se preocupar se ela diminuir.
• Você pode usar a configuração Inferior para uma fonte de dados como taxas de transferência, porque flutuações ascendentes repentinas são bastante comuns, mas uma grande queda repentina indicaria um problema.

Aqui estão exemplos de como grandes flutuações nos seus dados seriam tratadas nas diferentes configurações de direção de anomalia. As áreas vermelhas representam eventos de alerta.

Entenda quando os alertas são acionados

Os alertas de detecção de anomalia não são acionados no momento em que os dados tocam a faixa cinza de limite. O tempo depende das configurações de duração e de quanto tempo a violação persiste.

Isto é o que muitos clientes vivenciam:

Expectativa do cliente: "Minha CPU atingiu um pico de 90% e saiu da área cinza, então por que não recebi um alerta?"

Realidade: se o pico durar apenas 2 minutos, mas a duração estiver definida para 5 minutos, nenhum alerta será criado — mesmo que os dados tenham saído claramente das faixas cinzas.

Condições de múltiplos sinais

Dependendo de como a consulta NRQL foi definida ao criar a condição do alerta, ela pode estar monitorando muitos sinais, não apenas um. Ao trabalhar com NRQL, essas consultas usam a cláusulaFACET . Tenha em mente o seguinte:

• Limite de sinal: uma única condição do alerta de anomalia pode monitorar até 20.000 sinais individuais.
• Avaliação independente: cada sinal é rastreado e avaliado em relação à sua própria baseline histórica. Uma anomalia em um sinal aciona um incidente sem que o comportamento normal de outro sinal o distorça ou mascare.
• Configurações uniformes: as configurações de limite especificadas se aplicam da mesma forma a todos os sinais monitorados por esta condição, embora os baselines sejam calculados por sinal.
• Visualização do gráfico: é exibido um máximo de 500 sinais no gráfico de visualização. O sinal previsto e as faixas de limite não são exibidos quando há mais de um sinal no gráfico — selecionar uma única série temporal na legenda para isolar o seu baseline e os limites.

Ajuste os limites usando dados de sinal

Depois que uma condição avaliar os dados por alguns dias ou mais, não tente adivinhar um limite. Cada avaliação de condição de anomalia publica um evento NrAiSignal contendo o valor real, o valor previsto e o desvio padrão do erro de previsão (numberOfDeviations). Faça a consulta desses eventos para ver exatamente como o limite atua e para criar gráficos do sinal e das previsões em janelas de tempo mais longas do que o gráfico de visualização do editor de condições permite.

Encontrar o intervalo típico de desvios

Um histograma de numberOfDeviations ao longo de uma semana ou mais mostra o intervalo típico de desvios para o sinal, o que ajuda a escolher um limite inicial:

FROM NrAiSignal SELECT histogram(numberOfDeviations, start: -10, width: 20, buckets: 40) WHERE conditionId = YOUR_CONDITION_ID SINCE 1 week ago

Comparar desvios com um limite candidato ao longo do tempo

Trace os mesmos desvios como uma série temporal ao lado de uma linha de limite candidata, para ver com que frequência e em quanto o sinal a teria violado:

FROM NrAiSignal SELECT max(abs(numberOfDeviations)), 5 AS criticalValue WHERE conditionId = YOUR_CONDITION_ID SINCE 1 week ago TIMESERIES 28 minutes

Substitua 5 pelo limite candidato. Defina a janela TIMESERIES para um múltiplo da janela de agregação da condição e evite TIMESERIES MAX para esta comparação.

Calcular o desvio médio e de percentil

Para obter uma visão mais holística, calcule a média e o desvio padrão do percentil em uma janela mais longa. Por exemplo, este sinal de latência tem um pico de cerca de 120 ms:

Nesse mesmo momento, o desvio padrão é de cerca de 30,43:

Recomenda-se executar esta consulta para comparar o desvio padrão médio e do percentil com o limite atual:

SELECT average(deviations) AS 'avg', percentile(deviations, 75) AS 'p75', percentile(deviations, 95) AS 'p95' FROM (FROM NrAiSignal SELECT max(abs(numberOfDeviations)) AS 'deviations' WHERE conditionId = YOUR_CONDITION_ID TIMESERIES 1 hour LIMIT MAX) SINCE 1 week ago COMPARE WITH 2 weeks ago FACET string(7) AS 'Current Threshold'

Neste exemplo, um limite entre 10 e 17 seria mais adequado do que o limite atual de 7.

Verifique o comportamento do modelo

Trace o sinal real, o valor previsto e o limite calculado juntos para ver se o modelo está bem treinado e se o limite está bem calibrado:

FROM NrAiSignal SELECT latest(signalValue), latest(predictedValue), latest(predictedValue + (standardDeviation * {condition_threshold})) AS 'Upper Threshold' WHERE conditionId = {condition_id} SINCE 1 week ago TIMESERIES 30 minutes

• signalValue: O valor real do sinal da condição.
• predictedValue: o baseline calculado do modelo, que muda ao longo do tempo à medida que aprende tendências semanais e históricas.
• Limite superior/inferior: O limite alto ou baixo calculado a partir do limite de desvio padrão da condição.

Esta tendência mostra uma condição bem ajustada:

• O sinal não está consistentemente acima do limite superior, portanto, o limite de desvio padrão provavelmente está definido corretamente.
• O valor previsto acompanha o sinal real de perto, portanto, o modelo está bem treinado.

Utilizar isto para diagnosticar problemas:

• Se o sinal estiver consistentemente acima do limite superior ou abaixo do limite inferior, o limite de desvio padrão precisará de ajuste.
• Se a tendência do valor previsto variar muito do sinal real, o modelo precisará de mais tempo para aprender. Forneça mais dados antes de fazer mais ajustes.

Solucionar problemas comuns