Crie seu primeiro alerta

Primeiro, vá para o gráfico denominado Web transactions time e clique em create an alert condition.

É importante dar um nome descritivo à sua condição do alerta. Digamos que você nomeie essa condição response time e, em seguida, crie outra condição para um aplicativo completamente diferente e rotule essa condição como response time também. Se isso ocorrer, você não conseguirá distinguir qual condição se aplica a qual aplicativo. Portanto, certifique-se de dar à sua condição um nome específico e exclusivo. Nesse caso, nomearíamos essa condição como Response time: Example-app.

Depois de nomear sua condição, você poderá fazer alterações na consulta NRQL, se desejar. Para seu primeiro alerta, recomendamos não ajustar a consulta NRQL e deixar esta seção como está, mas se quiser saber mais sobre como usar NRQL para personalizar suas consultas, visite nossa documentação.

Sua equipe está criando esta condição de alerta para que você seja notificado caso o tempo de transação web demore mais que o normal. Mas digamos que você não se importa com o tempo de transação na Web e deseja apenas saber se o tempo de transação está se comportando de maneira anormal. Para este caso de uso específico, recomendamos usar nosso anomaly threshold. Nossa detecção de anomalia avalia constantemente seus dados para entender como seu sistema normalmente se comporta. Ao definir um limite de anomalia, você pode usar nossa detecção de anomalia para alertar sua equipe se o tempo de transação da web se desviar do desempenho esperado. Como você deseja apenas saber se o tempo de transação da Web está se comportando de maneira incomum, selecione upper and lower porque deseja a notificação de todos os Desvio. Mas, se você quiser apenas um alerta se o tempo de transação na Web demorar mais que o normal, selecione upper only.

Em seguida, você precisa definir o nível de prioridade. O nível de prioridade determina o que criará um incidente. Recomendamos definir seu nível de prioridade como critical para seu primeiro alerta. Você pode aprender mais sobre os níveis de prioridade em nossos documentos de condição do alerta.

A seguir, você deve escolher o que define um critical anomaly threshold breach. Para este primeiro alerta, recomendamos usar nossas configurações padrão e ajustá-las às suas necessidades conforme necessário. Então, deixe as configurações para abrir um incidente “quando uma consulta retornar um valor desvia do valor previsto: for at least five minutes por 3 standard deviations ”.

Saiba mais sobre anomalia 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. Os limites de alerta estático são muito mais personalizáveis e nós os recomendamos se você tiver uma boa noção dos seus dados e do que procura.

Saiba mais sobre nossa condição estática do alerta em nossos documentos NRQL.

Às vezes, um sinal recebido pode ser perdido e é importante entender se é simplesmente um atraso ou uma indicação de um problema mais amplo. Nosso loss signal threshold nos permite saber quantos segundos o sistema deve esperar desde o momento em que o último ponto de dados foi detectado antes de considerar que o sinal foi perdido. Se o sinal não retornar antes do limite de tempo definido, você poderá escolher uma ou ambas as ações: abrir um novo incidente e/ou fechar todos os incidentes abertos. Você pode fechar qualquer incidente aberto relacionado se o sinal perdido substituir outro incidente nesta entidade ou se a perda de sinal for esperada.

Definir o limite do sinal perdido requer conhecimento do seu sistema e do que você deseja entender. No caso do tempo de transação na web, digamos que a New Relic coleta um sinal a cada minuto. Um sinal perdido pode indicar um problema de latência muito maior. Portanto, recomendamos definir o horário de acordo com seu nível de conforto e marcar a caixa open a new lost signal incident.

Definir a duração da janela para sua condição do alerta informa à New Relic como agrupar seus dados. Se você estiver criando uma condição do alerta para um conjunto de dados que envia um sinal para o New Relic uma vez a cada hora, você desejará definir a duração da janela para algo próximo de sessenta minutos, pois isso ajudará a detectar padrões e comportamentos incomuns. Mas, se você estiver criando uma condição de alerta para o tempo de transação da Web e o New Relic coletar um sinal para esses dados a cada minuto, recomendamos definir a duração da janela para um minuto.

Para o seu primeiro alerta, recomendamos manter nossas configurações padrão, mas quanto mais você se familiarizar com a criação de uma condição do alerta, encorajamos você a personalizar esses campos com base em sua própria experiência.

