Aula 27: Monitoramento com Linux — Prometheus, Grafana e Netdata

O Monitoramento com Linux é uma das disciplinas mais críticas para administradores de sistemas, engenheiros de infraestrutura e profissionais de segurança da informação. Nesta aula avançada do curso Linux — Do Zero ao Avançado, você vai aprender a implementar uma stack completa de observabilidade em servidores Linux, integrando três ferramentas essenciais: Prometheus, Grafana e Netdata. O objetivo é que, ao final desta aula, você tenha um ambiente de monitoramento funcional, capaz de coletar métricas em tempo real, armazená-las de forma eficiente e apresentá-las em dashboards profissionais. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente esse exato conjunto de ferramentas para garantir a disponibilidade e o desempenho de servidores em produção.

O monitoramento com Linux deixou de ser um luxo opcional e passou a ser requisito obrigatório em qualquer ambiente que preze pela confiabilidade. Quando um servidor apresenta lentidão, esgotamento de memória, saturação de disco ou picos anormais de CPU, você precisa identificar a causa raiz rapidamente — e isso só é possível com dados históricos e alertas bem configurados. Sem monitoramento, você está operando às cegas, reagindo a incidentes em vez de preveni-los. Nesta aula, vamos eliminar essa lacuna no seu conhecimento, partindo da teoria fundamental até a implementação prática completa.

Para acompanhar esta aula, você precisa ter concluído as aulas anteriores do curso, especialmente aquelas relacionadas a gerenciamento de serviços com systemd, firewall com iptables/firewalld, usuários e permissões e configuração de rede no Linux. Também será necessário ter acesso a pelo menos uma máquina física ou virtual rodando Ubuntu 20.04/22.04 ou Debian 11/12, e outra rodando CentOS 7/8, Rocky Linux 8/9 ou RHEL 8/9. O ideal é ter pelo menos 2 GB de RAM e 2 vCPUs disponíveis para que todos os serviços coexistam sem gargalos. Você também precisará de privilégios de root ou acesso via sudo em todas as máquinas envolvidas.

Ao final desta aula, você será capaz de instalar e configurar o Prometheus para coletar métricas de servidores Linux através do Node Exporter, configurar regras de alerta, integrar o Grafana para visualizar esses dados em dashboards interativos, e instalar o Netdata para obter monitoramento instantâneo com detecção de anomalias baseada em machine learning. Você também aprenderá a evitar os erros mais comuns, como portas bloqueadas no firewall, configurações incorretas de systemd e problemas de permissão que impedem a coleta de métricas.

É importante destacar que, embora cada ferramenta possa ser usada isoladamente, o verdadeiro poder emerge da integração. O Prometheus é o cérebro que coleta e armazena; o Grafana é a interface que transforma números em insight visual; e o Netdata é o recurso de observação em tempo real que complementa o modelo de coleta periódica. Juntos, eles formam uma solução completa de monitoramento com Linux que atende desde pequenos laboratórios domésticos até ambientes corporativos com centenas de nós.

O que você vai aprender nesta aula

• Compreender os fundamentos teóricos de monitoramento com Linux: métricas, séries temporais, alertas e dashboards
• Instalar e configurar o Prometheus em Ubuntu/Debian e CentOS/RHEL/Rocky Linux
• Configurar o Node Exporter para expor métricas de CPU, memória, disco e rede
• Escrever regras de alerta no Prometheus para notificar sobre condições críticas
• Instalar e configurar o Grafana, conectando-o ao Prometheus como fonte de dados
• Importar dashboards prontos e criar visualizações personalizadas
• Instalar o Netdata para monitoramento em tempo real com detecção de anomalias
• Verificar a comunicação entre todos os componentes e interpretar as saídas esperadas
• Diagnosticar e corrigir os erros mais comuns em stacks de monitoramento
• Aplicar boas práticas de segurança, performance e organização em ambientes de produção

Pré-requisitos e Ambiente

