Uma condição de alerta é o elemento central que define quando um evento de alerta é criado. Ele atua como o ponto de partida essencial para criar qualquer alerta significativo. As condições de alerta contêm os parâmetros ou limites atingidos antes de você ser notificado. Eles podem mitigar alertas excessivos ou informar sua equipe quando surgir um comportamento novo ou incomum.
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 evento de alerta quando o limite é atingido por uma janela de tempo especificada.
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 New Relic que você deseja saber a latência média, ou duração, para carregar páginas em seu aplicativo WebPortal. Alertas proativos sobre latência, um dos principais sinais clássicos, fornecem avisos antecipados de degradação potencial.
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.
Dica
Para configurar alertas entre contas, selecione uma conta de dados na lista suspensa. E você só pode consultar dados de uma conta para alertas entre contas por vez.
/ <img title="definir uma consulta" alt="Uma captura de tela mostrando a um usuário como definir o comportamento do sinal para uma condição de alerta." src="/images/alerts_screenshot-crop_set-a-query.webp" /> /
Neste exemplo, o gráfico mostrará a duração média de uma transação. Clique em Next e comece a configurar sua condição do alerta.
Neste exemplo, você personalizará essas configurações avançadas de sinal para a condição criada para monitor a latência no aplicativo WebPortal.
/ <img title="ajustar configurações de alerta" alt="Uma captura de tela mostrando configurações avançadas de sinal." src="/images/alerts_screenshot-crop_fine-tune-alert-signals.webp" /> /
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.
Importante
clientes nos planos de preços de computadores Advanced e Core podem incorrer em custos adicionais de CCU ao utilizar agregação de janela deslizante. Embora esse método melhore a análise de dados ao suavizar flutuações, seu uso pode levar ao aumento de custos em relação a outros métodos. Para mais detalhes, consulte a seção de preços para janelas de correr. Para determinar se você está nos planos de preços de computador Advanced ou Core, consulte seu pedido.
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 em condições de alerta protege contra possíveis problemas decorrentes da coleta de dados inconsistente. Atua como um buffer, permitindo tempo extra para que os dados cheguem e sejam processados antes de acionar um alerta. Isso ajuda a evitar falsos positivos e garante uma criação de eventos de alerta 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.
Alertas entre contas no New Relic permitem que você configure alertas que monitoram dados de uma conta diferente daquela onde o alerta está configurado. Este recurso permite maior flexibilidade no monitoramento e gerenciamento de dependência entre múltiplas contas dentro do New Relic.
Se uma condição de alerta é um contêiner, então os limites são as regras que cada condição de alerta deve seguir. À medida que os dados fluem para o seu sistema, a condição de alerta busca quaisquer eventos de alerta dessas regras. Se a condição de alerta detectar dados do seu sistema que atendam a todas as condições que você definiu, ela criará um evento de alerta. Um evento de alerta sinaliza que algo está errado em seu sistema e você deve verificar.
/ <img title="definir um limite" alt="Uma captura de tela mostrando como definir o limite para uma condição de alerta." src="/images/alerts_screenshot-crop_set-a-threshold-for-an-alert-condition.webp" /> /
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.
Defina critérios de violação:
Comece com as configurações padrão: abra um evento de alerta quando uma consulta retornar um valor que se desvie do valor previsto por pelo menos cinco minutos em três desvios 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 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.
Você precisa definir o nível de prioridade para anomalia e limite estático. Consulte a seção acima para obter mais detalhes.
A detecção de outliers identifica entidades que estão se comportando de maneira significativamente diferente de seus pares em um determinado momento. Ao contrário da detecção de anomalias, que busca padrões incomuns ao longo do tempo, a detecção de outlier concentra-se em outliers dentro de um grupo usando o cluster DBSCAN.
Este tipo de limite é ideal para:
Identificar servidores com consumo de recursos incomum em comparação com o cluster.
Detectando brokers Kafka que não estão processando mensagens corretamente.
Identificando cenários de "vizinhos barulhentos" em ambientes com múltiplos inquilinos.
Parâmetro de configuração chave:
Epsilon: Distância máxima entre pontos no mesmo cluster
Pontuação mínima: Pontuação mínima necessária para formar um cluster (recomendado > 3)
Grupos de avaliação: Análise de segmentos por aspectos como ambiente ou região.
No New Relic, as entidades estão associadas a status de integridade codificados por cores. Você pode visualizar o estado atual dessas entidades a partir de seus respectivos índices e mapas. Quando uma condição de alerta é associada a uma entidade, o status de integridade da entidade é determinado pela condição de alerta. Se o alerta acionar um evento de alerta, o status de integridade da entidade muda com base no nível de gravidade do evento de alerta.
Se desejar que a condição do alerta não afete o status de saúde da entidade associada, ative o botão de alternância Do not report system health status . Isso é útil quando você deseja monitorar uma entidade sem afetar seu estado geral de saúde.
Importante
Ao criar um alerta entre contas, a opção Do not report system health status é desabilitada por padrão. Para evitar que a condição do alerta entre contas determine o estado de saúde da entidade associada, ative-a.
Predictive Alerts da New Relic analisa dados históricos para prever tendências futuras. Se a previsão mostrar que o limite estático pode ser violado em breve, você receberá uma notificação de alerta, dando a você a oportunidade de agir antes que as interrupções ocorram.
Para ativar alertas preditivos para sua condição do alerta, execute as seguintes etapas:
Na seção Set condition thresholds , selecione o tipo de condição limite como Static.
Para alertas preditivos, ative a opção Predict future behavior .
Defina o tempo de previsão. Isso indica até que ponto no futuro ele deve procurar por violações previstas. O tempo máximo de visualização é 360 vezes a duração da janela.
Defina o comportamento do evento de alerta previsto quando o sinal real cruzar o limite.
Feche o alerta previsto e abra um alerta real.
Mantenha o alerta previsto aberto para reduzir o ruído.
O limite de perda de sinal determina quanto tempo esperar antes de considerar um sinal ausente como perdido. Se o sinal não retornar dentro desse período, você pode optar por abrir um novo evento de alerta ou fechar quaisquer eventos relacionados. Você também pode optar por ignorar a abertura de um evento de alerta quando se espera que um sinal termine. 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 throughput, os dados de telemetria correspondentes enviados para o New Relic também cessarão. O monitoramento dessa perda de sinal pode servir como um sistema de alerta antecipado para tais interrupções.
Adicionar detalhes da condição do alerta
Neste ponto do processo, você tem uma condição totalmente definida e definiu todas as regras para garantir que um evento de alerta seja aberto quando você desejar. Com base nas configurações acima, se sua condição de alerta reconhecer esse comportamento no seu sistema que viola os limites que você definiu, ela criará um evento de alerta. Agora, tudo o que você precisa fazer é nomear esta condição e vinculá-la a uma política.
A política é o sistema de classificação do evento de alerta. Quando você cria uma política, você cria a ferramenta que organiza todos os seus eventos de alerta recebidos. Você pode conectar políticas a workflows que informam à New Relic para onde você deseja enviar todas essas informações recebidas, com que frequência deseja enviá-las e para onde.
/ <img title="nomeie uma condição de alerta " alt="Uma captura de tela demonstrando como você pode criar uma nova condição de alerta." src="/images/alerts_screenshot-crop_name-your-alert-condition.webp" /> /
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.
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 eventos de alerta em um único problema, mesmo que acionados por condições diferentes. Não é o ideal para questões de múltiplas visualizações 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 evento de alerta:
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 evento de alerta fecha automaticamente quando o sinal alvo retorna a um estado de não violação pelo período indicado nos limites da condição. Este tempo de espera é chamado de período de recuperação.
Por exemplo, se você estiver medindo a latência e o comportamento de violação for que duration para carregar páginas na sua aplicação WebPortal aumentou para mais de 3 segundos, o evento de alerta será fechado automaticamente quando duration for igual ou inferior a 3 segundos por 5 minutos consecutivos.
Quando um evento de alerta fecha 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 evento de alerta anterior terminou.
Todas as condições têm uma configuração de limite de tempo de evento de alerta que força automaticamente o encerramento de um evento de alerta 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 evento de alerta aberto quando o sinal não retorna dados é configurando um limite de 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á problemas de latência com sua aplicação WebPortal, você quer garantir que seus desenvolvedores tenham todas as informações necessárias ao serem notificados sobre esse evento de alerta. Você usará fluxos de trabalho para notificar um canal da equipe no Slack quando um evento de alerta for criado.
Saiba mais sobre descrições de eventos de alerta personalizados em nossa documentação.
/ <img title="página de detalhes do alerta" alt="Uma captura de tela mostrando a etapa final da criação de uma condição de alerta - a página de detalhes do alerta" src="/images/alerts_screenshot-crop_adding-alert-details-to-an-alert-condition.webp" /> /
O uso do modelo de título é opcional, mas nós o recomendamos. Uma condição de alerta define um conjunto de limites que você deseja monitorar. Se algum desses limites for excedido, um evento de alerta é criado. Modelos de título significativos ajudam a identificar problemas e resolver interrupções mais rapidamente.
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.
Para saber mais sobre os alertas entre contas, consulte nossos alertas entre contas.
Editar 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 latência média 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.
Tipos de condições
O tipo de condição principal e recomendado é uma condição do alerta NRQL , mas existem outros tipos de condições. Incluímos uma lista completa de nossos tipos de condição abaixo.
O alerta de anomalia permite criar condições que se ajustam dinamicamente às mudanças de dados e tendências, como padrões semanais ou sazonais. Este recurso está disponível para aplicativos e , bem como consulta NRQL.
Você pode definir limites que abrem um evento de alerta quando são violados por qualquer uma das métricas de instância do seu aplicativo Java.
Ao definir o escopo limit para uma instância específica, você pode identificar mais rapidamente a origem dos possíveis problemas. Isso é útil, por exemplo, para detectar anomalias que estão ocorrendo apenas em um subconjunto da instância do seu aplicativo. Esses tipos de anomalia são fáceis de perder em aplicativos que agregam métricas em um grande número de instâncias.
Para aplicativos Java monitorados pelo APM, você pode definir limites que abrem um evento de alerta quando o tamanho do heap ou o número de threads para uma única JVM estiver fora da faixa de operação esperada.
Avaliamos as violações de limite de alerta individualmente para cada uma das instâncias selecionadas do aplicativo. Ao criar sua condição, selecione JVM health metric como o tipo de condição para a política de alerta do seu aplicativo Java, em seguida, selecione qualquer um dos limites disponíveis:
Tópicos em impasse
Uso de memória heap
Tempo de utilização da CPU
Tempo de CPU da coleta de lixo
eventos de alerta fecharão automaticamente quando o inverso do limite for atingido, mas usando a interface de usuário você também pode alterar o momento em que um evento de alerta fecha forçadamente para uma métrica de integridade da JVM. O padrão é 24 horas.
Incluímos a opção de definir um percentil como limite para sua condição quando o tempo de resposta do seu aplicativo web estiver acima, abaixo ou igual a esse valor. Isso é útil, por exemplo, quando a equipe de operações deseja alertar sobre um percentil para o tempo de resposta da weboverall de transação da web de um servidor de aplicativos, em vez do tempo de resposta da web average .
Selecione Web transactions percentiles como o tipo de condição para a condição do seu aplicativo e selecione um único aplicativo. (Para alertar sobre mais de um aplicativo, crie uma condição Web transactions percentiles individual para cada um.)
Para definir os limites que abrem o evento de alerta, digite o valor do tempo de resposta Percentile nth, em seguida, selecione sua frequência (acima, abaixo ou igual a este valor).
Armazenamos o tempo de transação em milissegundos, embora a interface do usuário mostre os valores Crítico e Aviso em segundos. Se você deseja definir milissegundos, inclua o ponto decimal em seu valor.
Ao aplicar rótulos no aplicativo, você pode vincular automaticamente essas entidades à sua condição. Isso facilita o gerenciamento de todos os aplicativos em um ambiente dinâmico. Recomendamos usar o arquivo de configuração do agente para melhor manter os rótulos da entidade.
Um único rótulo identifica all entidade associada a esse rótulo (máximo de 10.000 entidades). Múltiplos rótulos identificam apenas a entidade que compartilha todos os rótulos selecionados.
Por exemplo, para obter uma notificação quando um agente de infraestrutura parar de receber dados, use o tipo de condição de host que não relata . Isso permite alertar dinamicamente sobre grupos de hosts filtrados e configurar a janela de tempo de 5 a 60 minutos.
Na lista de condições do alerta, clique no ícone de três pontos do alerta que deseja copiar e selecione Duplicate condition.
Em Copy alert condition, pesquise ou role a lista para selecionar a política onde você deseja adicionar esta condição.
Opcional: altere o nome da condição, se necessário.
Opcional: clique no botão de alternância para Enable on save
Selecione Copy condition.
Por padrão, a política de alerta selecionada adicionará a condição copiada no estado Disabled. Siga os procedimentos padrão para adicionar ou copiar mais condições para a política de alerta e, em seguida, Enable a condição conforme necessário. Além disso, a nova condição não copiará nenhuma tag adicionada à condição original.
Habilitar/desabilitar uma condição
Para desativar ou reativar uma condição:
Vá para one.newrelic.com > All capabilities > Alerts > Alert Conditions. Em seguida, na lista de Alert conditions, use o botão de alternância para ativar ou desativar a condição.
Clique no botão On/Off para alterná-lo.
Se você copiar uma condição, ela será salva automaticamente na nova política como desabilitada (Off), mesmo que a condição tenha sido habilitada (On) na política original.
Excluir uma condição
Para desativar uma condição, mas mantê-la com a política, desative -a. Para excluir uma ou mais condições:
