Condição do alerta

A duração da janela define como o New Relic agrupa seus dados para análise em uma condição do alerta. A escolha da configuração correta depende da frequência dos seus dados e do nível de detalhe desejado:

• High-frequency data (for example, pageviews every minute): defina a duração da janela para corresponder à frequência dos dados (1 minuto neste caso) para obter insights em tempo real sobre flutuações e tendências.

• Low-frequency data (for example, hourly signals): escolha uma duração de janela que capture dados suficientes para revelar padrões e anomalias (por exemplo, 60 minutos para sinais de hora em hora).

  Lembre-se de que você pode personalizar a duração da janela com base em suas necessidades e experiência. Recomendamos usar os padrões ao iniciar e experimentar à medida que você se sentir mais confortável criando a condição do alerta.

Os métodos de agregação tradicionais podem ser insuficientes ao lidar com dados pouco preenchidos ou que apresentam flutuações significativas entre intervalos. Veja como usar a agregação de janela deslizante para analisar esses dados e acionar alertas oportunos de maneira eficaz:

1. Smooth out the noise: comece criando uma grande janela de agregação. Essa janela (por exemplo, 5 minutos) atua como um buffer, suavizando o "ruído" ou a variabilidade inerente aos seus dados. Isso ajuda a evitar alertas falsos acionados por picos ou quedas isoladas.

2. Avoid lag with a sliding window: embora uma janela grande ajude na análise de dados, se você esperar que todo o intervalo decorra antes de verificar o limite, poderá ocorrer atrasos significativos na notificação de alertas. Recomendamos janelas deslizantes menores (por exemplo, um minuto). Imagine esta janela deslizante como um quadro móvel que examina seus dados dentro da janela de agregação maior. Cada vez que o quadro avança pelo seu intervalo menor, ele calcula um valor agregado (por exemplo, média).

3. Set your threshold duration: agora você pode definir seu limite de alerta no contexto da janela deslizante menor. Isso permite acionar alertas rapidamente quando o valor agregado no quadro atual se desvia significativamente do intervalo desejado, sem sacrificar o efeito de suavização da janela maior.

   Você pode aprender mais sobre agregação de janelas deslizantes neste tutorial NRQL.

Em geral, recomendamos usar o método de streaming event flow . Isso é melhor para dados que chegam ao seu sistema com frequência e de forma constante. Há casos específicos em que event timer pode ser o melhor método a ser escolhido, mas para seu primeiro alerta, recomendamos nosso padrão, event flow. Recomendamos assistir a este breve vídeo (aprox. 5:31 minutos) para entender melhor qual método de streaming escolher.

O recurso de atraso na condição do alerta protege contra possíveis problemas decorrentes da coleta inconsistente de dados. Ele atua como um buffer, permitindo mais tempo para que os dados cheguem e sejam processados antes de acionar um alerta. Isso ajuda a prevenir falsos positivos e garante uma criação de incidentes mais precisa.

Como funciona:

A configuração de atraso apropriada é determinada avaliando a consistência dos dados recebidos:

• Dados consistentes: uma configuração de atraso mais baixa é suficiente se os pontos de dados chegarem consistentemente com carimbo de data/hora dentro de um único minuto.

• Dados inconsistentes: se os pontos de dados chegarem com carimbo de data/hora abrangendo vários minutos no passado ou no futuro, será necessária uma configuração de atraso mais alta para acomodar a inconsistência.

  Criando um buffer:

• A configuração de atraso selecionada introduz um período de espera antes que a condição do alerta avalie os dados em relação ao limite definido.

• Esse buffer permite que as discrepâncias de dados sejam resolvidas, reduzindo a probabilidade de alertas enganosos.

Você está criando uma condição de alerta para notificar sua equipe sobre quaisquer problemas de latência no aplicativo WebPortal . Neste exemplo, seu aplicativo envia consistentemente dados do New Relic. Há um fluxo constante de sinais sendo enviados do seu aplicativo para o New Relic e não há nenhuma lacuna esperada no sinal, portanto, você não precisará selecionar uma estratégia de preenchimento de lacunas.

As estratégias de preenchimento de lacunas abordam cenários em que a recolha de dados pode ser intermitente ou incompleta. Eles fornecem um método para substituir pontos de dados faltantes por valores estimados, garantindo que a condição do alerta ainda possa funcionar de forma eficaz mesmo com lacunas no fluxo de dados.

Quando deixar o preenchimento de lacunas desativado:

• Consistent data flow: se o seu aplicativo envia dados consistentemente para o New Relic sem lacunas esperadas, como no caso do aplicativo WebPortal, o preenchimento de lacunas geralmente é desnecessário. Deixar a estratégia de preenchimento de lacunas definida como zero é muitas vezes a abordagem mais apropriada em tais casos.

  Consideracoes chave:

• Popular use case: Um uso comum de preenchimento de lacunas é inserir um valor 0 para janelas sem dados recebidos.

• Anomaly thresholds: O valor de preenchimento de lacuna é interpretado como o número de Desvio padrão do último valor observado ao usar o limite de anomalia. Por exemplo, preencher lacunas com um valor 0 replicaria o último valor visto, assumindo efetivamente nenhuma alteração.

  Saiba mais sobre estratégias de preenchimento de lacunas em nossos documentos sobre sinais perdidos.

O limite de anomalia é ideal quando você está mais preocupado com o Desvio a partir de padrões esperados do que com valores numéricos específicos. Eles permitem monitor atividades incomuns sem a necessidade de definir limites predefinidos. A detecção de anomalias do New Relic analisa dinamicamente seus dados ao longo do tempo, adaptando o limite para refletir a evolução do comportamento do sistema.