Antes de iniciar a parte prática, é essencial garantir que seu ambiente esteja adequadamente preparado. O monitoramento com Linux exige que as máquinas tenham relógio sincronizado, portas liberadas no firewall e serviços de timekeeping ativos. Se os horários das máquinas estiverem divergentes, o Prometheus poderá interpretar incorretamente os timestamps das métricas, gerando gráficos inconsistentes e alertas falsos. Recomendamos fortemente o uso de NTP ou chrony para sincronização de horário em todas as máquinas monitoradas e no servidor central.

Para este laboratório, considere a seguinte topologia: um servidor principal chamado monitor-server (onde rodarão Prometheus, Grafana e Netdata) e um ou mais servidores chamados app-server (onde rodará o Node Exporter para expor métricas). No Ubuntu/Debian, utilizaremos o gerenciador de pacotes apt e, no CentOS/RHEL/Rocky, o dnf. Para garantir que todos os comandos sejam reprodutíveis, você pode usar qualquer uma das distribuições mencionadas, e indicarei as diferenças de sintaxe quando necessário. Em nossos laboratórios na JRT Technology Solutions, padronizamos topologias semelhantes para treinamentos internos e implementações de clientes.

Os pré-requisitos de software incluem: curl ou wget (para download dos binários), tar (para extrair pacotes), systemd (para gerenciar serviços), firewalld ou ufw (para liberar portas), e um editor de texto como vim ou nano. Além disso, é recomendável que você tenha familiaridade com os conceitos básicos de TCP/IP, pois as ferramentas de monitoramento dependem de comunicação HTTP sobre portas específicas: 9090 (Prometheus), 3000 (Grafana), 9100 (Node Exporter) e 19999 (Netdata). Verifique também se nenhuma dessas portas já está em uso com o comando ss -tlpn.

A tabela abaixo resume as portas e os serviços que vamos configurar, e será sua referência rápida durante toda a aula:

Fundamentos de Monitoramento com Linux — Métricas, Séries Temporais e Alertas

Antes de executar qualquer comando, você precisa entender o que está sendo monitorado e por quê. No contexto do monitoramento com Linux, uma métrica é qualquer valor numérico que descreve o estado de um recurso em um dado momento, como cpu_usage, memory_available, disk_io_time ou network_receive_bytes. Cada métrica carrega um timestamp (o instante em que foi coletada) e um conjunto de labels (pares chave-valor que identificam o contexto, como instance=”192.168.1.10:9100″ ou job=”node”). O conjunto de uma métrica, seus labels e o timestamp forma uma série temporal, que é a unidade fundamental de armazenamento no Prometheus.

O Prometheus adota um modelo de coleta pull, ou seja, ele periodicamente faz requisições HTTP para endpoints que expõem métricas — isso é diferente do modelo push, onde o agente envia dados para o servidor. Essa escolha arquitetural oferece vantagens como: descoberta automática de falhas (se o endpoint não responder, o Prometheus sabe que o host está inativo), configuração centralizada e controle da frequência de coleta. O Node Exporter é o agente que expõe as métricas do sistema operacional em um endpoint HTTP, e o Prometheus as consome. A periodicidade de coleta é definida pela opção scrape_interval no arquivo de configuração, tipicamente entre 10 e 60 segundos.

As séries temporais são armazenadas em um banco de dados otimizado para leituras e escritas sequenciais, chamado TSDB (Time Series Database). O Prometheus possui seu próprio TSDB integrado, que armazena os dados em blocos de duas horas no diretório /var/lib/prometheus, por padrão. A retenção dos dados é configurável através da flag –storage.tsdb.retention.time, que por padrão é de 15 dias. Em ambientes de produção, recomendamos avaliar cuidadosamente esse período para equilibrar o consumo de disco e a necessidade histórica. Na JRT Technology Solutions, implementamos retenção diferenciada por cliente, considerando requisitos de compliance e capacidade de armazenamento.

