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 evento de alerta. Recomendamos definir o nível de prioridade como critical para o seu primeiro alerta. Você pode saber mais sobre níveis de prioridade em nossa documentação de condições de alerta.

Em seguida, você deve escolher o que define um critical anomaly threshold breach. Para este primeiro alerta, recomendamos usar nossas configurações padrão e ajustar às suas necessidades conforme necessário. Portanto, deixe as configurações para abrir um evento de alerta "quando uma consulta retornar um valor que desvia do valor previsto: for at least five minutes em 3 standard deviations".

Saiba mais sobre anomalia em nossa documentação de anomalia.

/ <img title="Configure your anomaly thresholds" alt="A screenshot demonstrating how to configure custom anomalies" src="/images/alerts_screenshot-crop_configure-your-anomaly-thresholds.webp" /> /

Ao contrário dos limites de anomalia, um limite estático não analisa seu conjunto de dados como um todo nem determina qual comportamento é incomum com base no histórico do seu sistema. Em vez disso, um limite estático abrirá um evento de alerta sempre que seu sistema se comportar de maneira diferente dos critérios que você definiu. Os limites de alerta estáticos são muito mais personalizáveis, e nós os recomendamos se você tiver um conhecimento sólido dos seus dados e do que está procurando.

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

Às vezes, um sinal de entrada pode ser perdido, e é importante entender se é simplesmente um atraso ou uma indicação de um problema mais amplo. Nosso lost signal threshold nos permite saber quantos segundos o sistema deve aguardar a partir do momento em que o último ponto de dados foi detectado antes de considerar o sinal como perdido. Se o sinal não retornar antes do limite de tempo definido, você tem algumas opções: abrir um novo evento de alerta, fechar todos os eventos de alerta abertos e/ou pular a abertura de um evento de alerta quando o sinal estiver previsto para terminar. Clique aqui para saber mais sobre suas opções de limite de perda de sinal.

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 alert event.

/ <img title="" alt="" src="/images/alerts_screenshot-crop_lost-signal-threshold.webp"/> /

/ <img title="Window duration" alt="A screenshot depicting advanced custom settings for an alert condition." src="/images/alerts_screenshot-crop_window-duration.webp" /> /

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 fluem da sua aplicação para o New Relic. Em vez de avaliar esses dados imediatamente para eventos de alerta, as condições de alerta coletam os dados durante um período de tempo conhecido como aggregation window. Um atraso adicional permite que pontos de dados mais lentos cheguem antes que a janela seja 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 contra a coleta de dados inconsistente. Isso dá à condição de alerta uma pequena margem de manobra antes de decidir criar um evento de alerta. Se, em um determinado minuto, seus dados chegarem à New Relic com carimbos de data/hora de apenas um único minuto, então uma configuração de baixo atraso será suficiente. Por outro lado, se durante esse minuto a New Relic receber pontos de dados com carimbos de data/hora de vários minutos atrás ou vários minutos à frente, então seu sinal é mais inconsistente e precisará de uma configuração de atraso maior.

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 de alerta, esta é a nossa chance. Lembre-se de que uma política está conectada a fluxos de trabalho e os fluxos de trabalho controlam a frequência com que somos notificados sobre quaisquer eventos de alerta. É um equilíbrio delicado entre garantir que saibamos sobre quaisquer problemas com o tempo de transação web o mais rápido possível e garantir que não recebamos tantos alertas a ponto de nossos desenvolvedores sofrerem fadiga e começarem 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ê pode criar uma política que anexa apenas um problema por política (a opção padrão). Um problema por política reduz o ruído, mas também requer ação imediata. Mas isso significa que se você anexou várias condições a esta política, não apenas a Response time: Example app, então, independentemente do que aconteça, todos os eventos de alerta 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 evento de alerta, todos esses eventos de alerta serão agrupados em um único 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 é monitorar problemas de latência com o tempo de transação da web.

Ou poderíamos criar uma issue para cada evento de alerta. Esta opção é a mais ruidosa, mas pode funcionar bem se você deseja enviar informações para um sistema externo.

Saiba mais sobre como criar políticas aqui.

Um evento de alerta será fechado automaticamente quando o sinal alvo retornar a um estado de não violação pelo período de tempo indicado nos limites da condição. Este tempo de espera é chamado de período de recuperação.

Por exemplo, se o comportamento de violação for "o tempo de transação web é maior que .50 segundos pelo menos uma vez em 5 minutos," então o evento de alerta será encerrado automaticamente quando o tempo de transação da web for igual ou inferior a 0,50 por 5 minutos consecutivos.

Quando um evento de alerta fecha 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 evento de alerta anterior terminou.

   Todas as condições possuem uma configuração de limite de tempo de evento de alerta que forçará automaticamente o encerramento de um evento de alerta 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á problemas de latência com o tempo de transação da web, queremos garantir que nossos desenvolvedores tenham todas as informações necessárias quando forem notificados sobre esse evento de alerta. Vamos usar workflows para notificar um canal do Slack da equipe quando um evento de alerta for criado.

Saiba mais sobre descrições de eventos de alerta personalizados em nossa documentação.

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