| Sistema | Use para | Exemplo |
|---|---|---|
| Uptime monitoring | Uma verificação externa de que seus endpoints públicos ainda respondem | Alertar quando um endpoint de health-check para de retornar 2xx a partir de qualquer região |
| Incident notifications | Erros e incidentes de desempenho que o AppSignal já detecta no seu app | Notificar a equipe na primeira vez que um erro aparece após um deploy, ou quando um incident fechado começa a acontecer de novo |
| Anomaly detection triggers | Alertas de limite em métricas internas e métricas personalizadas | Alertar quando a taxa de erros permanece acima de 5%, o tempo de resposta p95 sobe, o throughput cai ou o uso de disco ultrapassa 85% |
| Log triggers | Padrões em logs que devem alertar mesmo quando nunca se tornam um incident ou métrica | Alertar quando um provedor de pagamentos começa a registrar timeouts repetidos |
| Check-in triggers | Cron jobs, heartbeats e outros processos que devem reportar no horário | Alertar quando uma tarefa noturna não termina, ou um worker para de enviar heartbeats |
O que são alertas
Alertas transformam telemetria em ação. Eles ajudam você a responder perguntas como:- O app está fora do ar?
- Os usuários estão vendo mais erros do que o normal?
- O tráfego caiu porque algo upstream falhou antes das requisições chegarem ao app?
- Uma fila em background está acumulando?
- Uma tarefa agendada parou de rodar?
Escolha o sistema de alerta certo
Use incident notifications quando o AppSignal já tem um incident e você quer controlar quem é notificado e com que frequência. Este é um bom padrão para exceções e ações lentas que você já sabe que importam. Use anomaly detection triggers quando quiser alertas baseados em limite sobre métricas. Esta é a opção mais flexível para cobertura no estilo SRE, incluindo taxa de erros, percentis de tempo de resposta, throughput, tempo de fila, métricas de host e métricas personalizadas. Use log triggers quando o sinal existe nos logs, mas ainda não como um incident ou métrica dedicada. Eles funcionam bem para falhas específicas de integração, como um banco ou provedor apresentando timeout enquanto o restante do sistema parece saudável. Use check-in triggers quando sucesso significa “este processo reportou no horário”. Eles são a ferramenta certa para cron jobs, heartbeats, workers e tarefas agendadas.Um conjunto inicial prático
Para a maioria dos apps em produção, um conjunto inicial útil tem esta aparência:- Uma verificação de uptime para seu endpoint público de health-check.
- Um anomaly trigger para a taxa de erros do
web. - Um anomaly trigger para o tempo de resposta
p90oup95no tráfego crítico voltado ao usuário. - Um anomaly trigger para quedas de throughput.
- Um anomaly trigger para tempo de fila, profundidade de fila ou backlog de jobs em background.
- Triggers de métricas de host para CPU, memória e disco.
- Check-ins para cron jobs, tarefas agendadas e workers de longa duração.
Alertas populares para começar
Estes são alertas iniciais comuns para equipes que querem cobertura ampla sem muito ruído:| Alerta | Por que ajuda | Recurso do AppSignal |
|---|---|---|
Taxa de erros no namespace web | O sinal mais rápido de que os usuários estão encontrando falhas | Anomaly detection trigger |
Tempo de resposta p90 ou p95 para ações críticas | Médias escondem uma experiência lenta para parte do seu tráfego | Anomaly detection trigger |
| Queda de throughput | Uma queda acentuada muitas vezes significa que algo upstream falhou antes das requisições chegarem ao seu app | Anomaly detection trigger |
| Crescimento de tempo de fila ou backlog | Aviso antecipado antes que os usuários percebam atrasos | Anomaly detection trigger |
| Uso de CPU, memória e disco | Alerta de infraestrutura para problemas de saturação e capacidade | Anomaly detection trigger |
| Endpoint de health-check falhando | Confirma que o app está inacessível de fora da sua infraestrutura | Uptime monitoring |
| Heartbeat de cron job ou worker ausente | Confirma que o trabalho em background esperado continua rodando | Check-in trigger |
O que os SREs costumam querer cobrir
Se você está criando cobertura de alertas do zero, estas são prioridades comuns:- Erros visíveis ao usuário
- Requisições lentas de usuários, especialmente em
p90oup95 - Quedas de tráfego e mudanças incomuns de throughput
- Crescimento de filas em background e jobs atrasados
- Saturação de host, como CPU, memória e disco
- Tarefas agendadas que falham em iniciar, terminar ou reportar
- Problemas de dependências externas, como APIs de banco lentas, timeouts ou tempestades de retry
Configure alertas com sucesso
Um bom sistema de alertas trata principalmente de escopo e roteamento:- Adicione notifiers primeiro nas páginas Integrations e Notifications. Cada trigger pode usar um notifier diferente, então você pode rotear por severidade.
- Envie alertas urgentes de produção para uma ferramenta on-call como PagerDuty, Opsgenie ou outro webhook notifier.
- Envie avisos e degradações para chat ou e-mail, como o Slack. Dê ao staging seu próprio canal ou silencie-o.
- Defina padrões de notificação por namespace para que
web,backgroundeadminpossam notificar equipes diferentes por padrão. - Comece com alertas ligados ao impacto no usuário, depois adicione verificações operacionais mais restritas conforme perceber o que é útil.
Evite alertas ruidosos
Esta é a parte que separa um alerta útil de um que a equipe aprende a ignorar:- Defina limites a partir do histórico real, não por suposição. Revise algumas semanas da tendência da métrica antes de escolher um limite.
- Use janelas de warm-up para que uma condição precise se manter por vários minutos antes que o alerta abra. Três a cinco minutos é um ponto de partida comum, e a maioria dos falsos alarmes são picos de um único minuto.
- Use pelo menos um warm-up de um minuto em uptime monitors para tolerar pequenas oscilações de rede.
- Adicione um cooldown para que um sinal instável se torne um alerta mais longo, em vez de abrir e fechar repetidamente.
- Prefira taxas em vez de contagens absolutas quando o tráfego muda ao longo do dia. A taxa de erros geralmente é mais útil que a contagem bruta de erros.
- Prefira
p90oup95para alertas sensíveis à latência, em vez de depender de médias. - Restrinja o escopo dos alertas por namespace, ação ou tags para que a notificação diga exatamente o que está afetado.
- Um bom alerta sustentado supera cinco nervosos. Envie apenas alertas urgentes voltados ao cliente para o on-call, e o restante para o chat.
Configurar uptime monitoring
- Crie um endpoint dedicado de health-check se ainda não tiver um.
- Adicione um uptime monitor para esse endpoint.
- Escolha um notifier para notificações de downtime.
- Defina pelo menos um warm-up de um minuto para que pequenas oscilações de rede não abram alertas.
- Ignore o endpoint de health-check no seu app do AppSignal se não quiser que essas requisições sejam contabilizadas no volume mensal de requisições.
Exemplos
Exemplo de incident notification
Use incident notifications quando o AppSignal já criou um incident de erro ou desempenho e você precisa principalmente do comportamento de notificação correto. Por exemplo:- Use First in Deploy para erros de produção que devem alertar apenas uma vez por release.
- Use First After Close para incidents causados por sistemas externos que podem se recuperar sem um deploy.
- Use Every Nth per Hour ou Every Nth per Day para erros conhecidos e ruidosos onde o volume importa mais do que cada ocorrência individual.
Exemplo de log trigger
Use log triggers quando os logs contêm o sinal que você precisa. Por exemplo, um fluxo de pagamento ou cadastro pode fazer retry quando uma API de banco está lenta, então uma única falha pode não merecer uma notificação urgente, mas um padrão sustentado sim.SQL
Exemplo de alerta de métrica personalizada
Se você envia métricas personalizadas, pode alertar sobre elas com anomaly detection. Por exemplo, você pode enviar:- Um counter para pagamentos ou cadastros bem-sucedidos
- Um gauge para profundidade de fila ou contagem de workers ativos
- Uma measurement para o tempo de resposta do provedor
- Faça o gráfico primeiro e revise seu histórico recente.
- Escolha o campo que corresponde à pergunta que você está fazendo:
gauge,counter,count,mean,p90oup95. - Filtre por tags como
provider=bank-aouregion=euquando precisar de um alerta mais restrito. - Adicione o notifier certo para a severidade do problema.
- Adicione warm-up e cooldown antes de depender do alerta em produção.
Próximos passos
- Revise as notification settings para alertas baseados em incidents.
- Crie anomaly detection triggers para métricas e limites.
- Configure uptime monitoring para uma verificação externa de saúde.
- Crie process monitors and check-ins para cron jobs e heartbeats.
- Use log triggers para alertas baseados em logs.