Um dos conceitos mais importantes em monitoramento com Linux é o de alertas. Alertas são regras que disparam quando uma métrica ultrapassa um limiar pré-definido, como CPU acima de 90% por 5 minutos ou disco com menos de 10% de espaço livre. O Prometheus possui um motor de regras integrado que avalia expressões escritas em PromQL (Prometheus Query Language) e gera alertas quando a condição se torna verdadeira. Esses alertas são então enviados para um componente opcional chamado Alertmanager, que faz a roteamento, deduplicação e notificação por e-mail, Slack, PagerDuty, etc. Nesta aula, focaremos nas regras de alerta e deixaremos o Alertmanager para uma aula futura, pois ele merece atenção especial.

Por fim, é crucial entender a diferença entre monitoramento de caixa preta e caixa branca. A caixa branca (como faz o Node Exporter) expõe métricas internas do sistema operacional, enquanto a caixa preta testa o comportamento externo por meio de probes, como verificar se uma URL responde com código HTTP 200. O Prometheus pode fazer ambos, mas nesta aula focaremos no monitoramento de caixa branca, que é a base para qualquer operação de infraestrutura. Com esses fundamentos claros, estamos prontos para iniciar a instalação prática.

Arquitetura do Prometheus — Modelo Pull e Componentes Principais

A arquitetura do Prometheus é composta por quatro componentes principais: o servidor Prometheus (responsável pela coleta e armazenamento), os exporters (que expõem métricas), o motor de regras e alertas (que avalia condições e gera notificações) e a interface web (que permite consultas e visualização básica). O servidor Prometheus é um binário único que integra todas essas funções, o que simplifica a instalação e reduz a superfície de manutenção. Os exporters são programas separados, como o Node Exporter, que coletam métricas locais e as expõem em formato texto no endpoint /metrics.

O fluxo de dados no monitoramento com Linux utilizando Prometheus funciona assim: o servidor central faz uma requisição HTTP a cada scrape_interval (por exemplo, a cada 15 segundos) para cada endpoint configurado no arquivo prometheus.yml. O exporter responde com uma lista de métricas em formato texto simples, uma por linha, com o nome da métrica, os labels e o valor. O Prometheus então armazena esses dados em seu TSDB, associando o timestamp da coleta. Quando você consulta os dados, utiliza a linguagem PromQL, que permite filtrar, agregar e transformar as séries temporais de maneiras poderosas, como rate(), avg_over_time(), sum by(), entre outras funções.

Um conceito essencial para a configuração é o de jobs e targets. Um job é um conjunto lógico de alvos que compartilham a mesma finalidade, como node (para os Node Exporters), prometheus (para o próprio Prometheus) e grafana (se você quiser monitorar o Grafana). Cada target é um endpoint específico definido por seu endereço IP e porta. Na configuração do Prometheus, você define quais jobs e targets devem ser consultados, além de opções como o intervalo de coleta, o timeout e os labels adicionais. Essa flexibilidade permite escalar o monitoramento para milhares de máquinas sem alterar a lógica central.

O próprio Prometheus expõe suas métricas internas no endpoint /metrics da porta 9090, o que permite que ele se monitore. Isso é extremamente útil para diagnosticar problemas de performance do próprio sistema de monitoramento, como taxas de ingestão, uso de memória e latência de coleta. Na interface web do Prometheus, disponível em http://IP:9090, você pode consultar essas métricas, visualizar o status dos targets, executar consultas PromQL e até verificar a configuração atual. A interface nativa é funcional, mas limitada para visualização avançada — é aí que entra o Grafana, que veremos mais adiante.

Para finalizar a parte teórica, é importante mencionar o modelo de dados multidimensional do Prometheus. Cada métrica pode ter múltiplos labels, e o sistema é otimizado para consultas que combinam filtros por labels. Por exemplo, a métrica node_cpu_seconds_total{cpu=”0″,mode=”idle”} representa os segundos de CPU idle acumulados no core 0. Através de funções como rate(), você pode calcular a taxa de variação e, com isso, determinar a porcentagem de uso de CPU em um período. Essa riqueza de dados é o que torna o Prometheus tão poderoso para análise de desempenho e diagnóstico de incidentes em ambientes Linux.

