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

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

Nível 1 - Regra do scorecard de cobertura de alerta de prestação de serviço

A cobertura de alerta de entrega de serviços garante que seus aplicativos e serviços voltados para o cliente tenham alertas de monitoramento implementados para detectar problemas que possam impactar a experiência do usuário e as operações de negócios.

Sobre esta regra do scorecard

Esta regra de cobertura de alerta de prestação de serviços faz parte do Nível 1 (Reativo) no modelo de maturidade de tempo de operação do negócio. Ele verifica se seu aplicativo e serviços têm alertas básicos configurados para notificá-lo quando ocorrem problemas voltados aos clientes.

Por que isso é importante: Problemas na prestação de serviços afetam diretamente a experiência do cliente e a receita do negócio. Sem alertas de aplicativos adequados, você só poderá descobrir problemas quando os clientes os relatarem, o que levará a interrupções mais longas e relacionamentos prejudicados com os clientes.

Como funciona esta regra

Esta regra examina sua entidade de prestação de serviços e verifica se ela tem a condição do alerta definida. Especificamente, ele procura alertas sobre:

  • Entidades APM-APPLICATION: aplicativo backend e serviços monitorados pelo agente APM
  • Entidades BROWSER-APPLICATION: Aplicativo web frontend monitorado por monitoramento de Browser
  • Entidades MOBILE-APPLICATION: Aplicativos móveis monitorados por monitoramento de Mobile
  • Entidades SYNTH-MONITOR: Monitores sintéticos que simulam a interação do usuário

A regra falhará se qualquer entidade de prestação de serviço monitorada não tiver pelo menos uma condição de alerta.

Compreendendo sua pontuação

  • Aprovado (Verde): Todas as entidades de prestação de serviços têm pelo menos uma condição de alerta definida
  • Falha (Vermelho): Uma ou mais entidades de prestação de serviços não possuem cobertura de alerta
  • destino: 100% de cobertura de alerta em todos os aplicativos e serviços voltados para o cliente

O que isto significa:

  • Pontuação de aprovação: sua base de monitoramento de aplicativo está pronta para detectar problemas que impactam os clientes
  • Pontuação de falha: alguns aplicativos ou serviços podem falhar sem alertar sua equipe, impactando potencialmente os clientes

Como melhorar a cobertura de alertas de prestação de serviços

Se sua pontuação mostrar alertas de prestação de serviços ausentes, siga estas etapas para estabelecer uma cobertura abrangente:

1. Identificar serviços não cobertos

  1. Revise a entidade falida: identifique qual aplicativo ou serviço específico não possui cobertura de alerta
  2. Priorize o impacto do cliente: concentre-se primeiro em aplicativos voltados para o cliente e em serviços críticos para a receita
  3. Avalie a criticidade do serviço: determine quais serviços exigem alerta imediato ou atrasado

2. Configure alertas de prestação de serviços essenciais

Configure alertas para estas métricas críticas com base no seu tipo de entidade:

Alertas de aplicativo APM :

  • taxa de erros: alerta quando a porcentagem de erro ultrapassa 5% por 5 minutos
  • tempo de resposta: alerta quando o tempo médio de resposta excede o limite aceitável (por exemplo, >2 segundos)
  • taxas de transferência: alerta quando o volume de solicitações cai significativamente, indicando possíveis interrupções
  • Pontuação Apdex: alerta quando as pontuações de satisfação do usuário caem abaixo dos níveis aceitáveis (por exemplo, menos de 0,8)

Alertas de aplicativos Browser :

  • Erros de JavaScript: alerta quando a taxa de erros de frontend aumenta
  • Tempo de carregamento da página: alerta quando o tempo de carregamento da página excede o limite da experiência do usuário
  • Core Web Vitals: alerta quando métricas como Largest Contentful Paint ou Cumulative Layout Shift degradam
  • Sessões de usuário: alerta quando sessões de usuários ativos caem inesperadamente

Alertas de aplicativos móveis:

  • Taxa de travamento: alerta quando a taxa de travamento do aplicativo excede 1-2%
  • Erros de rede: alerta quando ocorrem picos de falhas em solicitações de rede
  • Tempo de inicialização do aplicativo: alerta quando os tempos de inicialização do aplicativo se tornam inaceitáveis
  • Interação do usuário: alerta quando as principais ações do usuário (login, compra) falham com frequência

Sintético monitora alertas:

  • Monitore falhas: alerta imediatamente quando as verificações sintéticas falham
  • Degradação de desempenho: alerta quando o tempo de transação Sintético aumentar significativamente
  • Disponibilidade: alerta quando o tempo de operação fica abaixo dos requisitos SLA (por exemplo, menos de 99,9%)
  • Falhas em vários locais: alerta quando o mesmo problema ocorre em vários locais

3. Configure alertas de forma eficaz

