O problema com o cron
O cron é confiável de uma forma: ele executará seu comando conforme agendado. Ele não é confiável de outra forma, mais importante: ele não avisa quando seu comando falha.
Seu servidor está rodando. O daemon cron está funcionando. O agendamento é acionado no horário. Mas o script que você apontou termina com um status diferente de zero, atinge um timeout ou fica sem memória. Ninguém sabe. O trabalho do cron é iniciar o processo, não verificar se ele foi bem-sucedido.
Isso não é um bug do cron. É assim que o cron foi projetado. O cron é anterior à web. Foi construído em uma era em que as tarefas escreviam em arquivos de log e um humano as verificava periodicamente. Esse modelo não escala para a infraestrutura moderna, onde um desenvolvedor gerencia dezenas de tarefas agendadas em vários servidores.
O que as falhas silenciosas do cron custam para você
Uma falha silenciosa de backup significa que você a descobre quando precisa do backup. Talvez três semanas depois, após um incidente de corrupção de banco de dados. A lacuna entre quando o backup parou de funcionar e quando você precisava dele são dados que você não pode recuperar.
Uma falha silenciosa na fila de e-mails significa que os clientes param de receber notificações. Redefinições de senha, confirmações de pedido, recibos de cobrança. Ninguém reclama no início porque ninguém sabe o que está faltando. Quando você percebe, tem milhares de e-mails não entregues e usuários confusos.
Uma falha silenciosa na exportação de dados significa que suas análises estão erradas. Seus dashboards mostram tendências baseadas em dados desatualizados. Você toma decisões com informações incompletas. O erro se agrava quanto mais tempo passa sem ser detectado.
Por que o monitoramento de uptime não detecta isso
Seu monitor de uptime diz que seu servidor está no ar. Sua API retorna 200. Seu dashboard carrega. Está tudo bem de acordo com seu painel de monitoramento.
Mas nenhuma dessas verificações informa se o backup da noite passada foi concluído. Elas não sabem se sua conciliação de cobrança foi executada. Elas não sabem se o pipeline de dados que alimenta suas análises terminou.
O monitoramento de uptime responde: «Consigo alcançar este endpoint?». O monitoramento heartbeat responde: «Esta tarefa foi executada?». São perguntas complementares. Você precisa de ambas.
Como funciona o monitoramento heartbeat
O monitoramento heartbeat é simples. Cada tarefa agendada recebe uma URL única com um token secreto. No final da sua tarefa, adicione uma única linha que faz ping nessa URL:
curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKENSe o ping chegar dentro da janela esperada, a verificação heartbeat é aprovada. Se a janela fechar sem ping, o monitor aciona um alerta.
Você configura o intervalo esperado. Se seu backup é executado a cada 6 horas, defina o intervalo para 6 horas. Adicione um período de tolerância se a duração da tarefa variar. Um período de tolerância de 10 minutos significa que o monitor não alerta a menos que o ping esteja 10 minutos atrasado.
Essa é toda a configuração. Uma URL. Um comando curl. Zero arquivos de configuração.
Configurando na prática
Aqui está uma entrada cron para um backup noturno de banco de dados:
0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKENO && é importante. Significa: «Execute curl somente se o script de backup terminar com status 0 (sucesso)». Se o backup falhar, o curl nunca é executado. Nenhum ping chega. Você recebe um alerta.
Se você quiser monitorar que o script foi executado (mesmo que tenha falhado), use ; em vez de && e adicione tratamento de erros dentro do script para relatar o status. Mas para a maioria dos casos de uso, && é o que você quer. Você se importa com o sucesso, não apenas com a execução.
O que monitorar com heartbeats
Comece pelos trabalhos que mais doeriam se falhassem silenciosamente:
Backups de banco de dados: Este é o caso de uso mais comum e o de maior custo de falha. Um backup que você não sabe que está faltando é pior do que nenhum backup.
Filas de entrega de e-mail: Se seus e-mails transacionais ou de marketing pararem de ser enviados, você quer saber em minutos, não em horas.
Cobrança e geração de faturas: Cobrança com falha significa receita perdida. Um heartbeat no seu trabalho de cobrança detecta isso antes do fim do mês.
Sincronizações e exportações de dados: Se seu pipeline de análise ou sincronização de data warehouse falhar, seus relatórios estão errados. Um heartbeat avisa dentro do intervalo esperado.
Renovação de certificados: Se você usa certbot ou ferramentas similares com renovação automática, adicione um heartbeat. A expiração de certificados é uma das causas mais evitáveis de tempo de inatividade.
Rotação e limpeza de logs: Se a rotação de logs falhar, seu disco enche. Seu servidor cai. Um heartbeat detecta a falha de rotação antes que o disco esteja cheio.
Monitoramento heartbeat vs. serviços de monitoramento de cron
Ferramentas como Healthchecks.io e Cronitor focam exclusivamente no monitoramento de cron e tarefas agendadas. Elas fazem isso bem. Algumas adicionam recursos como rastreamento de duração de tarefas e tendências de desempenho.
O PingWatchdog inclui monitoramento heartbeat junto com monitoramento de uptime e monitoramento SSL em uma única plataforma. Você não precisa de uma ferramenta separada para cron jobs. Você monitora seus sites, APIs, certificados SSL e tarefas agendadas em um único dashboard com um único pipeline de alertas.
Isso importa porque a mesma equipe que monitora o uptime geralmente cuida dos cron jobs. Consolidar ferramentas significa menos dashboards para verificar, menos canais de alerta para configurar e menos assinaturas para gerenciar.
Compare o PingWatchdog com o Healthchecks.io para ver como nosso monitoramento heartbeat se compara ao monitoramento de uptime e páginas de status.
Monitoramento de cron em contêineres e Kubernetes
Se você executa cron jobs dentro de contêineres Docker ou CronJobs do Kubernetes, o mesmo padrão heartbeat funciona. Adicione um comando curl no final do ponto de entrada do seu contêiner ou do comando do seu CronJob.
Para Kubernetes:
apiVersion: batch/v1
kind: CronJob
metadata:
name: db-backup
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: your-backup-image
command:
- /bin/sh
- -c
- "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
restartPolicy: OnFailureO mesmo princípio se aplica a eventos agendados do AWS Lambda, Google Cloud Scheduler, timers do systemd ou qualquer outro agendador. Se sua tarefa pode fazer uma requisição HTTP, ela pode enviar um heartbeat.
Comece agora
O PingWatchdog inclui monitoramento heartbeat em todos os planos. O plano gratuito oferece 3 monitores heartbeat. Os planos pagos vão até 25.
Saiba mais sobre os recursos de monitoramento heartbeat ou configure seu primeiro monitor.