Passo a Passo — Instalação do Prometheus no Ubuntu/Debian e CentOS/RHEL

Vamos iniciar a parte prática instalando o Prometheus. Diferentemente de muitos pacotes disponíveis nos repositórios oficiais, o Prometheus geralmente é instalado a partir dos binários pré-compilados disponibilizados no site oficial prometheus.io. Isso garante que você tenha a versão mais recente e com suporte adequado. Nesta aula, usaremos o método de instalação via tarball, que é idêntico para todas as distribuições Linux, pois o binário é estático e não depende de bibliotecas específicas. Esse método também facilita o entendimento completo de onde cada arquivo é colocado, algo que os pacotes .deb e .rpm mascaram.

O procedimento será dividido em etapas claras e ordenadas. Primeiro, você vai baixar o binário compactado, extraí-lo, criar os diretórios de dados e configuração, criar o usuário dedicado para o serviço, copiar os binários para os diretórios corretos, criar o arquivo de configuração, criar o unit file do systemd, habilitar e iniciar o serviço, e por fim liberar a porta no firewall. Cada etapa será detalhada com os comandos exatos para que não haja gaps. Vamos começar com o download do binário, usando a versão estável mais recente na data desta aula (agosto de 2026).

O primeiro passo é acessar o site oficial e identificar a versão mais recente. Para fins didáticos, usaremos a versão 2.53.1 (uma versão estável amplamente testada). Você pode verificar a versão mais atual com o comando curl -s https://api.github.com/repos/prometheus/prometheus/releases/latest | grep tag_name. O download será feito com wget ou curl, e o arquivo será extraído com tar -xzf. Vamos executar todos os passos para ambas as famílias de distribuição, mas como os comandos de download e extração são idênticos, farei uma única sequência e indicarei as diferenças quando chegarmos ao firewall e ao gerenciamento de serviços.

Execute os comandos abaixo como usuário root (ou anteceda cada um com sudo):

# Passo 1: Atualizar o sistema e instalar dependencias basicas
# Ubuntu/Debian
apt update -y && apt upgrade -y
apt install -y wget tar curl

# CentOS/RHEL/Rocky
dnf update -y
dnf install -y wget tar curl

# Passo 2: Baixar o binario do Prometheus (versao 2.53.1)
cd /opt
wget https://github.com/prometheus/prometheus/releases/download/v2.53.1/prometheus-2.53.1.linux-amd64.tar.gz

# Passo 3: Extrair o arquivo compactado
tar -xzf prometheus-2.53.1.linux-amd64.tar.gz

# Passo 4: Renomear o diretorio extraido para um nome mais limpo
mv prometheus-2.53.1.linux-amd64 prometheus

# Passo 5: Criar o diretorio de dados e o diretorio de configuracao
mkdir -p /var/lib/prometheus/data
mkdir -p /etc/prometheus

# Passo 6: Criar o usuario dedicado para o servico (sem home e sem login)
useradd --no-create-home --shell /bin/false prometheus

# Passo 7: Copiar os binarios para o diretorio /usr/local/bin
cp /opt/prometheus/prometheus /usr/local/bin/
cp /opt/prometheus/promtool /usr/local/bin/

# Passo 8: Copiar os diretorios de consoles e alertas
cp -r /opt/prometheus/consoles /etc/prometheus/
cp -r /opt/prometheus/console_libraries /etc/prometheus/

# Passo 9: Ajustar as permissoes dos diretorios para o usuario prometheus
chown -R prometheus:prometheus /var/lib/prometheus
chown -R prometheus:prometheus /etc/prometheus
chown prometheus:prometheus /usr/local/bin/prometheus
chown prometheus:prometheus /usr/local/bin/promtool

# Passo 10: Remover o arquivo compactado para economizar espaco
rm -f /opt/prometheus-2.53.1.linux-amd64.tar.gz

