Aula 23: Monitoramento e alertas — Grafana, Prometheus e logs de firewall

Nesta vigésima terceira aula do curso Firewall, fail2ban e CrowdSec — Do Zero ao Avançado, vamos mergulhar em um dos temas mais críticos para qualquer operação de segurança da informação: monitoramento e alertas. Até aqui, você aprendeu a configurar firewalls no Linux, a blindar serviços com fail2ban e a implantar o CrowdSec como uma camada colaborativa e inteligente de defesa. No entanto, nenhuma dessas ferramentas cumpre seu papel se você não conseguir observar o que está acontecendo em tempo real, identificar anomalias antes que virem incidentes e ser notificado imediatamente quando algo sair do padrão. É exatamente isso que vamos construir nesta aula usando Grafana, Prometheus e uma análise estruturada de logs de firewall.

O objetivo central é transformar dados brutos — métricas de sistema, contadores de bloqueios do fail2ban, decisões do CrowdSec, pacotes aceitos e rejeitados pelo firewall, mensagens de log — em um painel de observabilidade unificado. Com ele, você poderá visualizar a saúde do seu ambiente, cruzar informações entre as ferramentas de defesa e configurar alertas inteligentes que avisam sua equipe em canais como e-mail, Slack ou Telegram. Este é o passo que separa um servidor “configurado” de um servidor verdadeiramente operado e monitorado.

Ao final desta aula, você terá implementado uma stack completa de monitoramento: Prometheus para coleta e armazenamento de métricas, Node Exporter para expor métricas do sistema, Grafana para visualização e dashboards, Alertmanager para roteamento de alertas e integrações com logs via Promtail/Loki. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente essa mesma arquitetura para monitorar datacenters, ambientes de nuvem e servidores on-premise, e nesta aula você terá acesso ao passo a passo completo, sem atalhos ou lacunas.

É importante destacar que esta é uma aula de nível avançado. Você já deve dominar os conceitos de firewall (iptables/nftables/UFW), já configurou fail2ban e CrowdSec nas aulas anteriores e está familiarizado com a linha de comando Linux. Vamos trabalhar com dois grandes sistemas: Ubuntu/Debian e CentOS/RHEL/Rocky Linux. Todos os comandos serão mostrados na ordem exata de execução, com as saídas esperadas e os arquivos de configuração completos para que você possa seguir exatamente o que fazemos em campo na JRT Technology Solutions.

O que você vai aprender nesta aula

Antes de colocar a mão na massa, quero deixar claro o escopo técnico e prático desta aula. Monitoramento e alertas não é apenas “instalar um software e abrir um dashboard” — é construir um ecossistema de observabilidade onde cada componente tem um papel bem definido. Ao concluir este conteúdo, você será capaz de:

• Explicar a diferença entre métricas, logs e traces, e como cada um contribui para monitoramento e alertas de segurança.
• Instalar e configurar o Prometheus como servidor central de métricas no Ubuntu/Debian e no CentOS/RHEL/Rocky Linux.
• Implantar o Node Exporter para coletar métricas essenciais do host: CPU, memória, disco, rede e processos.
• Configurar o Alertmanager para transformar métricas em notificações proativas, com roteamento e silêncios.
• Instalar e configurar o Grafana, conectar o Prometheus como fonte de dados e criar dashboards do zero.
• Coletar e analisar logs de firewall, fail2ban e CrowdSec usando Promtail e Loki.
• Escrever regras de alerta com PromQL focadas em cenários reais de intrusão e anomalia.
• Verificar a instalação, testar o funcionamento de cada componente e resolver os erros mais comuns em ambientes de produção.

Pré-requisitos e Ambiente

Para acompanhar esta aula sem fricção, você precisa de um ambiente mínimo que atenda aos requisitos abaixo. Não pule esta seção: a stack de monitoramento e alertas consome recursos, e tentar instalar tudo em uma máquina com pouca memória pode gerar falhas que não são defeito do software, mas sim do ambiente. Em nossos projetos na JRT Technology Solutions, sempre dimensionamos o ambiente antes de iniciar qualquer implantação, e recomendamos que você faça o mesmo.

