• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

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.

Criar um problema

Implementação parte 4: Alertas e outras soluções proativas

Esta é a quarta e última parte do nosso guia de implementação.

Nas etapas anteriores de implementação, você instrumentou sua stack e conheceu a plataforma New Relic. Agora é um bom momento para pensar em soluções proativas que irão notificá-lo sobre problemas antecipadamente e ajudá-lo a evitar os piores cenários. Nesta etapa, você conhecerá algumas soluções importantes nesta área, entre elas:

  • Alerta
  • Monitor Sintético
  • Errors Inbox

Pense na sua estratégia de alerta

A interface do New Relic oferece uma visualização do estado da condição do alerta em uma conta.

Antes de configurar o alerta, recomendamos passar algum tempo pensando sobre seus objetivos e estratégia de alerta. Quanto maior for a sua organização, mais importante ela será.

Quando você não tem uma estratégia de alertas e, em vez disso, configura alertas de forma rápida e aleatória para resolver problemas pontuais, isso pode resultar no envio de muitas notificações de alerta. Quando isso acontecer, sua equipe sofrerá com excesso de alertas e passará a ignorar alertas. Passar algum tempo pensando sobre sua estratégia de alertas garantirá que você configure o alerta de maneira inteligente, que pode ser dimensionada à medida que sua organização cresce ou à medida que você adiciona mais dados ao New Relic.

Para encaminhar mensagens de notificação de alerta para você, usamos workflows (as regras de como o incidente cria a notificação e quais dados são enviados) e notification destinations (para onde as notificações são enviadas). Recomendamos que você planeje como eles serão configurados para serem consistentes e fáceis de manter em toda a sua organização. Se você estiver integrando outro serviço, como Slack ou PagerDuty, considere como você controlará e manterá essa integração no longo prazo.

Evitar o excesso de alertas deve ser um objetivo central da sua estratégia de alertas. Uma estratégia que você pode aplicar é categorizar seu alerta por gravidade do impacto nos negócios. Aqueles que são mais severos ou críticos devem fazer o barulho mais alto e ser entregues às partes interessadas que estão em posição de responder, enquanto aqueles que têm menos impacto nos negócios devem ser entregues de forma mais silenciosa, com um “raio de explosão” menor.

Por exemplo, você pode considerar definir alguns protocolos de gravidade de alerta que podem ser aplicados em toda a organização e usar o fluxo de trabalho para garantir que os alertas sejam roteados corretamente. As equipes podem aplicar rotas ligeiramente diferentes para cada gravidade, mas a introdução de uma linguagem comum e compreensão do impacto em toda a organização pode render dividendos à medida que seus esforços de alerta aumentam.

Gravidade

Impacto

Público

Integração

Set 1/P1

Crítico

SRE de plantão, C-Level Manager / incidente Commander /, Product Owner Relevante e equipes DevOps

PagerDuty, folga, e-mail

Setembro 2/P2

Alto

Equipes relevantes de Product Owner e DevOps

PagerDuty, folga

3 de setembro/P3

Médio

Equipes de DevOps

Slack

Caixa de areia / Set 4 / P4

Baixo/Nenhum

Equipes de DevOps

Folga na caixa de areia

Um exemplo de como uma organização pode definir alguns protocolos de segurança de alerta.

Para garantir a qualidade dos alertas a longo prazo, poderá considerar planear revisões regulares da sua condição do alerta para garantir que qualquer excesso de alertas é resolvido e que os alertas estão a ser categorizados corretamente. Isto implicará analisar com que frequência os alertas disparam e quais são os tempos de resposta e resolução.

Para saber como começar a usar alertas:

Aqui estão alguns documentos sobre como automatizar seu alerta:

Monitoramento sintético

Nosso monitoramento sintético oferece um conjunto de ferramentas automatizadas e programáveis para monitor seus sites, transações comerciais críticas e endpoints de API. Essas ferramentas permitem executar um monitor simples para verificar o ritmo de operação e a funcionalidade básica, ou criar scripts complexos que imitam as ações e o fluxo de trabalho do usuário real.

Para usar bem o Sintético, sua equipe deve identificar as jornadas do cliente críticas para os negócios e API dependente, e configurar o monitor do Sintético para rastreá-las. Os relatórios do monitor Sintético podem fazer parte da sua carga de trabalho ou de outro painel.

Você pode verificar o status e as métricas do seu monitor com o índice do monitor.

Para começar a usar o Sintético, consulte Introdução ao Sintético e Criar um monitor.

Errors Inbox

Nosso recurso Errors Inbox ajuda você a detectar, priorizar e tomar medidas proativas em relação aos erros antes que eles afetem seu usuário final. Você receberá alertas sempre que surgir um erro crítico que possa afetar os clientes por meio do seu canal de comunicação preferido, como o Slack.

A interface Errors Inbox permite revisar facilmente os erros da sua carga de trabalho.

Para usar Errors Inbox, você precisará configurar alguma carga de trabalho. Recursos para começar:

Qual é o próximo?

Este guia ajudou você a estabelecer uma base sólida de observabilidade, mas esse é apenas o primeiro passo para avançar em direção à excelência em observabilidade. Em seguida, você pode querer se concentrar em aprender os pontos mais delicados do New Relic e otimizar sua configuração. Algumas ideias para os próximos passos:

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.