Esta tradução de máquina é fornecida para sua comodidade.
In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.
Uma condição do alerta é o elemento central que define quando um incidente é criado. Ele atua como ponto de partida essencial para a construção de qualquer alerta significativo. condição do alerta contém o parâmetro ou limite atendido antes de você ser informado. Eles podem mitigar alertas excessivos ou avisar sua equipe quando surgir um comportamento novo ou incomum.
A página Alert conditions list é o centro universal para todas as suas condições de alerta.
Crie uma nova condição do alerta
Uma condição de alerta é uma consulta em execução contínua que mede um determinado conjunto de eventos em relação a um limite definido e abre um incidente quando o limite é atingido por um período de tempo especificado.
Este exemplo demonstra a criação manual de uma nova condição do alerta usando a página Alert condition details . Mas existem muitas maneiras de criar uma condição de alerta. Você pode criar uma condição do alerta a partir de:
Você também pode usar um de nossos criadores de alerta:
Use
Write your own query
para criar um alerta do zero
Use guided mode
Para todos os métodos, exceto o nosso modo guiado, o processo de criação de uma condição do alerta será exatamente o mesmo descrito nas etapas abaixo.
Defina o comportamento do seu sinal
Neste exemplo, imagine que sua equipe gerencia o aplicativo WebPortal de um site de comércio eletrônico. Você deseja estar alerta sobre quaisquer problemas de latência.
Você pode usar uma consulta NRQL para definir os sinais que deseja que uma condição do alerta use como base para seu alerta. Para este exemplo, você usará esta consulta:
SELECT average(duration)
FROM PageView
WHERE appName = 'WebPortal'
Usar esta consulta para sua condição do alerta informa ao New Relic que você deseja saber a média de pageviews do seu aplicativo WebPortal . O monitoramento pageviews pode ajudá-lo a detectar quaisquer problemas de latência em seu aplicativo.
Você pode aprender mais sobre como usar NRQL, a linguagem de consulta da New Relic, consulte nossa documentação NRQL.
Ajustar configurações de sinal avançadas
Depois de definir seu sinal, clique em Run. Um gráfico aparecerá e exibirá o parâmetro que você definiu.
Neste exemplo, o gráfico mostrará a média pageviews para seu aplicativo WebPortal . Clique em Next e comece a configurar sua condição do alerta.
Neste exemplo, você personalizará essas configurações de sinal avançadas para a condição criada para monitor uma atividade incomum para pageviews em seu aplicativo WebPortal.
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:
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.
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).
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.
Se uma condição do alerta for um container, então são limitadas as regras que cada condição do alerta deve seguir. À medida que os dados fluem para o seu sistema, a condição do alerta procura qualquer ocorrência dessas regras. Se a condição do alerta detectar dados do seu sistema que atenderam a todas as condições que você definiu, isso criará um incidente. Um incidente sinaliza que algo está errado em seu sistema e você deve verificar.
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:
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.
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.
Consulte a documentação da condição do alerta para obter mais detalhes sobre os níveis de prioridade.
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.
Saiba mais sobre o limite de anomalia e os comportamentos do modelo em nossa documentação de anomalia.
Ao contrário dos limites de anomalia, um limite estático não analisa o 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 sistema se comportar de maneira diferente dos critérios you set.
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 sinal perdido para pageviews puder indicar um problema de latência, defina um limite com o qual você se sinta confortável e marque a caixa para abrir um novo incidente de sinal perdido.
Adicionar detalhes da condição do alerta
Neste ponto do processo, você tem uma condição totalmente definida e define todas as regras para garantir que um incidente seja aberto quando você desejar. Com base nas configurações acima, se a sua condição do alerta reconhecer esse comportamento no seu sistema que viola o limite que você definiu, ele criará um incidente. Agora, tudo que você precisa fazer é nomear essa condição e anexá-la a uma política.
A política é o sistema de classificação do incidente. Ao criar uma política, você cria a ferramenta que organiza todos os seus incidentes recebidos. Você pode conectar políticas a workflows que informam à New Relic para onde você deseja que todas essas informações recebidas sejam enviadas, com que frequência você deseja que elas sejam enviadas e para onde.
É essencial dar um nome descritivo à sua condição do alerta. Digamos que você nomeie essa condição como pageviews e, em seguida, crie outra condição para um aplicativo completamente diferente e rotule essa condição como pageviews 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, você nomearia essa condição pageviews: WebPortal App.
Se você já possui uma política que deseja conectar a uma condição do alerta, selecione a política existente.
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:
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.
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.
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.
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 o comportamento de violação for "pageviews for inferior a 300 pelo menos uma vez a cada 5 minutos", o incidente será encerrado automaticamente quando pageviews for igual ou superior a 300 por cinco minutos consecutivos.
Quando um incidente é encerrado automaticamente:
O timestamp de fechamento é retroativo ao início do período de recuperação.
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.
Se quiser vincular a um runbook, você pode colocar a URL no campo URL do runbook.
Editar ou melhorar uma condição de alerta existente
Se quiser editar uma condição do alerta já criada, você pode:
A partir daí, você verá a página Alert conditions details . Esta página contém todos os elementos que você definiu quando criou sua condição. Você pode editar aspectos específicos da condição do alerta clicando no lápis no canto superior direito de cada seção.
Histórico de sinais
Em Signal history, você pode ver os resultados mais recentes da consulta NRQL usada para criar sua condição do alerta. Neste exemplo, você veria a média pageviews no aplicativo WebPortal para o período específico definido.
Para todas as condições do alerta construídas com consulta NRQL, o Signal history será apresentado com um gráfico de linhas.
Qualquer condição do alerta construída com um monitor Sintético será um pouco diferente. Isso ocorre porque os monitores Sintético permitem executar ping em seu aplicativo de vários locais, o que pode produzir resultados positivos ou negativos cada vez que o monitor é executado. Esses dados só podem ser apresentados em tabela.
Solucionar problemas
Se você vir um sinal vazio no gráfico histórico, considere um dos seguintes:
Review the condition's settings
: verifique novamente se todos os elementos estão configurados corretamente.
Inspect NRQL queries
: Certifique-se de que o destino seja métrica ou evento válido e retorne dados.
Examine entity configuration
: confirme se a entidade está configurada corretamente para enviar sinais.
Consult New Relic documentation
: Consulte os guias relevantes para obter assistência com questões específicas.