Descobrir que um servidor está com problema porque o cliente ligou reclamando é a pior forma de ficar sabendo. Monitoramento em tempo real existe justamente pra inverter essa ordem — você vê o disco enchendo ou a CPU disparando horas antes de virar um chamado de suporte. Este guia mostra como montar isso na prática com Prometheus e Grafana, incluindo uma peça que a maioria dos tutoriais esquece de mencionar.
Por que monitorar vale o esforço de configurar
Além do óbvio (saber quando algo vai quebrar antes que quebre), monitoramento contínuo ajuda a identificar tendências: um servidor que sobe 2% de uso de disco por semana vai estourar em quatro meses, e só dá pra prever isso com histórico. Também ajuda a justificar upgrade de hardware com dado concreto, em vez de “acho que está lento”.
As métricas que realmente importam no dia a dia
- CPU — não só o percentual total, mas o load average, que mostra quantos processos estão esperando processamento.
- Memória RAM — preste atenção especial na memória disponível real, não só a “livre” (o Linux usa RAM livre pra cache de disco, então “livre” sozinho engana).
- Disco e IOPS — espaço disponível é óbvio, mas velocidade de leitura/escrita costuma ser o gargalo real em bancos de dados.
- Latência de rede — principalmente entre servidores que trocam dados com frequência (aplicação e banco, por exemplo).
Qual ferramenta escolher
Prometheus + Grafana é o padrão de fato hoje em dia, principalmente em ambientes com múltiplos servidores ou containers — o Prometheus coleta e armazena as métricas, o Grafana só visualiza (não confunda os dois papéis). Zabbix é uma alternativa tudo-em-um mais tradicional, boa quando você quer uma ferramenta só cuidando de coleta, alerta e visualização sem integrar peças diferentes. Netdata é a opção mais rápida de colocar no ar quando você só quer ver “o que está acontecendo agora” num único servidor, sem se preocupar com histórico de longo prazo.
A peça que falta na maioria dos tutoriais: o node_exporter
Instalar só o Prometheus não gera métrica nenhuma de CPU, memória ou disco do servidor — ele precisa de um “exportador” rodando na máquina que você quer monitorar. Para métricas de sistema operacional, isso é o node_exporter. Sem ele, o Prometheus fica de mãos vazias.
- Baixe e extraia o node_exporter em cada servidor que será monitorado:
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-linux-amd64.tar.gz
tar xvfz node_exporter-linux-amd64.tar.gz
cd node_exporter-linux-amd64
./node_exporter
Por padrão ele expõe as métricas na porta 9100. - No servidor central, instale o Prometheus:
wget https://github.com/prometheus/prometheus/releases/latest/download/prometheus-linux-amd64.tar.gz
tar xvfz prometheus-linux-amd64.tar.gz
cd prometheus-linux-amd64 - Edite o
prometheus.ymle adicione o servidor monitorado como alvo (target):scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['192.168.1.50:9100'] - Inicie o Prometheus:
./prometheus --config.file=prometheus.yml
- Instale o Grafana no mesmo servidor central ou em outro:
sudo apt-get install -y grafana
sudo systemctl enable grafana-server
sudo systemctl start grafana-server - No Grafana, adicione o Prometheus como fonte de dados (Data Source) apontando pro endereço onde ele está rodando, e importe o dashboard pronto de ID 1860 (“Node Exporter Full”) direto da galeria oficial do Grafana — ele já vem com todos os gráficos de CPU, memória, disco e rede prontos, sem precisar montar do zero.
Configurando alertas de verdade
Métrica sem alerta é só um gráfico bonito que ninguém olha até dar problema. Configure o Alertmanager (que acompanha o Prometheus) pra disparar notificação quando, por exemplo, o uso de disco passar de 85% ou a CPU ficar acima de 90% por mais de 5 minutos seguidos — esse detalhe do “por X minutos seguidos” evita alerta falso de pico momentâneo que se resolve sozinho.
Problemas comuns
O Grafana não mostra nenhum dado do Prometheus
Confira primeiro se a Data Source está configurada com o endereço certo — se o Grafana roda em Docker, “localhost” não funciona pra apontar pro Prometheus rodando fora do container; use o IP real da máquina ou o nome do serviço na rede Docker.
O painel do node_exporter aparece vazio mesmo com tudo instalado
Quase sempre é firewall bloqueando a porta 9100 entre o servidor monitorado e o Prometheus. Teste com curl http://IP_DO_SERVIDOR:9100/metrics a partir do servidor onde o Prometheus roda — se não retornar nada, o problema é rede, não configuração.
Alertas demais, a maioria sem necessidade real
Geralmente é threshold mal calibrado copiado de algum tutorial genérico. Ajuste os limites com base no comportamento normal do seu próprio servidor ao longo de pelo menos uma semana antes de definir os alertas definitivos.
Perguntas frequentes
Prometheus e Grafana são gratuitos?
Sim, ambos são open source e gratuitos nas versões que rodam localmente. Existem versões cloud pagas, mas não são necessárias pra monitorar seus próprios servidores.
Preciso de um servidor separado só pro Prometheus?
Não obrigatoriamente, mas é recomendado em ambientes com vários servidores — assim o monitoramento continua funcionando mesmo se um dos servidores monitorados cair.
Dá pra monitorar servidores Windows também?
Sim, existe o equivalente ao node_exporter para Windows, chamado windows_exporter, que expõe as mesmas métricas de sistema pro Prometheus.
Quanto tempo de histórico o Prometheus guarda por padrão?
15 dias por padrão, configurável via a flag --storage.tsdb.retention.time. Para históricos mais longos, é comum integrar com soluções de armazenamento remoto.
Vale a pena rodar o Prometheus dentro de um container Docker?
Sim, é uma prática comum e facilita bastante a atualização de versão. Só preste atenção em montar um volume persistente pro diretório de dados — sem isso, você perde todo o histórico coletado a cada vez que o container for recriado.
Depois de montar o monitoramento, vale revisar outros pontos da infraestrutura: confira como configurar um servidor DNS com BIND9 e como montar um servidor de mídia (NAS) na mesma rede monitorada.