Defina um limite apropriado:

  • Limite de base em dados históricos de desempenho e requisitos de negócios
  • Use limites diferentes para ambientes diferentes (a produção deve ser mais sensível)
  • Considere o impacto da experiência do usuário ao definir o tempo de resposta e a taxa de limite de erros

Escolha janelas de avaliação adequadas:

  • Use janelas mais curtas (2 a 5 minutos) para problemas críticos enfrentados pelo usuário
  • Use janelas mais longas (10-15 minutos) para tendências de desempenho que precisam de tempo para serem estabelecidas
  • Evite janelas tão curtas que desencadeiem flutuações temporárias

4. Estabelecer procedimentos de resposta a incidentes

  1. Definir canal de notificação: Configurar integração com Slack, PagerDuty ou email
  2. Atribuir equipes responsáveis: garantir que os alertas cheguem às equipes que podem diagnosticar e corrigir problemas
  3. Crie caminhos de escalonamento: defina o que acontece se os alertas não forem reconhecidos dentro dos prazos do SLA
  4. Procedimentos de resposta de teste: verifique se as equipes podem realmente responder e resolver problemas de alertas

Medindo a melhoria

Acompanhe essas métricas para verificar as melhorias na cobertura de alertas de entrega de serviço:

  • Porcentagem de cobertura: Monitoramento de IA para cobertura de alerta de 100% em aplicativos e serviços de produção
  • Tempo médio de detecção (MTTD): mede a rapidez com que os alertas identificam problemas que impactam os clientes
  • Precisão do alerta: monitore a porcentagem de alertas que representam problemas genuínos que exigem ação
  • Redução do impacto para os clientes: monitore se uma detecção mais rápida leva a interrupções mais curtas para os clientes

Cenários e soluções comuns

legado ou aplicativo não utilizado:

  • Problema: Aplicativos antigos ainda aparecem no monitoramento mas não atendem mais os clientes
  • Solução: Remova os aplicativos não utilizados do monitoramento ou tag os como obsoletos para excluí-los dos requisitos de cobertura

Ambientes de desenvolvimento e testes:

  • Problema: métrica de cobertura de alerta de desordem de aplicativo de não produção
  • Solução: Use convenções de tags ou nomenclatura para separar ambientes e concentrar as regras de cobertura em serviços de produção

microsserviços arquitetura:

  • Problema: Muitos serviços pequenos tornam a cobertura de 100% um desafio para alcançar e manter
  • Solução: Priorizar serviços voltados para o cliente e dependências críticas, usar mapas de serviços para identificar componentes-chave

Dependência de terceiros:

  • Problema: Serviços externos não estão sob seu controle, mas impactam seu aplicativo
  • Solução: Criar monitores Sintético para testar integração e APIs críticas de terceiros

Considerações avançadas

Personalizando regras de cobertura

Pode ser necessário ajustar a regra do scorecard se:

  • Diferentes tipos de serviços: Sua arquitetura inclui outros tipos de entidades (função do Lambda, banco de dados, fila de mensagens)
  • Níveis de criticidade empresarial: alguns serviços são mais críticos do que outros e exigem diferentes estratégias de alerta
  • Padrões de implantação: implantação canária ou implantação azul-verde podem afetar temporariamente a cobertura

alerta coordenação e dependência

Para serviços complexos de arquitetura:

  • Dependência de serviço: configurar alertas para contabilizar falhas de serviço upstream
  • Correlação de alerta: alertas relacionados ao grupo para evitar tempestades de notificações durante incidentes
  • Alerta inteligente: use recursos de aprendizado de máquina para reduzir falsos positivos e melhorar a qualidade do sinal

Considerações importantes

  • Foco no impacto do cliente: Priorizar alertas para problemas que afetam diretamente a experiência do cliente
  • Equilibre a cobertura com a qualidade: garanta que a cobertura abrangente não crie excesso de alertas
  • Manutenção regular: revise e atualize a condição do alerta conforme seu aplicativo evolui
  • Coordenação entre equipes: garantir que as equipes de desenvolvimento e operações colaborem na estratégia de alerta

Próximos passos

  1. Ação imediata: configure alertas básicos para quaisquer serviços que atualmente não tenham cobertura
  2. Monitoramento contínuo: revise esta regra do scorecard semanalmente para manter a cobertura conforme os serviços mudam
  3. Melhoria da qualidade: Foco na eficácia do alerta e redução de falsos positivos
  4. Avance para o Nível 2: Uma vez estabelecido o alerta de prestação de serviços, concentre-se em práticas de monitoramento proativo

Para obter orientação detalhada sobre a configuração do aplicativo de monitoramento, consulte nossa documentação para APM, monitoramento de Browser, monitoramento de Mobile e monitoramento sintético.

Copyright © 2025 New Relic Inc.

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