• 2 servidores Linux (ou 1 servidor e 1 VM com 2 GB de RAM e 1 vCPU). Um será o servidor de monitoramento, o outro o host monitorado — mas se você quiser seguir em uma única máquina, também funciona com adaptações.
• Ubuntu 22.04/24.04 ou Debian 12 em um host, e CentOS Stream 9, Rocky Linux 9 ou RHEL 9 no outro (para cobrir os dois mundos).
• Fail2ban instalado e configurado em pelo menos um dos hosts, com jails ativas para SSH e Nginx/Apache, conforme as aulas anteriores.
• CrowdSec instalado e configurado com o bouncer de firewall, com cscli funcional e métricas disponíveis via API local.
• UFW ou firewalld ativo, com regras de firewall aplicadas e logs sendo gerados (ex.: /var/log/ufw.log ou /var/log/firewalld).
• Acesso sudo (root) em todas as máquinas.
• Portas livres: 9090 (Prometheus), 9100 (Node Exporter), 9093 (Alertmanager), 3000 (Grafana), 3100 (Loki) — verifique se não há conflitos.
• Conhecimento intermediário de linha de comando, incluindo edição de arquivos com vim, nano ou vi.

A arquitetura que vamos montar é escalável e modular. O Prometheus coleta métricas expostas pelos exporters via HTTP (pull model). O Node Exporter expõe métricas do sistema operacional. O Alertmanager processa as regras de alerta definidas no Prometheus e as encaminha para os canais configurados. O Promtail lê logs dos arquivos em disco e os envia ao Loki, que armazena e permite consultas via Grafana. Por fim, o Grafana unifica tudo em dashboards interativos. Vamos construir cada peça com calma e na ordem correta.

Fundamentos de Monitoramento e alertas — métricas, logs e o modelo pull

Antes de instalar qualquer pacote, você precisa internalizar os conceitos que sustentam essa stack. Monitoramento e alertas em segurança da informação se baseiam em três pilares de observabilidade: métricas, logs e traces. Métricas são valores numéricos coletados ao longo do tempo — por exemplo, a quantidade de pacotes rejeitados pelo firewall nos últimos 5 minutos, o número de IPs banidos pelo fail2ban ou a contagem de decisões do CrowdSec. Logs são eventos textuais com timestamp, como uma linha do /var/log/auth.log registrando uma tentativa de login falha. Já os traces (que não serão o foco aqui) registram o caminho de uma requisição entre serviços. Nesta aula, trabalharemos com métricas e logs, que são suficientes para construir um sistema robusto de monitoramento e alertas para firewall, fail2ban e CrowdSec.

O Prometheus adota o modelo pull (puxar): ele periodicamente acessa endpoints HTTP que expõem métricas em um formato texto simples. Esse modelo é vantajoso porque o Prometheus descobre sozinho se o alvo está vivo e pode scrapar várias instâncias de forma centralizada — não depende de agents enviando dados ativamente. Já o Loki, que usaremos para logs, adota o modelo push (empurrar): o Promtail lê os arquivos de log e empurra as linhas para o Loki via HTTP. Entender essa diferença é fundamental para diagnosticar problemas de coleta e configurar corretamente cada componente.

Outro conceito central é o PromQL (Prometheus Query Language). É a linguagem que você usará para consultar métricas, aplicar funções como rate(), increase(), sum() e criar gráficos, tabelas e alertas. Por exemplo, a expressão rate(node_cpu_seconds_total{mode="idle"}[5m]) mostra a taxa de CPU ociosa nos últimos 5 minutos. Sem dominar o PromQL, você conseguirá instalar tudo, mas não conseguirá extrair valor real da stack. Vamos praticar com exemplos reais focados em firewall e segurança ao longo da aula.

Por fim, os alertas são o coração da operação proativa. No Prometheus, você define regras de alerta em arquivos YAML: uma condição PromQL, uma severidade, uma descrição e um rótulo de destino. Quando a condição se mantém verdadeira por um tempo definido (ex.: 1 minuto), o Prometheus envia o alerta ao Alertmanager. O Alertmanager, por sua vez, agrupa, deduplica e roteia os alertas para os canais configurados. Esse fluxo garante que sua equipe seja notificada quando, por exemplo, o fail2ban detectar uma rajada de tentativas de login ou quando o firewall começar a rejeitar um volume anormal de pacotes.

Instalação passo a passo — Prometheus, Node Exporter e Alertmanager no Ubuntu/Debian e CentOS/RHEL/Rocky

