Por que monitorar?
Quando você tem um servidor rodando serviços para você, para seus clientes, ou para os dois, uma hora ou outra algo vai cair. Pode ser um certificado SSL que expirou, um container que consumiu toda a memória, uma API que parou de responder, ou simplesmente o provedor de nuvem que teve um problema de rede.
A diferença entre um problema e uma crise é saber que ele aconteceu antes do cliente te avisar.
Monitoramento não é sobre evitar que coisas quebrem — coisas sempre quebram. É sobre saber que quebrou, o mais rápido possível, para poder agir antes que o impacto seja grande.
Por onde comecei
Durante muito tempo, meu monitoramento era artesanal: um script shell aqui, um cron com curl ali, e torcer para o ping funcionar. Funcionava? Mais ou menos. O problema é que monitoramento artesanal só avisa o que você lembrou de monitorar, e você sempre esquece de monitorar exatamente o que vai quebrar.
Minha primeira ferramenta “de verdade” foi o Uptime Robot. É um serviço freemium que monitora sites e APIs com checks de uptime a cada 5 minutos no plano gratuito. Na época resolvia o básico: saber se o site estava no ar ou não. O plano gratuito permite até 50 monitores, que para um começo é mais que suficiente.
Usei o Uptime Robot por um bom tempo e ainda uso para alguns projetos específicos. É confiável, simples, e cumpre o que promete. Mas tem limitações: você não controla os servidores de check, não tem monitoramento de SSL avançado, e o plano gratuito tem um limite de alerts que pode ser frustrante quando vários serviços caem ao mesmo tempo.
A transição para o self-hosted
Com o tempo, fui crescendo minha infraestrutura. Mais servidores, mais containers, mais serviços. E aí o Uptime Robot começou a ficar apertado: precisei de checks mais frequentes, monitoramento de portas específicas, e a possibilidade de criar páginas de status personalizadas para meus clientes.
Foi aí que conheci o Uptime Kuma.
O Uptime Kuma é um divisor de águas no monitoramento self-hosted. É open source, bonito, extremamente configurável, e roda em um container Docker com mínimo esforço. A interface é limpa, os alertas funcionam com dezenas de canais (email, Telegram, WhatsApp, Discord, Slack, Webhooks…), e ele já vem com página de status embutida.
A instalação é trivial:
docker run -d --name uptime-kuma -p 3001:3001 louislam/uptime-kuma:latest
E em cinco minutos você já está monitorando seus primeiros serviços.
Com o Uptime Kuma, posso:
- Monitorar HTTP, HTTPS, TCP, Ping, DNS, Push, e até Steam Game Server
- Configurar checks a cada 30 segundos ou mais
- Criar páginas de status públicas para meus clientes acompanharem
- Receber alertas no Telegram no mesmo instante que algo cai
- Ver histórico de uptime com gráficos claros
- Configurar manutenções programadas
O problema do self-hosted
Mas tem um detalhe: você está monitorando seus serviços com um serviço que roda na sua própria infraestrutura. Se o servidor cair, seu monitoramento cai junto. É o velho problema do “quem vigia o vigia?”
Para resolver isso, tenho o Uptime Kuma rodando em um servidor separado dos serviços que ele monitora. Se um servidor cai, o outro ainda está de pé para avisar. É o mínimo de redundância que você precisa ter quando opta pelo self-hosted.
Outras opções self-hosted
O Uptime Kuma é meu preferido, mas não é o único. Algumas alternativas que merecem menção:
Gatus — Leve, altamente customizável, e configurado via YAML. Diferente do Uptime Kuma que tem interface web completa, o Gatus é mais “config-as-code”. Ideal para quem prefere versionar a configuração. Tem suporte a testes complexos (código de status, headers, body, latency) e página de status automática.
Cachet — Focado em página de status. O Cachet é bonito, usado por empresas grandes (Boeing, Siemens, GNOME), e tem uma API poderosa. Mas é mais um sistema de comunicação de incidentes do que de monitoramento — você precisa de outra ferramenta para fazer os checks.
Checkmate — Monitora servidores, sites, containers Docker, com analytics e alertas. Interface moderna, mas menos comunidade que o Uptime Kuma.
Opções SaaS (quando não dá para self-hostar)
Nem todo mundo quer ou pode manter mais um serviço rodando. Para esses casos, as opções SaaS são uma mão na roda:
Uptime Robot — O clássico. 50 monitores grátis, checks a cada 5 minutos. Simples, confiável, e já tem página de status. Ótimo para começar.
Better Stack (antigo Better Uptime) — Interface moderna, heartbeat, incidentes, página de status, e integração com calendário. Tem plano gratuito generoso. Diferencial: já vem com status page bonita e domínio próprio.
Pingdom — O veterano. Monitoramento global, relatórios detalhados, alertas por SMS. Funciona bem, mas o custo sobe rápido se você precisa de mais checks.
StatusCake — Plano gratuito com 10 monitores e checks a cada 5 minutos. Suporte a monitoramento de SSL e domínio. Opção intermediária sólida.
HetrixTools — Focado em blacklist e uptime. Útil para quem gerencia servidores de email.
A página de status
Se você oferece SaaS para clientes, uma página de status não é opcional — é requisito mínimo de profissionalismo.
Seus clientes merecem saber quando algo não está funcionando, e uma página de status pública resolve isso de forma transparente. O Uptime Kuma já entrega isso de graça: você cria uma página pública com seus serviços, e os clientes acompanham em tempo real.
Sem página de status, o cliente fica no escuro. Ele manda email, mensagem no WhatsApp, abre ticket — e você perde tempo respondendo “já estamos cientes” em vez de resolvendo o problema. Com a página de status, ele consulta antes de perguntar.
Minha stack atual de monitoramento
Hoje meu monitoramento é híbrido:
- Uptime Kuma self-hosted: monitoramento principal de todos os serviços — sites, APIs, portas, SSL
- Página de status pública: embutida no Uptime Kuma, acesso restrito para clientes
- Alertas no Telegram: chegando no celular em segundos quando algo cai
- Netdata: para métricas detalhadas de servidor (CPU, RAM, disco, rede) — esse merece um post separado
E para os serviços mais críticos (banco de dados, API principal), tenho monitores também no Uptime Robot como redundância externa.
A recomendação final
Se você está começando, use o Uptime Robot. É grátis, simples, e cobre o básico.
Se você já tem um servidor e quer mais controle, monte um Uptime Kuma em Docker. A instalação leva 5 minutos e o ganho é imenso.
Se você oferece SaaS, tenha uma página de status pública, não importa qual ferramenta use.
E lembre-se: monitoramento não é sobre nunca ter problemas. É sobre saber deles antes dos seus clientes.