Prometheus e Grafana em um VPS: três métricas que vale a pena monitorar
Publicado em 2026-10-26 por frfrand
CPU, memória, disco e alertas para aplicações em produção
Quando uma web fica lenta, o número de visitas não é suficiente para explicar o que aconteceu. Três métricas básicas podem dar uma visão útil: memória disponível, CPU utilizada e espaço em disco. O Prometheus coleta séries temporais e o Grafana as apresenta.
Vamos ao ponto: o que significa, como testar e o que acontece quando você usa com clientes ou informações reais. A maioria dos problemas não se resolve com um botão mágico, mas com etapas que você pode repetir e medir.
O que é Prometheus e Grafana em VPS e por que isso importa
O Prometheus consulta métricas expostas por exporters e serviços, enquanto o Grafana constrói painéis e alertas com fontes de dados. Para infraestrutura Linux, costuma-se usar o node_exporter, com acesso ao seu endpoint restrito à rede de monitoramento.
Uma coisa é uma demonstração funcionar por cinco minutos; outra é manter um serviço todos os dias. Para isso, você precisa de limites, permissões, registros de atividade e procedimentos para resolver falhas sem improvisar.
Exemplo de implementação ou diagnóstico
# Ejemplo de consultas PromQL, adaptar job/labels
100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
(node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100
# Reglas/umbrales deben considerar volúmenes y exclusionesÉ uma referência didática, não um modelo que você deve executar às cegas em produção. Substitua os valores de exemplo, escolha identidades com permissões mínimas e garanta que nenhuma chave sensível termine em um log ou repositório.
Como eu colocaria isso para funcionar
- Instale um exporter no VPS e proteja seu endpoint; não o abra à Internet por costume.
- Configure o Prometheus para coletar métricas com etiquetas claras por servidor.
- Crie um painel Grafana com CPU, memória disponível e disco por volume.
- Adicione um sinal de aplicação: latência HTTP, taxa de erros ou fila de jobs.
- Configure alertas acionáveis e verifique quais informações você receberá antes de uma queda.
Após cada passo, verifique um resultado concreto: uma ação autorizada, um status HTTP, uma tarefa processada, um custo registrado ou uma métrica estável. Se algo não funcionar, verifique qual foi a primeira falha antes de tentar novamente em loop.
Um exemplo que pode aparecer em um projeto real
Uma API FastAPI atende reservas com Celery. O dashboard mostra RAM se esgotando quando o worker é iniciado, enquanto as consultas do PostgreSQL continuam rápidas. Esse dado o orienta a revisar a concorrência de tarefas, não o DNS.
Se essa aplicação tiver vários clientes, separe contextos e recursos. É especialmente importante quando um chatbot ou um agente pode consultar dados: a facilidade de conectar ferramentas não deve pular os limites de privacidade e autorização.
O erro mais comum
Um dashboard bonito não significa que haja alertas. Evite mostrar exporters sem autenticação nem registrar métricas de cada URL com IDs privados; podem causar cardinalidade excessiva.
Uma configuração com bons padrões ajuda, mas não elimina a necessidade de testes. Para serviços que gravam dados ou disparam ações, considere retentativas, duplicatas e falhas no meio do caminho.
Onde entra o ArduMaker?
O ArduMaker permite administrar o VPS e seus processos. Uma camada de métricas com Prometheus/Grafana ajuda a dimensionar e detectar incidentes antes que os usuários reclamem.
Com o ArduMaker você pode hospedar o backend em um VPS, implantar a partir do Git, configurar domínio HTTPS e utilizar ferramentas de bancos de dados, serviços e MCP de acordo com o projeto. Isso facilita reunir operações em um ambiente, embora as regras de negócio e de segurança continuem sendo responsabilidade do software.
O que mediria para saber se melhorou
Não mediria apenas «funciona/não funciona». Também revisaria consumo de recursos, erros, tempos de resposta ou gasto de API, de acordo com a funcionalidade. Defina uma medida de sucesso antes da mudança e compare com o mesmo cenário depois.
Se um dado parecer estranho, verifique a amostra e a janela temporal. Uma média pode esconder casos extremos, e uma única execução bem-sucedida não demonstra que uma automação suporte milhares de solicitações.
Perguntas frequentes
Preciso de uma infraestrutura grande para começar? Não necessariamente. Primeiro resolva o problema com uma arquitetura simples e meça o ponto onde começa a ficar aquém.
O que acontece se o provedor externo falhar? Você precisa de timeouts, política de tentativas e uma resposta útil para o usuário. Não assuma que APIs externas estão sempre disponíveis.
Como mantenho o controle? Registre eventos importantes, separe permissões e conserve um procedimento testado para desfazer alterações ou recuperar informações.
Referências para seguir
A ideia final: automatizar e medir vale a pena quando você também sabe detectar um erro, limitar seus efeitos e se recuperar.