Explicação linha por linha: os comandos apt update e dnf update sincronizam os repositórios de pacotes e aplicam atualizações de segurança. Em seguida, instalamos wget (para download), tar (para extração) e curl (para testes HTTP). O comando cd /opt move a sessão para o diretório padrão de instalação de software adicional. O wget baixa o binário diretamente do GitHub. O comando tar -xzf extrai o arquivo .tar.gz — a flag -x extrai, -z descomprime gzip e -f especifica o arquivo. O mv renomeia o diretório extraído para simplificar os próximos passos. Os comandos mkdir -p criam as pastas necessárias, com a flag -p garantindo que diretórios pai sejam criados sem erro. O useradd cria o usuário prometheus com shell /bin/false para impedir login. Os comandos cp copiam os binários para o PATH do sistema. O cp -r copia diretórios recursivamente. O chown -R altera recursivamente o proprietário dos diretórios para o usuário prometheus, garantindo que o serviço possa ler e escrever nos locais corretos.

Após executar esses comandos, a saída esperada no terminal será silenciosa, indicando sucesso. No entanto, você pode verificar se os binários foram instalados corretamente com o comando prometheus –version e promtool –version. A saída esperada deve mostrar algo semelhante a isto:

prometheus, version 2.53.1 (branch: HEAD, revision: 0b6d5cfc1bdc2d49c48b2cbb615d8a92e824dfa3)
  build user:       root@xyz
  build date:       20240905-12:33:45
  go version:       go1.22.5
  platform:         linux/amd64

O comando prometheus –version exibe a versão compilada, a revisão do código, a data de build, a versão do Go e a plataforma. Isso confirma que o binário está funcional e no PATH. É importante verificar também se o diretório /var/lib/prometheus e /etc/prometheus estão com os proprietários corretos, usando o comando ls -ld. Se você pulou algum passo de chown, o serviço falhará ao iniciar com um erro de permissão — isso será abordado na seção de erros comuns.

Configuração Detalhada do Prometheus — Arquivo prometheus.yml Completo

O coração do Monitoramento com Linux usando Prometheus é o arquivo de configuração prometheus.yml. Este arquivo define como o Prometheus se comporta: quais endpoints ele consulta, com que frequência, quais regras de alerta estão ativas e quais parâmetros globais se aplicam. A configuração é escrita em formato YAML (YAML Ain’t Markup Language), que é sensível à indentação — espaços, não tabs. Vamos criar um arquivo completo, totalmente comentado, que servirá como base para sua implementação. Na maioria dos cenários, você pode usar este arquivo como ponto de partida e adaptá-lo conforme sua infraestrutura cresce.

A estrutura do arquivo possui seções principais: global (parâmetros globais), alerting (configuração de Alertmanager), rule_files (arquivos de regras de alerta e gravação) e scrape_configs (jobs e targets de coleta). Na seção global, definimos scrape_interval (intervalo de coleta, por exemplo, 15 segundos), evaluation_interval (intervalo de avaliação de regras, por exemplo, 15 segundos) e parâmetros de timeout. Na seção scrape_configs, cada job tem um nome, uma lista de targets estáticos e labels adicionais opcionais. Vamos configurar três jobs: prometheus (o próprio servidor), node (os Node Exporters) e grafana (se você quiser monitorar o Grafana também).

O arquivo completo ficará da seguinte forma:

# /etc/prometheus/prometheus.yml
# Arquivo de configuracao principal do Prometheus

global:
  scrape_interval:     15s   # Coleta métricas a cada 15 segundos
  evaluation_interval: 15s   # Avalia regras de alerta a cada 15 segundos
  external_labels:
    monitor: 'linux-monitor'

# Configuracao do Alertmanager (sera abordado em aula futura)
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Arquivos de regras de alerta e gravacao
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# Configuracoes de coleta (scrape)
scrape_configs:
  # Job para o proprio Prometheus
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

  # Job para os Node Exporters (metricas dos servidores Linux)
  - job_name: 'node'
    static_configs:
    - targets:
      - 'localhost:9100'
      - '192.168.1.10:9100'
      - '192.168.1.11:9100'
      labels:
        environment: 'production'

  # Job para o Grafana (opcional, se o endpoint /metrics estiver habilitado)
  - job_name: 'grafana'
    static_configs:
    - targets: ['localhost:3000']