Agora começa a parte prática. Vamos instalar o Prometheus, o Node Exporter e o Alertmanager do zero, usando os binários oficiais do projeto — isso garante controle total sobre versões e caminhos. Mostraremos os comandos para Ubuntu/Debian e para CentOS/RHEL/Rocky Linux, pois há diferenças importantes no gerenciamento de pacotes e na forma de criar serviços systemd. Em nossos projetos na JRT Technology Solutions, padronizamos essa instalação via binários para evitar dependências de repositórios terceiros e permitir atualizações previsíveis.

Primeiro, no Ubuntu/Debian, prepare o sistema com as dependências mínimas e crie o usuário de serviço. Não execute nada como root permanente; o usuário prometheus será dono dos processos. Siga estes passos exatos:

1. Atualize os índices de pacotes e instale utilitários básicos: wget para download e tar para extração.
2. Crie o usuário de sistema prometheus sem shell interativo e sem diretório home, com o comando useradd.
3. Crie os diretórios padrão /etc/prometheus e /var/lib/prometheus, ajustando as permissões.
4. Baixe a versão estável mais recente do Prometheus (aqui usaremos a 2.53.0 LTS, mas ajuste o link se houver versão superior).
5. Extraia, mova os binários para /usr/local/bin e os arquivos de console para /etc/prometheus.
6. Crie o arquivo de serviço systemd, habilite e inicie o Prometheus.

Agora execute os comandos completos para Ubuntu/Debian:

# ---- Ubuntu/Debian: preparação e criação do usuário ----
sudo apt update
sudo apt install -y wget tar
sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus

# ---- Download e extração do Prometheus (ajuste a versão se necessário) ----
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar -xvf prometheus-2.53.0.linux-amd64.tar.gz

# ---- Instalação dos binários e arquivos de console ----
sudo cp /tmp/prometheus-2.53.0.linux-amd64/prometheus /usr/local/bin/
sudo cp /tmp/prometheus-2.53.0.linux-amd64/promtool /usr/local/bin/
sudo cp -r /tmp/prometheus-2.53.0.linux-amd64/consoles /etc/prometheus/
sudo cp -r /tmp/prometheus-2.53.0.linux-amd64/console_libraries /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus/consoles /etc/prometheus/console_libraries

O mesmo procedimento no CentOS/RHEL/Rocky usa dnf em vez de apt, e o useradd com as mesmas opções. Observe que no Rocky Linux o pacote wget já costuma estar instalado, mas confirmamos. Execute os comandos:

# ---- CentOS/RHEL/Rocky Linux: preparação e criação do usuário ----
sudo dnf install -y wget tar
sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus

# ---- Download e extração (as mesmas versões funcionam em ambos os sistemas) ----
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar -xvf prometheus-2.53.0.linux-amd64.tar.gz

# ---- Instalação dos binários e arquivos ----
sudo cp /tmp/prometheus-2.53.0.linux-amd64/prometheus /usr/local/bin/
sudo cp /tmp/prometheus-2.53.0.linux-amd64/promtool /usr/local/bin/
sudo cp -r /tmp/prometheus-2.53.0.linux-amd64/consoles /etc/prometheus/
sudo cp -r /tmp/prometheus-2.53.0.linux-amd64/console_libraries /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus/consoles /etc/prometheus/console_libraries

Agora vamos instalar o Node Exporter. Ele é o collector padrão que expõe métricas do sistema operacional: uso de CPU, memória, disco, rede, processos, e também métricas de ipvs, socket e filefd. O processo de instalação é semelhante. Para Ubuntu/Debian, siga:

# ---- Node Exporter no Ubuntu/Debian ----
cd /tmp
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -xvf node_exporter-1.8.2.linux-amd64.tar.gz
sudo cp /tmp/node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false node_exporter
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

Para CentOS/RHEL/Rocky, o comando é idêntico na parte de download e instalação, mudando apenas o gerenciador no primeiro passo, que já executamos:

# ---- Node Exporter no CentOS/RHEL/Rocky ----
cd /tmp
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -xvf node_exporter-1.8.2.linux-amd64.tar.gz
sudo cp /tmp/node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false node_exporter
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

Vamos também instalar o Alertmanager agora, pois ele fará parte do núcleo de monitoramento e alertas. O processo é o mesmo: baixar, extrair e copiar binários. Execute no Ubuntu/Debian:

# ---- Alertmanager no Ubuntu/Debian ----
cd /tmp
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar -xvf alertmanager-0.27.0.linux-amd64.tar.gz
sudo cp /tmp/alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/
sudo cp /tmp/alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/
sudo mkdir -p /etc/alertmanager /var/lib/alertmanager
sudo useradd --no-create-home --shell /bin/false alertmanager
sudo chown -R alertmanager:alertmanager /etc/alertmanager /var/lib/alertmanager

E no CentOS/RHEL/Rocky:

# ---- Alertmanager no CentOS/RHEL/Rocky ----
cd /tmp
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar -xvf alertmanager-0.27.0.linux-amd64.tar.gz
sudo cp /tmp/alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/
sudo cp /tmp/alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/
sudo mkdir -p /etc/alertmanager /var/lib/alertmanager
sudo useradd --no-create-home --shell /bin/false alertmanager
sudo chown -R alertmanager:alertmanager /etc/alertmanager /var/lib/alertmanager

Com os binários instalados, precisamos criar os arquivos de serviço systemd para que o Prometheus, o Node Exporter e o Alertmanager iniciem automaticamente no boot e sejam gerenciados de forma limpa. O conteúdo do arquivo de unidade é o mesmo para ambas as famílias de Linux, pois o systemd funciona de forma padronizada. Vamos criar primeiro o serviço do Prometheus:

# ---- Criar o serviço systemd do Prometheus (use sudo nano/vim) ----
sudo tee /etc/systemd/system/prometheus.service > /dev/null <<EOF
[Unit]
Description=Prometheus Monitoring System
Documentation=https://prometheus.io/docs/introduction/overview/
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/ \
  --web.console.templates=/etc/prometheus/consoles \
  --web.console.libraries=/etc/prometheus/console_libraries \
  --web.listen-address=0.0.0.0:9090 \
  --web.enable-lifecycle
Restart=always
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF

Nesse arquivo, a opção --web.enable-lifecycle permite recarregar a configuração via HTTP POST em /-/reload sem reiniciar o serviço — essencial em operação. O LimitNOFILE aumenta o limite de descritores de arquivo para evitar erros de “too many open files” em ambientes com muitos alvos. Agora crie o serviço do Node Exporter:

# ---- Criar o serviço systemd do Node Exporter ----
sudo tee /etc/systemd/system/node_exporter.service > /dev/null <<EOF
[Unit]
Description=Node Exporter
Documentation=https://prometheus.io/docs/guides/node-exporter/
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter \
  --collector.systemd \
  --collector.processes \
  --web.listen-address=0.0.0.0:9100
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

O coletor systemd expõe métricas do estado dos serviços, permitindo que você crie alertas como “serviço fail2ban parou”. O coletor processes fornece métricas de processos. Por fim, crie o serviço do Alertmanager:

# ---- Criar o serviço systemd do Alertmanager ----
sudo tee /etc/systemd/system/alertmanager.service > /dev/null <<EOF
[Unit]
Description=Prometheus Alertmanager
Documentation=https://prometheus.io/docs/alerting/latest/alertmanager/
After=network-online.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager \
  --config.file=/etc/alertmanager/alertmanager.yml \
  --storage.path=/var/lib/alertmanager/ \
  --web.listen-address=0.0.0.0:9093
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

Agora recarregue o systemd, habilite e inicie os três serviços. Este passo é idêntico nos dois sistemas:

sudo systemctl daemon-reload
sudo systemctl enable prometheus node_exporter alertmanager
sudo systemctl start prometheus node_exporter alertmanager
sudo systemctl status prometheus node_exporter alertmanager --no-pager

Se tudo correu bem, você verá saída semelhante a esta para o Prometheus (os outros dois mostrarão estrutura análoga, com active (running)):

