Antes de criar um trigger
Três passos de configuração tornam mais útil cada alerta que vem depois, e todos os três são mais fáceis de fazer primeiro do que de adaptar depois. Adicione seus notifiers. Triggers referenciam notifiers, então criá-los primeiro significa que você pode direcionar cada alerta enquanto o constrói, em vez de revisar tudo mais tarde. Configure pelo menos dois destinos: um para o urgente, como uma ferramenta de plantão, e um para o não urgente, como um canal de chat da equipe. Notifiers são configurados uma vez para a organização e compartilhados entre apps. Envie deploy markers. A maioria dos incidentes em produção começa com um release. Um marker transforma “quando isso começou?” em uma pergunta que você responde em segundos, e é o que faz a configuração de notificação First in Deploy funcionar. Divida seu app em namespaces. Namespaces são a principal alavanca para alertar em diferentes severidades sem configurar cada alerta individualmente. Se o tráfegoweb, background e admin cai todo em um namespace, cada limite que você define precisa servir aos três ao mesmo tempo, o que normalmente significa que não serve a nenhum.
Adicione alertas em camadas
Adicionar todos os alertas de uma vez produz notificações demais no primeiro dia e ensina a equipe a ignorá-las. Adicione uma camada, conviva com ela por uma semana e então adicione a próxima.- Acessibilidade. Um uptime monitor em um endpoint de health-check. Este é o único alerta que ainda funciona quando sua aplicação não consegue reportar nada.
- Sintomas visíveis ao usuário. Taxa de erros e tempo de resposta no seu namespace voltado ao usuário. Esses alertas correspondem a erros ou tempos de resposta lentos vivenciados pelos usuários.
- Trabalho agendado e em background. Check-ins para cron jobs e heartbeats de workers, e um alerta de ausência para qualquer fila que nunca deveria estar sem atividade.
- Saturação. Disco, memória e swap do host. Estas são causas, não sintomas, então direcione-as para o chat em vez do plantão.
- Métricas de negócio. Métricas personalizadas para a atividade específica da aplicação que só você pode medir, como pagamentos concluídos ou cadastros por minuto.
Mantenha o ruído de staging e de testes fora da produção
Os alertas de produção só continuam confiáveis se o ruído de ambientes que não são produção nunca chegar até eles.- Dê a cada ambiente seu próprio app no AppSignal, para que limites e notifiers sejam definidos por ambiente em vez de compartilhados.
- Dê ao staging seu próprio canal de chat, ou deixe os triggers de staging sem nenhum notifier. Um trigger sem notifier ainda registra alertas que você pode revisar depois, sem notificar ninguém.
- Use limites diferentes. O tráfego de staging é menor e muda mais do que o de produção, então um limite ajustado com dados de produção pode nunca abrir um alerta, ou pode abrir alertas com frequência excessiva.
- Mantenha canais de teste pessoais fora dos apps de produção. Um notifier pode ser compartilhado por vários apps, e alertas de trigger são direcionados pelos notifiers selecionados em cada trigger.
Verifique sua cobertura
Notificações em excesso são a falha visível. A falha oculta é uma queda sobre a qual ninguém foi alertado. Percorra os modos de falha em vez dos recursos, e verifique se cada um tem um alerta:
A última linha é a que mais costuma faltar. Todo outro alerta desta lista precisa que dados cheguem antes de poder abrir.
Duas perguntas são úteis para revisar o conjunto inteiro. Primeiro, para cada linha que você cobriu, o alerta chega a alguém que pode agir no horário do dia em que ele tem mais chance de abrir? Segundo, dos seus últimos incidentes em produção, quantos foram relatados primeiro por uma pessoa em vez de por um alerta? Esse segundo número é uma medida útil de cobertura.
Decida com que rapidez você precisa saber
A detecção não é instantânea, e vale a pena decidir deliberadamente quanto atraso cada alerta pode carregar. Três fatores somam-se para formar o tempo entre o início de um problema e a chegada de uma notificação:- Agregação. Métricas são avaliadas uma vez por minuto, então sempre há até um minuto antes de o valor em questão ser considerado.
- Processamento. O AppSignal espera um minuto pelos dados de todos os seus servidores antes de avaliá-los.
- Warm-up. O número de minutos que o AppSignal espera antes de abrir o alerta.
- Checkout ou pagamentos quebrados, então clientes não conseguem comprar, reservar ou transferir dinheiro. O mais rápido possível, com pouco ou nenhum warm-up.
- Site ou app inacessível. 1–2 minutos.
- Taxa de erros elevada, então clientes estão encontrando erros. 1–2 minutos.
- Degradação do tempo de resposta, então requisições demoram mais que o normal. 1–3 minutos.
- Fila acumulando, então o trabalho ainda é processado mas chega atrasado. 1–3 minutos.
- Uso de disco se aproximando da capacidade total. 10–60 minutos.
Verifique um alerta antes de confiar nele
Um trigger que não corresponde a nada pode parecer um sistema saudável. Antes de contar um alerta como cobertura, confirme tudo o seguinte:- A prévia do gráfico mostra dados. Uma prévia vazia no formulário do trigger significa que o trigger atualmente não corresponde a nada.
- O hostname é resolvido. Se o campo hostname avisar que o host não foi encontrado, o trigger provavelmente está observando uma máquina que foi renomeada ou substituída.
- A combinação de tags é reconhecida. O AppSignal avisa quando uma combinação de tags não foi vista na última hora. Use uma das combinações de chaves de tag listadas no formulário do trigger, e defina cada valor como um valor exato ou um curinga.
- Um notifier está anexado. Um trigger sem notifier registra alertas sem enviar notificações.
- O notifier funciona. Envie uma notificação de teste e confirme que ela chega no canal esperado, e não em um parecido.
- Alertas de ausência tratam dados faltantes. Para qualquer trigger cujo limite seja zero ou um valor mínimo, confirme que treat missing datapoints as 0 está ativado, ou ele não abrirá exatamente no caso para o qual você o criou.
Mantenha os alertas após a configuração
Alertar não termina quando a configuração está pronta.- Escreva o runbook no trigger. Um nome que diga o que está errado, uma descrição que diga o que fazer, e um dashboard vinculado. Coberto em torne a notificação autoexplicativa.
- Evite reajustar durante um incidente. Alterar configurações do trigger pode afetar o alerta que você está acompanhando, incluindo fechar ou substituir o estado ativo do alerta.
- Revise trimestralmente. Os alertas se deterioram conforme hosts são substituídos, serviços renomeados e o tráfego cresce. A checklist de revisão cobre o que observar.
- Adicione um alerta após cada incidente, e remova um também. A revisão pós-incidente é o melhor momento para notar tanto o que faltava quanto o que abriu sem exigir ação.
Próximos passos
- Escolha configurações nos guias para criar alertas.
- Reduza o volume com ajuste seus alertas.
- Defina padrões de notificação por namespace.
- Configure check-ins para trabalho agendado.