Ao longo do dia, os dados são transmitidos do seu aplicativo para o New Relic. Em vez de avaliar esses dados imediatamente quanto ao incidente, a condição do alerta coleta os dados durante um período conhecido como aggregation window. Um atraso adicional permite que pontos de dados mais lentos cheguem antes da janela ser agregada.

As janelas deslizantes são úteis quando você precisa suavizar gráficos "ponjosos". Um caso de uso comum é usar janelas deslizantes para suavizar gráficos de linha que apresentam muita variação em curtos períodos de tempo, em casos em que o agregado contínuo é mais importante do que agregados de janelas estreitas de tempo.

Recomendamos usar nossa agregação de janela deslizante se você não espera ter um fluxo de dados constante e consistente, mas espera algumas quedas e picos nos dados.

Você pode aprender mais sobre agregação de janelas deslizantes neste tutorial NRQL ou assistindo a este vídeo.

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. Para entender melhor qual método de streaming escolher, recomendamos assistir a este breve vídeo.

O recurso de atraso protege você contra coleta de dados inconsistente. Isso dá à condição do alerta um pouco de margem de manobra antes de decidir criar um incidente. Se em qualquer minuto seus dados chegarem ao New Relic com carimbo de data e hora de apenas um minuto, uma configuração de atraso baixo será suficiente. Por outro lado, se durante esse minuto o New Relic receber pontos de dados com carimbo de data/hora de vários minutos atrás ou vários minutos adiante, então seu sinal será mais inconsistente e precisará de uma configuração de atraso mais alta.

Estamos criando uma condição do alerta para notificar nossa equipe sobre quaisquer problemas de latência com o tempo de transação web. Nesse caso, nosso aplicativo envia consistentemente dados do New Relic. Há um fluxo constante de sinais sendo enviados de nosso aplicativo para o New Relic e não há lacuna esperada no sinal, portanto não precisaremos selecionar uma estratégia para preencher lacunas. Para este caso de uso e para seu primeiro alerta, recomendamos deixar gap-filling strategy definido como none.

Se você tiver um conjunto de dados mais inconsistente enviando sinais para a New Relic uma vez a cada vinte e quatro horas, recomendamos personalizar esse recurso com base nas necessidades específicas de sua equipe.

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

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.

Se quisermos criar uma nova política para esta condição do alerta, aqui está a nossa oportunidade. Lembre-se, uma política está conectada ao fluxo de trabalho e o fluxo de trabalho controla a frequência com que somos notificados sobre qualquer incidente. É um equilíbrio tênue entre garantir que aprendemos sobre quaisquer problemas com o tempo de transação da web o mais rápido possível e garantir que não recebamos tantos alertas que nossos desenvolvedores fiquem cansados e comecem a perder informações importantes devido à sobrecarga de informações.

As políticas podem conter uma ou várias condições. Se você deseja monitor a transação da latência da web, você tem algumas opções.

Primeiro, você poderia criar uma política que anexe apenas um único problema por política (a opção padrão). Uma questão por política reduz o ruído, mas também requer ação imediata. Mas isso significa que se você anexou diversas condições a esta política, não apenas a Response time: Example app, então, não importa o que aconteça, todos os incidentes nesta política serão agrupados em um único problema.

Ou poderíamos criar um problema por condição. Isso significa que sempre que a condição Response time: Example app abrir um incidente, todos esses incidentes serão agrupados em um problema conectado à nossa condição. Para este caso de uso específico, você deve escolher esta opção porque ela atende ao objetivo principal, que é monitor problemas de latência com o tempo de transação da web.

Ou poderíamos criar um problema para cada incidente. Esta opção é a mais barulhenta, mas pode funcionar bem se você quiser enviar informações para um sistema externo.

Saiba mais sobre como criar políticas aqui.

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

Por exemplo, se o comportamento de violação for "o tempo de transação na web é superior a 0,50 segundos pelo menos uma vez a cada 5 minutos", o incidente será encerrado automaticamente quando o tempo de transação na Web for igual ou inferior a 0,50 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çará automaticamente o fechamento de um incidente de longa duração.

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

Como estamos criando uma condição de alerta que nos permite saber se há algum problema de latência com o tempo de transação web, queremos garantir que nossos desenvolvedores tenham todas as informações necessárias quando forem notificados sobre esse incidente. Usaremos 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.

Se quiser vincular a um runbook, você pode colocar a URL no campo URL do runbook.