A detecção de outliers da New Relic é um recurso avançado projetado para identificar automaticamente entidades que se comportam de maneira significativamente diferente de seus pares. Ao contrário da detecção de anomalias tradicional, que busca padrões incomuns ao longo do tempo, a detecção de outliers concentra-se em desvios dentro de um grupo em um momento específico.
Esta funcionalidade ajuda você a identificar proativamente problemas em potencial, como:
- Um único servidor apresentando alto uso de CPU comparado aos outros em seu cluster
- Um broker do Kafka não processando mensagens corretamente
Ao identificar esses "outliers", você pode encontrar rapidamente sistemas a jusante relacionados e inferir a probabilidade de falha, reduzindo assim o Tempo Médio para Detecção (MTTD) e o Tempo Médio para Recuperação (MTTR).
Conceitos chave
Compreender esses conceitos fundamentais ajudará você a configurar a detecção de outliers de forma eficaz:
DBSCAN: Um algoritmo de clusterização baseado em densidade que agrupa pontos que estão densamente concentrados, enquanto identifica outliers como pontos que não pertencem a nenhum cluster.
Epsilon (Eps): Define a distância máxima entre dois pontos para que eles sejam considerados parte da mesma vizinhança. Um valor menor cria clusters mais compactos, enquanto um valor maior cria clusters mais dispersos.
Pontos mínimos (MinPts): O número mínimo de pontos necessários para formar um cluster. Um valor maior que 3 é recomendado para a maioria dos casos de uso.
Grupos de avaliação: Permite segmentar sua análise de outliers por diferentes facetas (como ambiente, região ou aplicação), para que os outliers sejam detectados dentro de cada grupo separadamente, em vez de em todo o conjunto de dados. Isso garante que os outliers sejam detectados dentro de cada grupo separadamente, reduzindo a necessidade de múltiplas condições de alerta.
Modo automático vs. manual
Você tem dois modos distintos para definir os parâmetros principais, garantindo que você receba o alerta correto para seus dados:
Auto mode é a maneira mais rápida de configurar seu alerta de outlier. Isso permite ignorar os detalhes técnicos do algoritmo, eliminando a necessidade de entender parâmetros complexos de machine learning.
Em vez de configurar parâmetros técnicos, você ajusta um simples controle deslizante de sensibilidade. O sistema usa estimativas automáticas para calcular instantaneamente os valores ideais de Epsilon (Eps) e Pontos Mínimos (MinPts) correspondentes ao nível de sensibilidade selecionado.
Para verificar se as estimativas automáticas estão corretas para seus dados, observe a visualização de dados. Se os sinais identificados como outliers no gráfico estiverem alinhados com o seu entendimento de senso comum de uma anomalia, o modo automático está funcionando de forma eficaz.
Manual mode é para usuários avançados ou situações em que as estimativas automáticas do sistema não se ajustam perfeitamente às características únicas dos seus dados. Alternar para o modo manual permite controlar diretamente os parâmetros do DBSCAN.
Você deve alternar para o modo manual se os resultados do modo automático forem imprecisos:
- O sistema sinaliza sinais como outliers que visualmente ainda fazem parte de um cluster.
- O sistema falha em sinalizar um sinal que está claramente distante do cluster de dados principal.
- Mover o controle deslizante de Sensibilidade em toda a sua faixa produz pouca ou nenhuma alteração significativa nos outliers detectados.
Criar uma condição de alerta de detecção de outliers
Siga estas etapas para criar uma condição de alerta com detecção de outliers:
Na sua conta New Relic, acesse one.newrelic.com > All capabilities > Alerts > Alert Conditions.
Clique em + New alert condition e selecione Use guided mode ou o modo Query **. Independentemente de qual modo você escolher, você define limites para sua condição de alerta na página de definição de limites.
Siga as etapas até chegar à página de definição de limites.
Selecione outliers.
Escolha o modo do algoritmo:
- Se você escolher o modo Auto, ajuste o controle deslizante de sensibilidade para refinar a detecção. Neste modo, o sistema determina automaticamente os parâmetros internos ideais (como Epsilon e pontos mínimos para DBSCAN) com base em seus dados históricos.
- Se você escolher o modo Manual, poderá especificar os valores de Epsilon e Pontos mínimos.
Opcionalmente, configure um grupo de avaliação.
Conclua o restante da configuração da condição de alerta.
Melhores práticas de configuração
Escolhendo valores de epsilon
- Comece com valores padrão e ajuste com base nas características dos seus dados.
- Monitore as taxas de falsos positivos e ajuste de acordo.
- Épsilon menor para uma detecção mais sensível.
- Epsilon maior para detecção menos sensível.
Definindo pontos mínimos
- Use valores maiores que 3 para a maioria dos cenários.
- Valores mais altos reduzem o ruído, mas podem não detectar outliers sutis.
- Considere os tamanhos típicos dos seus grupos ao definir este valor.
Usando grupos de avaliação de forma eficaz
- Agrupe por limites lógicos (ambiente, região, serviço).
- Evite a segmentação excessiva, que pode reduzir a eficácia.
- Considere a sazonalidade e os padrões de negócios ao agrupar.
Tratamento de dados atrasados e timestamps mais antigos
A detecção de outlier funciona comparando métricas de múltiplas entidades no mesmo momento. Para fazer uma comparação justa, todas as entidades devem reportar dados para a mesma janela de tempo.
O problema com timestamps atrasados
Imagine que você está realizando o monitoramento do uso da CPU em três servidores às 14:00:
- Servidor A reporta 45% de CPU com timestamp
2:00 PM - Servidor B reporta 50% de CPU com timestamp
2:00 PM - Servidor C reporta 95% de CPU com timestamp
1:30 PM
Os dados do Servidor C têm um timestamp mais antigo (13:30 em vez de 14:00). O sistema não pode comparar dados das 13:30 com dados das 14:00 — é como comparar maçãs com laranjas. Como resultado, o Servidor C é totalmente excluído da análise de outlier. Mesmo que o Servidor C esteja claramente apresentando um problema, você não receberá um alerta porque ele nunca foi avaliado.
Isso acontece quando uma entidade reporta consistentemente dados com timestamps mais antigos do que a janela de tempo atual sendo analisada.
Causas comuns
Sondagem de provedor de nuvem: AWS CloudWatch e serviços semelhantes coletam métricas de forma programada, e o New Relic as consulta posteriormente. Por exemplo, uma métrica representando as 14:00 pode não chegar ao New Relic até as 14:05, criando um atraso de 5 minutos.
Transações de longa duração: os jobs em segundo plano recebem um timestamp quando começam, não quando terminam. Um job que começa às 13:30 e é executado por 30 minutos terá um timestamp de 13:30 quando seus dados chegarem às 14:00.
Dados em buffer: problemas de rede ou configurações do agente podem fazer com que os dados sejam enfileirados localmente. Quando a conectividade é restaurada, todos os dados em buffer chegam com seus timestamps originais.
Identificando entidades excluídas
Para ver quais entidades estão sendo excluídas e por que, consulte o evento NrAiSignal:
FROM NrAiSignalSELECT *WHERE conditionId = 1234 AND outlierProcessingSkippedReason IS NOT NULLSubstitua 1234 pelo ID da sua condição do alerta. Principais campos a examinar:
outlierProcessingSkippedReason: Por que o sinal foi excluído (normalmente mostraLATEpara dados atrasados)outlierProcessingSkippedTimeDelta: A diferença de tempo em segundos entre o timestamp dos dados e a janela de avaliação atual
Resolvendo o problema
Se você vir um aviso no editor de condições de que os sinais estão sendo excluídos:
Opção 1: dividir a condição (recomendado)
Crie condições do alerta separadas para entidades com comportamentos de relatório diferentes:
- Uma condição para servidores de aplicativos em tempo real
- Outra condição para recursos consultados na nuvem (como métricas do AWS CloudWatch)
Isso garante que a janela de agregação de cada condição corresponda à forma como suas entidades realmente reportam dados.
Opção 2: aumentar a janela de agregação
Expanda sua janela de agregação para acomodar atrasos. Por exemplo, se seus dados estão consistentemente 3–5 minutos atrasados, use uma janela de agregação de 5 minutos em vez de 1 minuto.
Trade-off: janelas maiores suavizam picos de curto prazo e aumentam o tempo antes que um alerta seja acionado. Um servidor que atinge um pico às 14:00 pode não acionar um alerta até as 14:05 ou mais tarde.
Casos de uso e exemplos
- Brokers Kafka desbalanceados: Identifique rapidamente brokers com tempos de espera de E/S da CPU anormais, permitindo que os administradores rebalanceiem proativamente as cargas de trabalho antes que o desempenho seja impactado.
- Outliers de utilização de recursos: Identifique recursos que estão consistentemente subutilizados ou superutilizados. Isso permite um melhor planejamento de capacidade e evita desperdícios ou possíveis gargalos.
- Identificação de "vizinho barulhento": Detecte entidades que monopolizam recursos e consomem uma quantidade desproporcional de recursos compartilhados. Isso permite uma ação corretiva para equilibrar a alocação de recursos.
- Problemas de memória em aplicações Java: Detecção precoce de Máquinas Virtuais Java (JVMs) com taxas anormais de erros de falta de memória (OOM), permitindo intervenção oportuna para evitar falhas generalizadas na aplicação.
- Monitoramento específico por ambiente: Use grupos de avaliação para monitorar ambientes de staging e produção separadamente, garantindo que outliers em um ambiente não interfiram na detecção em outro.