● prometheus.service - Prometheus Monitoring System
     Loaded: loaded (/etc/systemd/system/prometheus.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-09-05 10:15:22 -03; 12s ago
   Main PID: 4321 (prometheus)
      Tasks: 8 (limit: 2316)
     Memory: 48.7M
        CPU: 98ms
     CGroup: /system.slice/prometheus.service
             └─4321 /usr/local/bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries --web.listen-address=0.0.0.0:9090 --web.enable-lifecycle

set 05 10:15:22 monitor01 systemd[1]: Started Prometheus Monitoring System.

O Prometheus ainda não tem uma configuração útil, pois ainda não criamos o arquivo prometheus.yml definitivo. Faremos isso na próxima seção, mas antes vamos instalar o Grafana. O processo de instalação do Grafana recomenda o uso do repositório oficial da Grafana Labs, pois traz atualizações mais frequentes e integridade verificada. Para Ubuntu/Debian, execute:

# ---- Grafana no Ubuntu/Debian ----
sudo apt-get install -y apt-transport-https software-properties-common wget
sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y grafana

# Iniciar e habilitar o Grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

Para CentOS/RHEL/Rocky, o repositório é adicionado via dnf:

# ---- Grafana no CentOS/RHEL/Rocky ----
sudo tee /etc/yum.repos.d/grafana.repo > /dev/null <<EOF
[grafana]
name=grafana
baseurl=https://rpm.grafana.com
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://rpm.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF
sudo dnf install -y grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

Após instalar, abra o navegador em http://SEU_IP:3000 e faça login com admin/admin. O Grafana solicitará a troca de senha no primeiro acesso. Mais adiante, vamos conectar o Prometheus como fonte de dados e construir dashboards. Agora que os serviços estão rodando, precisamos configurá-los adequadamente.

Configuração detalhada do Prometheus — arquivo prometheus.yml e integração com exporters

O arquivo /etc/prometheus/prometheus.yml é o coração do Prometheus. Ele define os alvos que serão raspados, a frequência de coleta, os caminhos dos arquivos de regras de alerta e as configurações de armazenamento. Vamos criar um arquivo completo, comentado linha por linha, que inclui o próprio Prometheus como alvo, o Node Exporter local e um host remoto (onde rodam fail2ban e CrowdSec). Em projetos na JRT Technology Solutions, sempre versionamos esse arquivo e o tratamos como código, pois erros de syntaxe aqui derrubam todo o serviço.

Use o editor de sua preferência para criar o arquivo, ou use o tee abaixo. O conteúdo é o mesmo para Ubuntu/Debian e CentOS/RHEL/Rocky. Observe que usamos IPs de exemplo (192.168.1.10 é o servidor de monitoramento e 192.168.1.20 é o host monitorado com fail2ban e CrowdSec). Substitua pelos IPs reais do seu ambiente:

# /etc/prometheus/prometheus.yml — Configuração principal do Prometheus
global:
  scrape_interval: 15s       # Intervalo padrão de coleta de métricas
  evaluation_interval: 15s   # Intervalo de avaliação das regras de alerta
  external_labels:
    datacenter: "sao-paulo"
    environment: "production"

# Carregar regras de alerta de todos os arquivos *.rules.yml
rule_files:
  - "/etc/prometheus/alert_rules/*.yml"

# Configuração do Alertmanager
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "192.168.1.10:9093"

# Alvos de coleta
scrape_configs:
  # O próprio Prometheus se monitora
  - job_name: "prometheus"
    static_configs:
      - targets: ["192.168.1.10:9090"]

  # Node Exporter local (métricas do host de monitoramento)
  - job_name: "node_local"
    static_configs:
      - targets: ["192.168.1.10:9100"]
        labels:
          instance: "monitor01"
          role: "monitoring"

  # Node Exporter do host monitorado (fail2ban e CrowdSec)
  - job_name: "node_managed"
    static_configs:
      - targets: ["192.168.1.20:9100"]
        labels:
          instance: "webserver01"
          role: "backend"

Depois de criar o arquivo, valide a syntaxe com o promtool antes de recarregar. A validação evita que o Prometheus entre em estado de erro e pare de coletar métricas. Execute:

sudo -u prometheus promtool check config /etc/prometheus/prometheus.yml

A saída esperada, se tudo estiver correto, é:

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

Em seguida, recarregue a configuração sem reiniciar o processo, graças à flag --web.enable-lifecycle que inserimos no serviço:

curl -X POST http://localhost:9090/-/reload

A resposta esperada é Lifecycle reloaded. Se você receber um erro 404, significa que a flag não foi habilitada no arquivo de serviço — revise o passo da criação do prometheus.service.

Configuração do Alertmanager para monitoramento e alertas — arquivo alertmanager.yml e regras de roteamento

O Alertmanager recebe os alertas do Prometheus e decide para onde enviá-los, com base em regras de roteamento, agrupamento e inibição. Nesta seção, vamos configurar um fluxo real de monitoramento e alertas: alertas de severidade critical vão para e-mail e Slack; alertas de severidade warning vão apenas para o e-mail; e todos os alertas serão agrupados por serviço para evitar spam. Você pode adaptar os canais conforme sua infraestrutura.

Crie o arquivo /etc/alertmanager/alertmanager.yml com o conteúdo completo abaixo. Vamos usar SMTP de exemplo (Gmail) e webhook do Slack. Em produção, recomendamos usar credenciais de aplicativo e canais dedicados:

# /etc/alertmanager/alertmanager.yml — Configuração do Alertmanager
global:
  resolve_timeout: 5m   # Tempo para considerar alerta resolvido após parar de disparar

  # Configurações de e-mail (SMTP)
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alerta@seudominio.com.br'
  smtp_auth_username: 'alerta@seudominio.com.br'
  smtp_auth_password: 'sua-senha-de-app'
  smtp_require_tls: true

  # Configurações do Slack via webhook (incoming webhook)
  slack_api_url: 'https://hooks.slack.com/services/TOKEN/SECRET/CHANNEL'

# Arquivo de rotas: define como os alertas são encaminhados
route:
  receiver: 'email-default'          # Receptor padrão
  group_by: ['alertname', 'cluster'] # Agrupar por alertname e cluster
  group_wait: 10s                    # Aguardar 10s para agrupar alertas
  group_interval: 5m                 # Intervalo mínimo entre envios de grupos
  repeat_interval: 12h               # Reenviar alerta se persistir após 12h

  # Rotas filhas baseadas em severidade
  routes:
    - matchers:
        - severity = "critical"
      receiver: 'slack-critical'
      group_wait: 5s
      repeat_interval: 1h
    - matchers:
        - severity = "warning"
      receiver: 'email-warning'
      repeat_interval: 4h

# Definição dos receptores
receivers:
  - name: 'email-default'
    email_configs:
      - to: 'equipe-so@seudominio.com.br'
        headers:
          Subject: '[Alerta] {{ .GroupLabels.alertname }}'
        html: '<h2>Alerta: {{ .GroupLabels.alertname }}</h2><p>{{ range .Alerts }}<div>{{ .Annotations.description }}</div>{{ end }}</p>'
  - name: 'slack-critical'
    slack_configs:
      - channel: '#alertas-seguranca'
        title: '[CRITICAL] {{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}'
        color: 'danger'
  - name: 'email-warning'
    email_configs:
      - to: 'equipe-so@seudominio.com.br'
        headers:
          Subject: '[Warning] {{ .GroupLabels.alertname }}'

# Regras de inibição: evita alertas redundantes
inhibit_rules:
  - source_matchers:
      - severity = 'critical'
    target_matchers:
      - severity = 'warning'
    equal: ['alertname', 'instance']

Valide a configuração do Alertmanager com amtool antes de aplicar. O comando de validação é:

sudo -u alertmanager amtool check-config /etc/alertmanager/alertmanager.yml

A saída esperada de sucesso é:

Checking '/etc/alertmanager/alertmanager.yml'  SUCCESS
Found 3 receivers
Found 1 inhibition rules

Recarregue o Alertmanager com:

sudo systemctl restart alertmanager && sudo systemctl status alertmanager --no-pager

A partir de agora, o Alertmanager está pronto para receber alertas do Prometheus. Mas ainda não definimos as regras de alerta em si. Faremos isso na seção seguinte, conectando métricas de firewall, fail2ban e CrowdSec.

Metricas de firewall, fail2ban e CrowdSec — exporters e integração com Prometheus

Um dos maiores desafios em monitoramento e alertas de segurança é obter métricas diretamente das ferramentas de defesa. O Node Exporter fornece métricas de sistema, mas precisamos de métricas específicas do firewall, do fail2ban e do CrowdSec. Para isso, vamos usar exporters dedicados: o fail2ban-exporter e o crowdsec-exporter. Além disso, podemos coletar métricas de firewall diretamente via contadores do iptables/nftables usando o iptables-exporter ou, mais praticamente, usar os logs para construir métricas com Loki.

Vamos instalar o fail2ban-exporter no host monitorado (Ubuntu/Debian). Este exporter lê o socket do fail2ban e expõe métricas como fail2ban_banned, fail2ban_jail_failed e fail2ban_failed_total por jail. No Ubuntu/Debian, instale via binário:

# ---- Instalar fail2ban-exporter no host monitorado (Ubuntu/Debian) ----
cd /tmp
wget https://github.com/ivosilva/fail2ban-exporter/releases/download/v0.10.0/fail2ban-exporter_0.10.0_linux_amd64.tar.gz
tar -xvf fail2ban-exporter_0.10.0_linux_amd64.tar.gz
sudo cp fail2ban-exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false fail2ban_exporter
sudo chown fail2ban_exporter:fail2ban_exporter /usr/local/bin/fail2ban-exporter

Crie o serviço systemd para o fail2ban-exporter:

sudo tee /etc/systemd/system/fail2ban-exporter.service > /dev/null <<EOF
[Unit]
Description=Fail2ban Exporter
Documentation=https://github.com/ivosilva/fail2ban-exporter
After=network.target fail2ban.service

[Service]
User=fail2ban_exporter
Group=fail2ban_exporter
Type=simple
ExecStart=/usr/local/bin/fail2ban-exporter \
  --web.listen-address=0.0.0.0:9191 \
  --collector.textfile.directory=/var/lib/fail2ban-exporter/
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable fail2ban-exporter
sudo systemctl start fail2ban-exporter
sudo systemctl status fail2ban-exporter --no-pager

Agora o CrowdSec. O CrowdSec já expõe métricas na API local (http://localhost:6060/metrics) quando a opção prometheus está habilitada. Verifique se a configuração do CrowdSec está correta no arquivo /etc/crowdsec/config.yaml. Procure a seção api.server.prometheus e certifique-se de que está habilitada:

# Trecho do /etc/crowdsec/config.yaml (não substitua o arquivo inteiro)
api:
  server:
    enable: true
    listen_uri: 127.0.0.1:6060
    prometheus:
      enabled: true
      listen: 127.0.0.1:6061

Se a seção não existir, adicione-a. Em seguida, reinicie o CrowdSec:

sudo systemctl restart crowdsec
curl -s http://127.0.0.1:6061/metrics | head -n 20

A saída esperada mostrará linhas como # HELP crowdsec_decisions_total, # TYPE crowdsec_alerts_total etc. Agora adicione o CrowdSec como alvo no prometheus.yml, apontando para o host monitorado (192.168.1.20:6061). No servidor Prometheus, edite o arquivo e adicione ao final:

  - job_name: "crowdsec"
    static_configs:
      - targets: ["192.168.1.20:6061"]
        labels:
          instance: "webserver01"
          service: "crowdsec"

  - job_name: "fail2ban"
    static_configs:
      - targets: ["192.168.1.20:9191"]
        labels:
          instance: "webserver01"
          service: "fail2ban"

Recarregue o Prometheus novamente com curl -X POST http://localhost:9090/-/reload. Verifique no UI http://SEU_IP:9090/targets que os jobs crowdsec e fail2ban aparecem com status UP (verde). Na próxima seção, vamos consumir essas métricas em Grafana e em regras de alerta.

Coleta de logs com Promtail e Loki — visualizando logs de firewall no Grafana

Métricas são excelentes para detectar “o que” está acontecendo, mas os logs são indispensáveis para entender “por que” e “quem” causou o evento. Nesta seção, vamos instalar o Loki (armazenamento de logs) no servidor de monitoramento e o Promtail (agente coletor) nos hosts que geram logs de firewall, fail2ban e CrowdSec. Essa integração completa o ciclo de monitoramento e alertas, permitindo que você correlacione métricas e logs nos dashboards do Grafana.

Instale o Loki no servidor de monitoramento. Usaremos os binários oficiais. No Ubuntu/Debian:

# ---- Loki no Ubuntu/Debian ----

cd /tmp

wget https://github.com/grafana/loki/releases/download/v3.3.0/loki-linux-amd64.zip

sudo apt install -y unzip

unzip loki-linux-amd64.zip

sudo mv loki-linux-amd64 /usr/local/bin/loki

sudo useradd --no-create


Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Firewall, fail2ban e CrowdSec para equipes corporativas.
  

    

    Falar no WhatsApp