Configurando a detecção de anomalias:

1. Escolha superior ou inferior:

   • Selecione superior e inferior para ser alertado sobre qualquer Desvio superior ou inferior ao esperado.
   • Selecione apenas superior para focar apenas em valores excepcionalmente altos.

2. Atribuir prioridade:

   • Defina o nível de prioridade como crítico para o seu alerta inicial para garantir atenção prompt a possíveis problemas.

3. Defina critérios de violação:

   • Comece com as configurações padrão: abra um incidente quando uma consulta retornar um valor que se desvie do valor previsto por pelo menos cinco minutos por três Desvio padrão.
   • Personalize essas configurações conforme necessário para alinhá-las com seu aplicativo específico e requisitos de alerta.

   Você pode aprender mais sobre os níveis de prioridade em nossos documentos de condição do alerta.

   Saiba mais sobre o limite de anomalia e os comportamentos do modelo em nossa documentação de anomalia.

Ao contrário do limite anomalia, um limite estático não analisa seu conjunto de dados como um todo e determina qual comportamento é incomum com base no histórico do seu sistema. Em vez disso, um limite estático abrirá um incidente sempre que o seu sistema se comportar de forma diferente dos critérios que você definiu.

Você precisa definir o nível de prioridade para anomalia e limite estático. Consulte a seção acima para obter mais detalhes.

O limite do sinal de perda determina quanto tempo esperar antes de considerar a perda de um sinal perdido. Se o sinal não retornar nesse período, você poderá optar por abrir um novo incidente ou fechar qualquer incidente relacionado. Defina o limite com base no comportamento esperado do seu sistema e na frequência de coleta de dados. Por exemplo, se um site sofrer uma perda total de tráfego, ou taxas de transferência, os dados de telemetria correspondentes enviados à New Relic também cessarão. O monitoramento dessa perda de sinal pode servir como um sistema de alerta precoce para tais interrupções.

As práticas recomendadas para nomeação de condições envolvem um formato estruturado que transmite informações essenciais rapidamente. Inclua os seguintes elementos nos nomes das suas condições:

• Prioridade: Indica a gravidade ou urgência do alerta, como P1, P2, P3.

• Sinal: Especifique a métrica ou condição que está sendo monitorada, como Latência Média Alta ou Taxas de Transferência Baixas.

• Entidade: identifique o sistema, aplicativo ou componente afetado, como WebPortal App ou banco de dados Server.

  Um exemplo de nome de condição bem formado seguindo esta estrutura seria P2 | High Avg Latency | WebPortal App.

Se você já possui uma política que deseja conectar a uma condição do alerta, selecione a política existente.

Saiba mais sobre como criar políticas aqui.

Equilibrar capacidade de resposta e fadiga em sua estratégia de alertas é crucial, e você expôs as principais considerações sobre pageview monitoramento para seu aplicativo WebPortal . Vamos explorar as opções de política:

1. Um problema por política (padrão):

   • Prós: Reduz o ruído e garante ação imediata.
   • Contras: agrupa todos os incidentes sob um único problema, mesmo que sejam desencadeados por condições diferentes. Não é ideal para vários problemas de visualização de página.

2. Um problema por condição:

   • Prós: Cria problemas separados para cada condição, ideal para isolar e resolver problemas específicos de latência.
   • Contras: Pode gerar mais alerta, podendo levar à fadiga.

3. Um problema para cada incidente:

   • Prós: Fornece detalhes granulares para sistemas externos, mas não é ideal para consumo interno devido à sobrecarga potencial.
   • Contras: É a opção mais barulhenta e é um desafio acompanhar tendências mais amplas e priorizar de forma eficaz.

   Saiba mais sobre como criar políticas aqui.

Um incidente é encerrado automaticamente quando o sinal de destino retorna a um estado sem violação pelo período indicado no limite da condição. Esse tempo de espera é chamado de período de recuperação.

Por exemplo, se você estiver medindo a latência e o comportamento da violação for que duration para carregar páginas em seu aplicativo WebPortal aumentou para mais de 3 segundos, o incidente será encerrado automaticamente quando duration for igual ou menor que 3 segundos por 5 minutos consecutivos.

Quando um incidente é encerrado automaticamente:

1. O timestamp de fechamento é retroativo ao início do período de recuperação.

2. A avaliação é redefinida e reiniciada a partir do momento em que o incidente anterior terminou.

   Todas as condições têm uma configuração de limite de tempo de incidente que força automaticamente o fechamento de um incidente de longa duração.

   O padrão da New Relic é automaticamente de 3 dias e recomenda que você use nossas configurações padrão para seu primeiro alerta.

   Outra maneira de fechar um incidente aberto quando o sinal não retorna dados é configurar um limite loss of signal . Consulte a seção de limite de sinal perdido acima para obter mais detalhes.

Como você está criando uma condição de alerta que permite saber se há algum problema de latência com seu aplicativo WebPortal , você deseja garantir que seus desenvolvedores tenham todas as informações necessárias quando forem notificados sobre esse incidente. Você usará o fluxo de trabalho para notificar um canal do Slack da equipe quando um incidente for criado.

Saiba mais sobre descrições personalizadas de incidentes em nossos documentos.

Usar o modelo de título é opcional, mas recomendamos. Uma condição do alerta define um conjunto de limites que você deseja monitor. Se algum desses limites for violado, um incidente é criado. Modelos de títulos significativos ajudam você a identificar problemas e resolver interrupções com mais rapidez.

Saiba mais sobre modelos de títulos em nossos documentos.

Um runbook de operações detalhando as etapas de investigação, triagem ou remediação costuma estar vinculado a esse campo.