Monitore primeiro seus endpoints voltados ao cliente
Todo produto SaaS tem endpoints com os quais os usuários interagem diretamente. Esses são sua prioridade máxima de monitoramento.
Comece com o painel do seu aplicativo. Se os usuários fazem login em app.suaempresa.com, monitore essa URL. Depois adicione seu endpoint de autenticação. Se os usuários não conseguem fazer login, o resto do seu monitoramento não importa.
Adicione seus endpoints de API principais. Se seu produto tem uma API REST que os clientes integram, monitore os endpoints que eles mais chamam. Um endpoint /v1/health é aceitável, mas pode retornar 200 enquanto seus endpoints de dados reais estão lançando erros 500. Monitore os endpoints que seus usuários realmente acessam.
Adicione seu fluxo de cobrança e pagamentos. Se os webhooks do Stripe ou Paddle pararem de chegar, ou seu endpoint de gerenciamento de assinaturas cair, você está perdendo dinheiro. Monitore os endpoints que tocam a receita.
Verifique seus jobs em segundo plano
Seu servidor está no ar. Sua API retorna 200. Seu painel carrega. Tudo parece bem. Mas seu backup noturno do banco de dados está falhando silenciosamente há duas semanas. Sua fila de e-mails está acumulada com 8.000 mensagens não entregues. Seu pipeline de exportação de dados parou há três dias.
Essa é a lacuna de monitoramento que pega a maioria das equipes. O monitoramento de disponibilidade cobre o caminho requisição-resposta. Ele não cobre tarefas agendadas, workers em segundo plano ou pipelines assíncronos.
O monitoramento heartbeat preenche essa lacuna. Cada tarefa agendada recebe uma URL única. Quando a tarefa é executada com sucesso, ela faz ping nessa URL. Se o ping não chegar dentro da janela esperada, você recebe um alerta. A configuração é um único comando curl no final do seu script cron.
Monitore estes jobs no mínimo:
- Backups de banco de dados
- Filas de entrega de e-mail
- Cobrança e geração de faturas
- Sincronizações e exportações de dados
- Rotação e limpeza de logs
- Automação de renovação de certificados
Saiba mais sobre monitoramento heartbeat e como ele captura o que as verificações de disponibilidade perdem.
Escolha o intervalo de verificação certo
Nem todo endpoint precisa da mesma frequência de verificação. Alinhe seus intervalos com o impacto nos negócios do tempo de inatividade.
Verificações de 30 segundos são para endpoints críticos de receita: seu fluxo de checkout, sua API principal, seu serviço de autenticação. Se estes caírem, você está perdendo dinheiro ou bloqueando usuários. Você precisa saber o mais rápido possível.
Verificações de 1 minuto funcionam para a maioria dos serviços de produção. Seu painel do aplicativo, APIs secundárias, endpoints de status. Rápido o suficiente para detectar problemas reais, devagar o suficiente para evitar alarmes falsos.
Verificações de 5 minutos são adequadas para endpoints de menor prioridade: páginas de marketing, sites de documentação, ferramentas internas. Se o site de marketing ficar fora do ar por 4 minutos, o impacto nos negócios é baixo.
Quanto mais rápidas as verificações, mais cedo você sabe. Mas verificações mais rápidas também significam mais dados, mais ruído e custos potencialmente mais altos. Combine o intervalo com o impacto.
Configure alertas que não esgotem sua equipe
A fadiga de alertas é o assassino silencioso do monitoramento. Quando cada pequeno problema aciona uma notificação, sua equipe para de prestar atenção. Eles silenciam o canal. Ignoram os e-mails. Então um incidente real acontece e ninguém percebe.
Use limites de escalonamento de alertas. Exija 2 ou 3 falhas consecutivas antes que um alerta seja disparado. Isso filtra problemas transitórios de rede que se resolvem sozinhos em segundos. Uma única verificação com falha não é um incidente. Três seguidas são.
Encaminhe alertas por gravidade. Monitores críticos vão para o PagerDuty ou telefones de plantão. Monitores de nível de aviso vão para um canal do Slack. Monitores informativos vão para e-mail ou painel. Não envie tudo para o mesmo lugar.
Use horas de silêncio para manutenção. Se você implanta toda terça-feira às 2h da manhã, suprima alertas nos monitores afetados durante essa janela. Sua equipe sabe sobre a implantação. Eles não precisam ser notificados porque o aplicativo reiniciou.
Separe canais de alerta de canais de discussão. Seu canal #alertas deve conter apenas mensagens de alerta automatizadas. A discussão humana acontece no #ops ou #engenharia. Isso mantém o feed de alertas limpo e escaneável.
Construa uma página de status que seus usuários realmente verifiquem
Sua página de status não é apenas uma caixa para marcar. É uma ferramenta de comunicação que reduz a carga de suporte durante incidentes.
Coloque-a em seu próprio domínio (status.suaempresa.com). Personalize-a com sua marca. Vincule-a a partir do rodapé do aplicativo, da documentação de suporte e das páginas de erro.
Quando um incidente acontecer, publique atualizações. “Estamos investigando relatos de erros elevados na API” é melhor que silêncio. “O problema foi identificado como esgotamento do pool de conexões do banco de dados. Estamos escalando.” diz aos usuários que você sabe o que está errado. “Monitorando a recuperação. A latência da API voltou ao normal.” fecha o ciclo.
Uma página de status que se atualiza automaticamente a partir dos seus dados de monitoramento significa que você não precisa acionar interruptores manualmente durante um incidente. A página reflete a realidade. Você se concentra em resolver o problema. Saiba mais sobre as páginas de status do PingWatchdog.
Revise seus incidentes
Após cada incidente, passe 10 minutos revisando o que aconteceu. Olhe para a linha do tempo. Quanto tempo levou para detectar? Quanto tempo para responder? Quanto tempo para resolver?
Esses três números são suas principais métricas de confiabilidade: tempo médio para detectar (MTTD), tempo médio para responder (MTTR) e tempo médio para resolver (MTTResolve). Acompanhe-os ao longo do tempo. Você está ficando mais rápido? Mais lento?
Use dados de incidentes para justificar melhorias. Se 40% dos seus incidentes são causados por problemas de conexão com o banco de dados, isso é um sinal para investir em pool de conexões ou réplicas de leitura. Se a expiração de certificados SSL causa incidentes a cada 90 dias, automatize a renovação de certificados.
O PingWatchdog cria incidentes automaticamente quando os monitores caem e os resolve automaticamente quando os serviços se recuperam. Você obtém uma linha do tempo completa sem trabalho manual. Saiba mais sobre gerenciamento de incidentes.
Faça camadas no seu monitoramento
Uma única ferramenta não pode cobrir tudo. Use o PingWatchdog para monitoramento externo: disponibilidade, SSL, heartbeat, páginas de status. Use ferramentas de monitoramento de desempenho de aplicações (APM) como Datadog ou Sentry para métricas internas. Use agregação de logs para depuração.
A visão externa diz se os usuários podem alcançar seu serviço. A visão interna diz por quê. Ambas importam.
Compare ferramentas de monitoramento para encontrar a stack certa para sua equipe.