Explicação detalhada: global.scrape_interval: 15s define que o Prometheus coletará métricas a cada 15 segundos de cada target. global.evaluation_interval: 15s define a frequência de avaliação das regras de alerta. external_labels.monitor: ‘linux-monitor’ adiciona um label global a todas as métricas coletadas, facilitando a identificação do cluster. A seção alerting está comentada porque o Alertmanager ainda não foi configurado — deixamos o exemplo do endpoint para referência futura. A seção rule_files também está com entradas comentadas, pois criaremos regras na próxima etapa. Em scrape_configs, cada item inicia com job_name, que é um identificador único do job. Dentro de static_configs, a chave targets lista os endpoints no formato IP:porta. No job node, adicionamos o label environment: ‘production’ para que essa informação fique disponível em todas as consultas, permitindo filtros por ambiente.

Para validar a sintaxe do arquivo antes de reiniciar o serviço, utilize o comando promtool check config /etc/prometheus/prometheus.yml. Se o arquivo estiver correto, a saída esperada será semelhante a:

Checking /etc/prometheus/prometheus.yml
  SUCCESS: 1 rule files found
  SUCCESS: /etc/prometheus/prometheus.yml is valid prometheus config file syntax

O comando promtool check config é indispensável para evitar derrubar o serviço por um erro de indentação ou sintaxe. Ele analisa o arquivo e reporta exatamente a linha problemática se algo estiver errado. Em nosso dia a dia na JRT Technology Solutions, incorporamos essa validação no pipeline de deploy para garantir que nenhuma configuração inválida entre em produção.

Instalação e Configuração do Node Exporter — Métricas de Host no Linux

O Node Exporter é o componente que expõe métricas do sistema operacional Linux para serem coletadas pelo Prometheus. Ele converte dados de /proc, /sys e outras fontes do kernel em um formato compreensível pelo Prometheus. Sem o Node Exporter, o Prometheus não tem como acessar informações como uso de CPU, memória livre, espaço em disco, I/O de disco, tráfego de rede, entre outras. O Node Exporter deve ser instalado em cada servidor Linux que você deseja monitorar, e é um serviço leve, consumindo pouquíssimos recursos (geralmente menos de 30 MB de RAM).

O processo de instalação do Node Exporter é semelhante ao do Prometheus: baixar o binário, extrair, copiar para o diretório de binários, criar usuário e configurar o serviço via systemd. A grande vantagem é que ele não requer um arquivo de configuração complexo — basta iniciá-lo e ele expõe as métricas em http://IP:9100/metrics. No entanto, você pode personalizar alguns parâmetros via flags, como –collector.disable-defaults e –collector.filesystem.ignored-mount-points, que permitem desabilitar coletores desnecessários em ambientes com restrições de performance.

Siga os comandos abaixo para instalar o Node Exporter no Ubuntu/Debian e CentOS/RHEL (os passos são idênticos):

# Passo 1: Baixar o binario do Node Exporter (versao 1.8.2)
cd /opt
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz

# Passo 2: Extrair o arquivo
tar -xzf node_exporter-1.8.2.linux-amd64.tar.gz

# Passo 3: Renomear o diretorio
mv node_exporter-1.8.2.linux-amd64 node_exporter

# Passo 4: Copiar o binario para /usr/local/bin
cp /opt/node_exporter/node_exporter /usr/local/bin/

# Passo 5: Criar o usuario dedicado
useradd --no-create-home --shell /bin/false node_exporter

# Passo 6: Ajustar a propriedade do binario
chown node_exporter:node_exporter /usr/local/bin/node_exporter

# Passo 7: Remover o arquivo compactado
rm -f /opt/node_exporter-1.8.2.linux-amd64.tar.gz

