Grafana, Prometheus ou Uptime Kuma: monitorar VPS sem virar SRE
-
Maicon Ramos
- Docker, Grafana, monitoramento, Prometheus, Uptime Kuma, VPS
- 17 minutos de leitura
Navegue por tópicos
Uptime Kuma é o ponto de partida para descobrir que uma URL, porta ou job parou. Prometheus com Node Exporter ajuda a entender CPU, memória e disco. Grafana organiza essas métricas em painéis e alertas. Para uma VPS pequena, comece pelo alerta que alguém vai receber e só amplie a stack quando houver uma decisão a tomar.
Quem hospeda uma API, automação ou app em VPS costuma notar o problema tarde demais: quando um cliente avisa. O caminho comum é instalar Grafana, Prometheus e vários dashboards logo de início.
Isso parece profissional. Também pode criar uma coleção de telas sem responsável, volumes sem backup e alertas que ninguém lê. O primeiro objetivo operacional é mais simples: saber que a experiência pública falhou antes de alguém do lado de fora avisar.
Chamamos essa regra de Alarme Antes do Painel. Ela ajuda a escolher a ferramenta pelo problema presente, em vez de transformar uma VPS em projeto paralelo de SRE.
A resposta curta: cada ferramenta responde uma pergunta diferente
Grafana, Prometheus e Uptime Kuma funcionam bem juntos. Porém, cada um começa por uma pergunta distinta. Escolher pela pergunta reduz configuração inútil.
| Ferramenta | Pergunta respondida | Entrada | Alerta | Persistência | Quando escolher | Quando não basta |
|---|---|---|---|---|---|---|
| Uptime Kuma | A URL, porta ou job respondeu? | Checks HTTP(S), TCP, Ping, DNS, Push e outros | Notificações configuráveis, como Telegram, Discord e SMTP | Dados da própria aplicação precisam permanecer disponíveis | Você precisa saber cedo que um serviço público caiu | Quando precisa explicar CPU, RAM, disco ou tendências |
| Prometheus | O que mudou nas métricas do host ou app? | Coleta por scraping em exporters e alvos | Usa regras; o Alertmanager roteia alertas no desenho tradicional | O diretório de dados deve usar armazenamento persistente | Você precisa investigar degradação com séries temporais | Quando falta um alerta externo ou alguém para operar regras |
| Grafana | Como ler e acompanhar os dados? | Fontes de dados, como Prometheus | Contact points encaminham notificações para destinos configurados | Configuração exige volume ou bind mount para sobreviver ao container | Já existem métricas que precisam virar decisão | Quando ainda não há dados úteis para visualizar |
O Uptime Kuma pode expor métricas dos monitores no endpoint /metrics quando a integração Prometheus está habilitada. Isso permite crescer por camadas. Você mantém o check de disponibilidade e adiciona diagnóstico sem recomeçar o monitoramento.
A distinção evita dois erros recorrentes. Grafana não coleta métricas sozinho. Uptime Kuma também não substitui um exporter de sistema para informar CPU, memória e disco.
Alarme Antes do Painel: o primeiro sinal de um solo builder
Uma VPS pode ter um dashboard impecável e continuar falhando para o usuário. Se a URL pública retorna erro, a porta deixa de responder ou um job agendado não confirma execução, a informação importante precisa chegar a uma pessoa.
O README oficial do Uptime Kuma lista checks HTTP(S), TCP, busca por palavra-chave ou JSON, WebSocket, Ping, DNS, Push e Docker, além de canais de notificação. Para uma operação pequena, isso cobre perguntas operacionais úteis sem exigir uma base de séries temporais desde o primeiro dia.
URL pública, TCP e job agendado
Comece pelo caminho que gera receita ou impede uma entrega. Pode ser a URL do app, a API que recebe webhook, uma porta TCP ou o job que gera uma tarefa crítica.
Um monitor HTTP testa a resposta do endpoint. Um monitor TCP ajuda a perceber se uma porta esperada responde. Para jobs, o monitor Push inverte a lógica: o job precisa enviar o sinal de vida depois de terminar. Se o sinal não chega no período definido, há algo para investigar.
Esse modelo pede uma decisão antes da ferramenta: quem recebe o aviso e o que fará em seguida? Um alerta no canal certo, com um responsável e uma ação inicial, reduz o tempo entre falha e diagnóstico.
Alerta que chega em alguém vale mais que painel sem dono
Não existe obrigação de usar cada gráfico disponível. Escolha poucos sinais que mudam uma ação. Por exemplo: indisponibilidade pública, erro de job, pouco espaço em disco e consumo de memória que antecede travamentos.
O Alertmanager, componente do ecossistema Prometheus, recebe alertas, deduplica, agrupa e os roteia para receivers. A documentação oficial descreve destinos como e-mail, PagerDuty e OpsGenie. O Grafana também oferece contact points para destinos como e-mail, Slack, IRM e webhooks.
A leitura do Runzos é direta: antes de montar regras sofisticadas, teste um alerta real. Interrompa um alvo de teste, confirme a notificação e registre a primeira ação. O alerta só existe operacionalmente quando alguém consegue recebê-lo e agir.
Quando Uptime Kuma basta e quando ele não enxerga a falha
Uptime Kuma basta como primeira camada quando a pergunta é pública e objetiva: o endpoint responde? O job terminou? A porta está aberta? Ele simplifica a criação de checks e torna o estado visível.
Ele deixa lacunas naturais. Uma URL pode estar disponível enquanto a memória cresce, o disco se aproxima do limite ou um processo consome CPU demais. Esses sinais pedem métricas do host ou da aplicação.
A VPS não pode ser sua única testemunha
Um monitor instalado na mesma VPS do app compartilha host, Docker e rota de rede. Se a máquina inteira falhar, esse monitor também pode parar. Ele não terá como avisar sobre a própria indisponibilidade.
Isso não invalida o Uptime Kuma local. Ele continua útil para diagnóstico e para problemas que não derrubaram a VPS inteira. Porém, a checagem pública mais importante precisa ter um domínio de observação separado quando a disponibilidade passa a ter impacto real.
Uma sonda externa ou serviço gerenciado cria esse segundo ponto de vista. Ela não elimina incidentes. Ela apenas permite testar a experiência pública de fora do mesmo ambiente que pode ter caído.
Quando usar sonda externa ou serviço gerenciado
Adicione uma sonda externa quando o app passou a ter usuários, recebe vendas, aciona automações importantes ou virou dependência de outra equipe. O gatilho não é aparência de maturidade. É a consequência de descobrir a falha tarde.
Serviço gerenciado também pode ser a escolha correta quando ninguém consegue manter atualizações, regras, volumes e recuperação. A complexidade técnica precisa caber na rotina de quem opera a VPS.
Prometheus com Node Exporter: quando é preciso entender CPU, memória e disco
Prometheus coleta métricas por scraping. Para métricas do host, o Node Exporter expõe dados de hardware e sistema operacional em kernels Unix-like para o Prometheus consumir.
Essa combinação responde perguntas de diagnóstico. O app ficou lento porque faltou memória? O disco cresceu antes da falha? A CPU ficou ocupada durante um pico? Sem uma série histórica, você enxerga apenas o estado depois do incidente.
O Prometheus separa parâmetros do servidor e jobs de coleta. A documentação oficial informa que local de armazenamento e retenção são definidos por flags, enquanto os jobs de scraping ficam no arquivo de configuração. Essa separação pede disciplina na configuração e na documentação do que cada regra mede.
Exporter, scraping, retenção e armazenamento persistente
Dados do Prometheus ficam em /prometheus no container. Sem armazenamento persistente ou bind mount, eles podem ser apagados em um restart. A mesma preocupação existe no Grafana: mudanças no filesystem do container não sobrevivem à remoção sem volume ou bind mount.
Volume persistente resolve continuidade de dados. Ele não cria um backup testado. Backup exige cópia recuperável, teste de restauração e clareza sobre o que entra na cópia: configuração, banco do app, volumes e dados de métricas.
A retenção também exige folga. A documentação de storage do Prometheus explica que, durante compactação, blocos antigos e o novo bloco podem coexistir. O disco pode ultrapassar temporariamente o limite de retenção configurado.
Não há requisito universal de CPU, RAM ou armazenamento para a pilha inteira nas fontes consultadas. Carga, intervalo de coleta, quantidade de séries e retenção mudam o consumo. A decisão segura é observar o ambiente depois da instalação e definir gatilhos de aumento com base nesses dados.
Métricas que justificam ação
Evite coletar tudo por receio de perder informação. Comece por métricas ligadas a ações conhecidas: pouco espaço em disco exige limpeza ou ampliação; memória sob pressão pede investigação de processo; CPU sustentada pede análise de carga; target indisponível pede olhar configuração ou conectividade.
Prometheus é valioso quando transforma um sintoma em hipótese verificável. Se nenhuma métrica orienta uma próxima ação, ela pode esperar.
Onde o Grafana entra e por que ele não substitui Prometheus
Grafana organiza fontes de dados em painéis e pode configurar alertas. Ele não ocupa o papel de coletor de métricas. Sem Prometheus, outra fonte compatível ou dados de aplicação, o painel não terá a matéria-prima para mostrar.
O Grafana faz sentido quando já existem perguntas repetidas. Você quer acompanhar os mesmos sinais de host, comparar períodos ou oferecer uma visão compartilhada de um incidente. O painel reduz a fricção de leitura; ele não reduz a responsabilidade de revisar alertas e atualizar serviços.
A documentação do Grafana para Docker reforça um detalhe operacional: a configuração precisa de persistência. Remover um container sem volume ou bind mount pode descartar mudanças feitas no filesystem. Planeje esse volume antes de considerar a instalação descartável.
Segurança e persistência: quatro erros que criam uma pilha silenciosa
A observabilidade adiciona serviços administrativos. Cada um merece uma decisão de acesso, armazenamento e recuperação.
Volumes não são backup
Use volumes persistentes para Grafana e Prometheus. Depois, defina backups separados e teste uma restauração em ambiente seguro. Uma cópia que nunca foi restaurada ainda deixa dúvida no dia do incidente.
Não exponha consoles administrativos
Grafana, Prometheus e Uptime Kuma não precisam virar portas abertas na internet. Mantenha acesso autenticado e prefira rede privada ou proxy reverso com TLS e política de acesso. A interface administrativa deve atender operadores, não visitantes anônimos.
Não monte docker.sock por padrão
O monitor de containers do Uptime Kuma pode parecer conveniente. A wiki oficial alerta que expor o socket ou TCP do Docker dá controle total do daemon ao Kuma. Se o container for comprometido, o host pode ser tomado.
Trate esse acesso como exceção de alto impacto. Se o caso realmente exigir monitoramento de containers por esse método, mantenha a interface do Kuma fora da internet e registre a justificativa. Para muitos casos, monitorar o endpoint público oferece um primeiro sinal com menos privilégio.
Fixe versão, atualize e tenha rollback
As três ferramentas tiveram releases recentes verificados em 5 de setembro de 2026. Isso sinaliza manutenção ativa, não autorização para usar latest sem teste. Fixe versões no Compose, leia mudanças relevantes e mantenha um caminho de rollback antes da atualização.
| Item | Verificação | Evidência esperada | Frequência | Responsável |
|---|---|---|---|---|
| Volume persistente | Confirmar volume ou bind mount para Grafana e Prometheus | Configuração do Compose e dados preservados após recriar o container | Na instalação e após mudanças de volume | Quem mantém a infraestrutura |
| Backup testado | Copiar configurações, bancos e volumes relevantes; restaurar em ambiente seguro | Registro de uma restauração concluída e dos itens recuperados | Após mudança importante e em revisão periódica | Dono da operação |
| Versões fixadas | Usar versões definidas no Compose e revisar mudanças antes do upgrade | Arquivo de configuração com versões fixadas e caminho de rollback | Antes de cada atualização | Quem atualiza os serviços |
| Acesso autenticado | Manter consoles administrativos com autenticação | Política de acesso aplicada ao Grafana, Prometheus e Uptime Kuma | Na instalação e em cada troca de acesso | Operador responsável |
| Portas privadas | Evitar exposição pública desnecessária; preferir rede privada ou proxy reverso com TLS | Interfaces administrativas sem porta aberta para visitantes anônimos | Na instalação e após alteração de rede | Quem mantém a VPS |
| Teste de alerta | Interromper um alvo de teste e confirmar o recebimento da notificação | Alerta chega ao responsável com primeira ação definida | Na criação e após mudar canal ou destinatário | Dono do app ou da automação |
| Rollback | Definir como retornar à versão anterior antes de atualizar | Procedimento documentado e imagem ou configuração anterior disponível | Antes de cada atualização | Quem atualiza os serviços |
| `docker.sock` | Usar acesso ao socket apenas quando houver necessidade documentada e controles adequados | Justificativa registrada; interface do Kuma protegida contra acesso público | Antes de habilitar e em cada revisão de acesso | Responsável pela infraestrutura |
Stack por estágio operacional
| Estágio | Sinal mínimo | Ferramenta inicial | Onde a sonda roda | Responsável pelo alerta | Próximo passo |
|---|---|---|---|---|---|
| URL pública ou API simples | Resposta HTTP(S) | Uptime Kuma | Preferencialmente fora da VPS para o check crítico | Dono do app | Testar alerta e documentar a primeira ação |
| Job ou cron | Sinal de conclusão no prazo | Uptime Kuma Push | No job, com monitor em local separado quando crítico | Dono da automação | Adicionar alerta de falha e registro de execução |
| App com usuários | Disponibilidade e erro percebido | Uptime Kuma mais sonda externa | Domínio separado para teste público | Responsável de plantão definido | Adicionar métricas de host se o diagnóstico demora |
| Múltiplos containers | CPU, memória, disco e alvos | Prometheus com Node Exporter | VPS, com acesso protegido | Quem mantém a infraestrutura | Criar poucos painéis no Grafana |
| Operação crítica | Alertas roteados e histórico útil | Prometheus, Grafana e Alertmanager | Separar domínios de falha quando possível | Escala definida | Revisar recuperação, retenção e serviço gerenciado |
Custo real no Brasil: VPS é só uma linha da conta
Comparar apenas o plano da VPS dá uma visão curta. O custo operacional inclui tempo e práticas que não aparecem no checkout. Como preços, cupons e condições variam, confira valores no dia da publicação ou contratação.
| Item | É obrigatório? | Valor verificável hoje? | Risco se ignorar | Quando reavaliar |
|---|---|---|---|---|
| VPS e volume persistente | Sim para stack local | Depende do plano e da carga | Perda de dados ou capacidade insuficiente | Após crescimento de disco, CPU ou memória |
| Domínio e TLS | Depende da arquitetura | Condição varia por fornecedor | Acesso inseguro ou operação improvisada | Na renovação e ao mudar o proxy |
| Backup | Sim para estado relevante | Depende de retenção e destino | Restauração impossível após incidente | Após qualquer mudança importante |
| Sonda externa ou serviço gerenciado | Recomendado para check público crítico | Depende do serviço escolhido | Falha total sem aviso independente | Quando o impacto do downtime aumentar |
| Canal de alerta | Sim | Depende do canal | Alarme sem destinatário | Em cada troca de equipe ou contato |
| Horas de manutenção | Sim | Não há preço universal | Atualização, regra e incidente sem dono | Todo mês |
| Upgrade e rollback | Sim para produção | Não há valor fixo | Atualização amplia indisponibilidade | Antes de cada versão nova |
Se você está escolhendo onde rodar containers e manter esses volumes, vale avaliar a infraestrutura que vai sustentar seus apps e alertas. Para uma stack Docker com n8n, também dá para rodar sua stack Docker em uma VPS ou comparar VPS brasileira com suporte em português.
As rotas acima servem para avaliar infraestrutura. Elas não substituem o checklist de persistência, backup, acesso e resposta a alerta.
Checklist: comece pequeno, aumente por evidência
Antes de ampliar a stack, percorra esta lista:
- Definir a URL, porta ou job que representa a entrega mais crítica.
- Criar um check e enviar o alerta a uma pessoa responsável.
- Simular uma falha controlada e confirmar a notificação.
- Usar volume persistente para dados e configurações necessários.
- Criar backup separado e testar uma restauração.
- Manter interfaces administrativas autenticadas e fora da exposição pública desnecessária.
- Evitar
docker.sockaté haver uma necessidade documentada e controles de acesso adequados. - Fixar versões de containers e planejar atualização com rollback.
- Adicionar Node Exporter e Prometheus quando CPU, memória ou disco virarem perguntas recorrentes.
- Criar painéis no Grafana apenas para métricas que orientam uma ação.
- Separar a sonda pública crítica da VPS quando uma falha total passar a ter impacto relevante.
- Revisar mensalmente destinatários, alertas, volumes e procedimentos de recuperação.
A melhor evolução é guiada por evidência. Cada nova camada deve responder a uma pergunta que a operação já fez mais de uma vez.
FAQ
Grafana substitui Prometheus?
Não. Grafana é uma plataforma de visualização e alertas que consulta fontes de dados. Prometheus é um sistema de monitoramento e banco de séries temporais que coleta métricas por scraping. Você pode usar Grafana com outras fontes, mas ele precisa receber dados de algum lugar. Para métricas de host em uma VPS, Prometheus com Node Exporter é uma combinação comum; o Grafana entra para acompanhar e organizar a leitura dessas métricas.
Uptime Kuma monitora CPU e RAM?
O Uptime Kuma monitora disponibilidade e tipos de check, como HTTP(S), TCP, Ping, DNS, Push e Docker. Ele não substitui um exporter de sistema para CPU, memória e disco. Quando essas métricas viram necessárias para explicar lentidão ou prevenir falta de capacidade, use uma fonte de métricas como Node Exporter com Prometheus. Começar pelo Kuma continua útil porque o alerta de disponibilidade resolve outra pergunta.
Posso rodar tudo na mesma VPS?
Pode, especialmente em uma operação pequena, desde que proteja acesso, use persistência e dimensione pelo comportamento real do ambiente. Há uma limitação arquitetural: se app, monitor e infraestrutura estão no mesmo host, uma falha total pode derrubar todos juntos. Para a checagem pública mais importante, use uma sonda em domínio separado quando o impacto justificar essa camada adicional.
O que acontece se a VPS inteira cair?
Um monitor localizado na própria VPS pode deixar de executar junto com o app. Por isso, ele não confirma sozinho a disponibilidade externa do host. Uma sonda externa testa a URL ou porta a partir de outro domínio de falha e consegue gerar um aviso sobre a experiência pública. Ela não evita a queda nem substitui recuperação, backup ou diagnóstico; ela melhora a chance de você descobrir o problema cedo.
Preciso expor Grafana ou Prometheus na internet?
Não como padrão. São interfaces administrativas e devem ficar atrás de autenticação. Prefira rede privada ou proxy reverso com TLS e política de acesso. Exposição pública desnecessária amplia a superfície de ataque. O mesmo cuidado vale para o Uptime Kuma, sobretudo se ele tiver acesso elevado ao Docker. A operação precisa equilibrar acesso do time e proteção das interfaces.
Quando serviço gerenciado é melhor?
Serviço gerenciado é uma escolha sensata quando não há tempo ou pessoa responsável por atualizações, alertas, volumes, retenção e recuperação. A pilha self-hosted oferece controle, mas também exige rotina. Se a consequência de perder um alerta é grande e a equipe não consegue manter a infraestrutura, pagar por uma sonda externa ou monitoramento gerenciado pode reduzir risco operacional.
A melhor stack é a que avisa e que você consegue manter
Uptime Kuma, Prometheus e Grafana resolvem problemas diferentes. Comece pelo check que prova que a entrega pública funciona e faça o alerta chegar a alguém. Depois, acrescente métricas de host para explicar degradações e painéis para acompanhar decisões repetidas.
A interpretação do Runzos adiciona uma regra simples: uma VPS bem monitorada não é a que tem mais gráficos. É a que dá um sinal útil, mantém seus dados recuperáveis e tem alguém capaz de agir quando o sinal aparece.
Maicon Ramos
