Com o alerta, você pode começar a detectar problemas antes que se tornem críticos. Usando NRQL, nossa linguagem de consulta New Relic, você pode criar e personalizar sua condição do alerta com foco no que mais lhe preocupa. Use para se manter atualizado sobre comportamentos incomuns em seus dados, encaminhar notificações para as pessoas que precisam vê-las e tomar decisões eficazes conhecendo a causa raiz do seu problema.
Melhore sua cobertura de alertas usando nossas recomendações sobre como usar melhor a resposta, manutenção, qualidade e configurações avançadas de alertas. Consulte nosso guia de gerenciamento de qualidade de alerta para saber como medir e melhorar a qualidade de seus alertas.
Você pode seguir estas ações recomendadas para melhorar e aproveitar ao máximo sua configuração de alerta.
Dica
Você já criou seu primeiro alerta? Caso contrário, confira nossa série de tutoriais para todas as etapas necessárias para começar.
Melhorar a resposta aos alertas
O que devo fazer | Beneficiar |
|---|---|
Tenha um nome explicativo para o alerta | A descrição e a tag devem fornecer um alerta autodescritivo para saber qual serviço está errado, qual ambiente está envolvido, qual equipe o possui e se está impactando o usuário final. Ajuda você a responder mais rápido e decidir o que fazer. |
Adicione tag à sua condição do alerta | Seus problemas e incidentes possuem essas tags em seus metadados. Use-os para fazer filtros flexíveis no fluxo de trabalho ou adicione-os à sua carga de notificação. Os problemas têm três fontes de tag:
|
Categorizar a condição do alerta | Em toda a sua organização, defina categorias de alerta, expectativas para lidar com suas notificações e um destino exclusivo. Por exemplo, proativo para o Slack notificar antes que o incidente ocorra; reativo ao PagerDuty para detectar e notificar sobre um incidente em andamento; ou informativo para Jira. |
Defina o método de comunicação e escalonamento | Decida os meios de notificação. Alguns métodos de notificação são: email, Slack, PagerDuty ou Jira. |
Adicione uma equipe responsável | Esta equipe é responsável pelo tratamento da primeira notificação. |
Adicione um URL de runbook a cada condição do alerta | O runbook deve descrever as etapas de correção a serem seguidas e quem envolver ou escalar. |
Usar enriquecimentos | Priorize e faça a triagem de sua notificação de alerta com mais rapidez, fornecendo métricas adicionais específicas para o problema. |
Melhorar a manutenção de alertas
O que devo fazer | Beneficiar |
|---|---|
Organize suas políticas | Recomendamos a criação de uma política para cada destino ou público separado que precisa receber uma notificação. Considere agrupar por entidade, serviço ou tecnologia para corresponder ao foco de suas respectivas equipes. |
Adicione uma equipe proprietária a cada condição do alerta | A equipe proprietária garante que o alerta permanece relevante. Eles aprovam quaisquer alterações na condição. |
Agende uma revisão periódica da condição do alerta | Utilize a página de visão geral do alerta para verificar o incidente criado e decidir a ação a ser tomada. Recomendamos que você tag a condição com a data da última revisão, o que permitirá identificar alertas obsoletos. |
Automatize a criação de seu alerta usando Terraform | Você evitará alterações não documentadas e terá uma rastreabilidade clara. |
Melhore a qualidade do alerta
O que devo fazer | Benefícios |
|---|---|
Ter SLIs e SLOs em um relatório | As violações de SLIs e SLOs nem sempre ocorrem e não exigem um alerta, a menos que você tenha documentado as etapas para evitá-las. O SLI/SLO pode destacar a área onde a equipe deve se concentrar para melhorias em vez de responder a um evento. |
Silenciar alerta durante manutenção | Suprimirá notificações ruidosas. |
Tenha uma abordagem sistêmica na definição de alerta para um serviço | Ajuda você a cobrir toda a sua stack de maneira consistente. Você pode organizar seu alerta por tecnologia, equipes envolvidas, etc. |
Revise as decisões sugeridas | Todos os dias analisamos os seus dados de alerta e fornecemos sugestões de decisões, bem como feedback sobre as decisões existentes. Isso melhorará a redução de ruído. |
Identificar e sintonizar alerta de oscilação | Esses alertas indicam uma configuração de má condição do alerta que cria ruído. Eles ainda podem indicar um problema antigo em seu sistema, mas isso não é um incidente. |
Aumente o limite ou a duração da janela e use a agregação de janela deslizante | Alertar que a auto-resolução antes que sua equipe possa tomar qualquer ação pode sobrecarregar sua caixa de entrada e criar ruído. Use um painel se quiser ver picos de curta duração e suavizar picos temporários. Você entenderá o impacto que isso terá no fechamento do seu incidente. |
Usar decisões | Aproveite sua tag personalizada e metadados nas decisões. O incidente relacionado será correlacionado em um problema único e abrangente. Mantenha as decisões padrão ativadas quando você começar. Dentro de algumas semanas, você poderá avaliar a eficácia dessas decisões. |
Se você usar decisões, aumente o período de carência de notificação | Você terá mais incidentes relacionados aos seus problemas. Você obterá um contexto mais rico e prático desde a primeira notificação. Quanto maior o período de carência, mais tardia será a notificação. |
Revise periodicamente o feed de problemas | Percorra a coluna Notified para garantir que todos os problemas sejam encaminhados para pelo menos um destino. Se nenhum roteamento for necessário, considere remover a condição, pois pode haver ruído. |
Condição do alerta criação e configurações avançadas
Se você é novo no alerta ou deseja sugestões que otimizem sua cobertura de alerta, preste atenção a estas recomendações:
- Receba alerta recomendado por tecnologia
- Deixe a New Relic encontrar suas lacunas de cobertura
- Obtenha recomendações de condições
Entenda o sinal
Cada condição do alerta gera um sinal ou vários sinais se a condição contiver uma cláusula de faceta. Cada valor de faceta possível criará um sinal distinto.
Você pode consultar todos os sinais em NrAiSignal. Isso permite obter detalhes sobre o valor observado, quantos pontos de dados foram considerados e, no caso de condições de anomalia, o valor esperado e o padrão Desvio. Ele também fornece informações sobre o delta de tempo entre o tempo do New Relic e o tempo dos dados brutos (se seus dados forem carimbo de data/hora), o que pode ajudá-lo a encontrar a configuração de atraso mais precisa ao criar suas condições.
Manter a integridade da entidade
Usamos sinais para inferir a cobertura de saúde e alerta de uma entidade. Se os resultados de uma condição do alerta contiverem dados de apenas uma entidade, o New Relic irá vinculá-los à integridade dessa entidade, e esses eventos serão exibidos no contexto na UI do New Relic.
É recomendado, para a maioria das condições, manter a existência de sinal. Nenhum sinal pode fazer com que a New Relic mostre o estado de saúde cinza (desconhecido) para algumas entidades, bem como adicione essas entidades à lista de entidades não cobertas.
Se a cláusula where da sua condição excluir todos os dados, não sobrarão dados. Isto é uma perda de sinal para o New Relic e a condição do alerta NÃO PODE ser avaliada em relação a NENHUM limite. Isso significa que o resultado da consulta NRQL não contém dados, mas não significa que o New Relic não esteja recebendo dados. Se quiser receber uma notificação, você deve adicionar um limite de perda de sinal.
Use os filtros mais genéricos na seção where e os mais específicos na seção select . Use a função de filtro para medir com precisão o que é importante para você. Por exemplo:
Select filter(count(*), where ErrorCode=123) from Transaction where AppName='Application1' and Environment='Production'Atraso de alerta ou duração do temporizador
Tente ajustar o atraso/tempo com o comportamento dos seus dados. Um pequeno atraso pode desencadear alertas falsos devido a dados incompletos e um grande atraso pode aumentar o tempo de notificação. A New Relic não sabe quantos dados esperar nem com que atraso esses dados podem chegar ao endpoint da New Relic. Dependendo do remetente log e da configuração, os dados log podem ser agrupados em lote e sofrer atrasos significativos para logs de baixos volumes.
Defina seu limite de condição
Defina níveis de limite significativos para otimizar o alerta para o seu negócio. Aqui estão algumas sugestões de diretrizes:
Ação | Recomendações |
|---|---|
Definir níveis de limite | Avoid setting thresholds too low. Por exemplo, se você definir um limite de condição de CPU de 75% por 5 minutos em seus servidores de produção e ele ultrapassar esse nível rotineiramente, isso aumentará a probabilidade de alertas inacionáveis ou falsos positivos. |
Experimentando configurações | You don't need to edit files or restart the software, então sinta-se à vontade para fazer alterações rápidas nos níveis de limite e ajustá-los conforme necessário. |
Ajustar configurações | Adjust your conditions over time.
|
Desativar configurações | Você pode disable any condition em uma política, se necessário. Isto é útil, por exemplo, se você quiser continuar usando outras condições na política enquanto experimenta outras métricas ou limites. |
O indicador de status de saúde codificado por cores na interface do New Relic muda conforme o limite de alerta aumenta ou retorna ao normal. Isso permite monitor uma situação através da interface antes de atingir um limite crítico, sem a necessidade de receber notificações específicas sobre isso. Existem dois limites de incidentes: crítico (vermelho) e aviso (amarelo). Defina estes limites com diferentes critérios, tendo em conta as sugestões acima mencionadas.
Garanta que seus jobs em lote diários sejam executados
Você pode configurar uma condição do alerta para receber uma notificação se seus trabalhos em lote falharem na execução.
Supondo que você esteja enviando um evento para o New Relic como parte de seu trabalho em lote, você pode configurar uma condição do alerta para notificá-lo se seus trabalhos em lote falharem na execução.
Configure uma consulta de contagem simples no evento.
SELECT count(*) FROM MyBatchEventDefina Perda de Sinal para abrir um novo incidente após 24 horas e 30 minutos. Você pode ajustar isso, mas é uma boa ideia permitir um trabalho em lote de execução tardia.
Certifique-se de usar o método de agregação de streaming do evento Timer . Como você obterá apenas 1 ponto de dados a cada 24 horas, poderá definir o cronômetro para a configuração mais baixa, 5 segundos.
Use valores não nulos quando não houver sinal
Por padrão, as lacunas nos sinais de dados são preenchidas com valores nulos. Nos casos em que você precisa criar condições com base nessas lacunas de dados, você pode preencher as lacunas com um valor personalizado ou o último valor conhecido. Você pode definir essa configuração por condição na interface ou configurar valores de preenchimento de lacunas via NerdGraph.
Importante
Configurar o preenchimento de lacunas não impede o acionamento da 'Perda de sinal'.
Defina suas preferências de criação de problemas
Decida quando você receberá a notificação de problemas para poder responder aos problemas quando eles acontecerem.
Se você é novo no alerta, saiba mais sobre as opções de preferências de problemas.
A configuração de preferência de problema padrão combina todas as condições de uma política em um problema. Altere sua configuração de preferência de problema padrão para aumentar ou diminuir o número de problemas e notificações de problemas que você recebe.
Cada equipe da sua organização pode ter necessidades diferentes. Faça duas perguntas importantes à sua equipe ao decidir suas preferências de problema:
- Queremos ser notificados sempre que algo der errado?
- Queremos agrupar todas as notificações semelhantes e ser notificados uma vez?
Quando uma política e suas condições têm um escopo mais amplo, como gerenciar o desempenho de diversas entidades, aumente o número de questões que você recebe. Você pode precisar de mais notificações porque dois problemas não podem necessariamente estar relacionados entre si.
Quando uma política e suas condições têm um escopo focado, como gerenciar o desempenho de uma entidade, opte pela preferência de emissão padrão. Você precisa de menos notificações quando 2 problemas estão relacionados entre si ou quando a equipe já foi notificada e está corrigindo um problema existente.
Qual é o próximo?
Para saber mais sobre como usar o alerta:
- Saiba mais sobre conceitos e termos de alertas.
- Saiba mais sobre a API.
- Leia detalhes técnicos sobre limites e regras mínimo/máximo.
- Leia mais sobre quando você pode querer usar configurações de perda de sinal e preenchimento de lacunas.