Agora, vamos criar o arquivo de serviço do systemd para gerenciar o Node Exporter como um daemon. O arquivo deve ser criado em /etc/systemd/system/node_exporter.service e conter as seguintes diretivas:

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Prometheus Node Exporter
Documentation=https://prometheus.io/docs/guides/node-exporter/
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter \
  --collector.disable-defaults \
  --collector.cpu \
  --collector.meminfo \
  --collector.filesystem \
  --collector.netdev \
  --collector.diskstats \
  --collector.uname \
  --collector.loadavg

[Install]
WantedBy=multi-user.target

O ExecStart contém o caminho do binário e várias flags. A flag –collector.disable-defaults desativa todos os coletores padrão, permitindo que você habilite apenas os que realmente precisa. As flags seguintes habilitam coletores específicos: –collector.cpu (métricas de CPU), –collector.meminfo (informações de memória), –collector.filesystem (espaço em disco), –collector.netdev (estatísticas de interface de rede), –collector.diskstats (I/O de disco), –collector.uname (informações do kernel) e –collector.loadavg (carga média do sistema). A opção Wants=network-online.target garante que o serviço só inicie após a rede estar disponível, o que é crítico para a exposição das métricas.

Após criar o arquivo, execute os comandos para habilitar e iniciar o serviço:

# Recarregar o systemd para reconhecer o novo servico
systemctl daemon-reload

# Habilitar o servico para iniciar no boot
systemctl enable node_exporter

# Iniciar o servico imediatamente
systemctl start node_exporter

# Verificar o status
systemctl status node_exporter

A saída esperada do systemctl status deve mostrar o serviço active (running):

● node_exporter.service - Prometheus Node Exporter
     Loaded: loaded (/etc/systemd/system/node_exporter.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2026-08-31 10:15:22 UTC; 12s ago
       Docs: https://prometheus.io/docs/guides/node-exporter/
   Main PID: 2345 (node_exporter)
      Tasks: 5 (limit: 2314)
     Memory: 6.2M
        CPU: 87ms
     CGroup: /system.slice/node_exporter.service
             └─2345 /usr/local/bin/node_exporter --collector.disable-defaults --collector.cpu --collector.meminfo --collector.filesystem --collector.netdev --collector.diskstats --collector.uname --collector.loadavg

A saída confirma que o serviço está active (running), ou seja, o Node Exporter está em execução. Note que o Main PID: 2345 identifica o processo do daemon, e a linha Memory: 6.2M demonstra o baixo consumo. A presença da linha CGroup com o comando completo confirma que o systemd está executando exatamente o binário com as flags que configuramos. Se o status mostrasse failed ou inactive, você precisaria verificar os logs com journalctl -u node_exporter -f para diagnosticar o problema.

Configuração do Prometheus para Coletar Métricas do Node Exporter e Regras de Alerta

Com o Node Exporter em execução, o próximo passo é garantir que o Prometheus o colete. Já configuramos o job node no arquivo prometheus.yml com o target localhost:9100, mas é importante testar manualmente se o endpoint está acessível antes de confiar na configuração. Utilize o comando curl http://localhost:9100/metrics e observe a saída — você verá centenas de linhas com nomes de métricas e valores. Cada linha segue o formato nome_da_metrica{label1=”valor1″,label2=”valor2″} valor. Se o curl retornar erro de conexão, o problema provavelmente está no firewall ou no próprio serviço.

Vamos também criar um arquivo de regras de alerta para que o Prometheus notifique quando algo estiver errado. Essas regras usam PromQL e definem condições com a sintaxe expr, for (duração mínima para o alerta disparar), labels e annotations. O for evita que pequenas flutuações disparem alertas espúrios. Por exemplo, for: 5m significa que a condição deve permanecer verdadeira por 5 minutos consecutivos antes de o alerta ser gerado. Crie o arquivo /etc/prometheus/alerts.yml com o seguinte conteúdo:

# /etc/prometheus/alerts.yml
# Regras de alerta para monitoramento com Linux

groups:
- name: linux_alerts
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Alta utilizacao de CPU em {{ $labels.instance }}"
      description: "CPU acima de 90% por mais de 5 minutos."

  - alert: HighMemoryUsage
    expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Memoria quase esgotada em {{ $labels.instance }}"
      description: "Menos de 10% de memoria disponivel."

  - alert: DiskSpaceLow
    expr: 100 - ((node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100) > 85
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Espaco em disco baixo em {{ $labels.instance }}"
      description: "Mais de 85% do disco raiz utilizado."

  - alert: InstanceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instancia {{ $labels.instance }} indisponivel"
      description: "O target nao respondeu as coletas por mais de 1 minuto."

Cada regra é composta por alert (nome do alerta), expr (expressão PromQL), for (duração mínima), labels (classificação de severidade) e annotations (informações descritivas para o operador). As expressões usam funções como rate(), que calcula a taxa de variação por segundo ao longo de um intervalo, e avg by(instance), que agrega os resultados por instância. A métrica up é especial: ela retorna 1 se o target está acessível e 0 se a coleta falhou — perfeita para detectar indisponibilidade. O parâmetro for é essencial para reduzir o ruído de alertas transitórios.

Agora, edite o arquivo /etc/prometheus/prometheus.yml para incluir o arquivo de regras recém-criado. Na seção rule_files, descomente a linha e adicione o caminho /etc/prometheus/alerts.yml. Após editar, valide novamente com promtool check config /etc/prometheus/prometheus.yml e reinicie o serviço do Prometheus com systemctl restart prometheus. Lembre-se de que o Prometheus recarrega a configuração a cada reinício, e você pode usar o endpoint http://IP:9090/-/reload com uma solicitação POST para recarregar sem reiniciar o serviço.

Para finalizar esta etapa, crie também o unit file do systemd para o Prometheus. Este arquivo é essencial para gerenciar o serviço como daemon. O conteúdo será:

# /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Monitoring Server
Documentation=https://prometheus.io/docs/introduction/overview/
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus/data \
  --web.console.templates=/etc/prometheus/consoles \
  --web.console.libraries=/etc/prometheus/console_libraries \
  --web.listen-address=:9090 \
  --storage.tsdb.retention.time=15d \
  --web.enable-admin-api
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Este arquivo define que o serviço execute sob o usuário prometheus, com o binário localizado em /usr/local/bin/prometheus. As flags incluem: –config.file (caminho do arquivo de configuração), –storage.tsdb.path (diretório de dados), –web.console.templates e –web.console.libraries (para consoles legados), –web.listen-address=:9090 (porta de escuta), –storage.tsdb.retention.time=15d (retenção de 15 dias) e –web.enable-admin-api (habilita API administrativa, útil para snapshot e exclusão de séries). As diretivas Restart=always e RestartSec=10 garantem que o serviço reinicie automaticamente após falhas, com intervalo de 10 segundos entre tentativas.

Após salvar o arquivo, execute os comandos systemctl daemon-reload, systemctl enable prometheus e systemctl start prometheus. Verifique o status e, se estiver active (running), o Prometheus estará operacional. A partir deste ponto, você já pode acessar a interface web em http://IP_DO_SERVIDOR:9090 e ir até Status → Targets para confirmar que todos os endpoints estão UP. Este é um ponto crítico de verificação que abordaremos em detalhes na seção de verificação.

Passo a Passo — Instalação do Grafana e Conexão com Prometheus

O Grafana é a camada de visualização da nossa stack de monitoramento com Linux. Embora o Prometheus tenha uma interface web funcional, o Grafana oferece recursos muito mais sofisticados: dashboards interativos, painéis com múltiplos gráficos, variáveis dinâmicas, anotações, alertas visuais e integração com dezenas de fontes de dados. O Grafana pode ser instalado de duas maneiras: a partir dos repositórios oficiais (recomendado para produção, pois facilita atualizações) ou via download direto de um pacote .deb ou .rpm

Quer aprender na prática com especialistas?