Dia 20: Monitorização de Rede — SNMP, Cacti, Zabbix e PRTG

A monitorização de rede é o conjunto de olhos e ouvidos de qualquer administrador de sistemas. Sem ela, problemas de largura de banda, falhas de equipamento e congestionamento passam despercebidos até que um utilizador reclame. Neste Dia 20 do curso de redes, exploramos SNMP, Cacti, Zabbix, PRTG, NetFlow e sFlow — as ferramentas que transformam uma rede cega numa infra-estrutura observável.

ℹ O SNMP v3 é a única versão segura — v1 e v2c enviam community strings em texto simples. Sempre usar v3 com autenticação e encriptação.

Neste artigo

1. Introdução à Monitorização de Rede

Monitorização de rede é o processo de recolha, armazenamento e análise de métricas de dispositivos de rede — routers, switches, servidores, access points — para detectar problemas antes que afectem os utilizadores. Uma boa monitorização responde a três perguntas: o que está a acontecer agora, o que aconteceu antes e o que vai acontecer (tendências e capacidade).

Os pilares da monitorização de rede são quatro: recolha de dados via SNMP, NetFlow ou agentes; armazenamento em bases de dados de séries temporais (RRDtool, InfluxDB); visualização em gráficos e painéis; e alertas baseados em limites. Sem alertas, a monitorização é apenas um registo histórico — não previne falhas.

Numa PME típica, a monitorização permite responder a perguntas críticas: a ligação WAN está saturada? Qual a aplicação que consome mais largura de banda? O switch da sala de servidores está sobrecarregado? Quando precisaremos de actualizar o ligação Internet? Estas respostas não vêm de palpites — vêm de dados.

Ferramenta Tipo Licença Complexidade Melhor para
Cacti Gráficos SNMP Gratuito (GPL) Baixa Largura de banda, tendências
Zabbix Plataforma completa Gratuito (GPL) Média-Alta PME com monitorização integral
PRTG Comercial Freeware até 100 sensores Baixa PME que quer simplicidade
NetFlow/sFlow Análise de tráfego Depende da ferramenta Média Identificar principais emissores, aplicações

2. SNMP — Simple Network Management Protocol

O SNMP (Simple Network Management Protocol) é o protocolo fundamental da monitorização de rede. Funciona sobre UDP porta 161 (recolha) e 162 (traps — notificações assíncronas). Quase todos os dispositivos de rede suportam SNMP: routers, switches, access points, firewalls, servidores, NAS, UPS.

A arquitectura SNMP tem três componentes: o gestor (servidor de monitorização que faz as consultas), o agente (software no dispositivo que responde) e a MIB (Management Information Base — base de dados hierárquica de objectos identificáveis por OID — Object Identifier). Por exemplo, IF-MIB::ifInOctets.1 representa os octetos recebidos na interface 1.

Existem três versões do SNMP. A v1 (1988) usa community strings em texto simples — insegura. A v2c (1996) melhora a eficiência com bulk requests mas mantém community strings em texto simples. A v3 (2002) adiciona autenticação (SHA), encriptação (AES) e controlo de acesso baseado em utilizador — é a única versão adequada para ambientes de produção.

# Instalar e configurar SNMP
apt install snmpd snmp
# /etc/snmp/snmpd.conf
rocommunity public 192.168.1.0/24
sysLocation Servidor PME
sysContact [email protected]
# SNMPv3
createUser admin SHA "senha" AES "senha"
rouser admin authPriv
# Reiniciar snmpd
systemctl restart snmpd
# Consultar via SNMP
snmpwalk -v2c -c public 192.168.1.1
snmpwalk -v3 -u admin -l authPriv -a SHA -A "senha" -x AES -X "senha" 192.168.1.1
# Verificar interface
snmpget -v2c -c public 192.168.1.1 IF-MIB::ifInOctets.1
# NetFlow
nfcapd -w /var/cache/nfdump -p 2055
nfdump -r /var/cache/nfdump
# Verificar portas SNMP
ss -ulnp | grep 161

O comando snmpwalk percorre toda a árvore de OIDs de um dispositivo — útil para descobrir que métricas estão disponíveis. O snmpget consulta um OID específico — usado pelas ferramentas de monitorização em intervalos regulares (tipicamente 1-5 minutos).

As SNMP traps são notificações enviadas pelo dispositivo ao gestor sem serem solicitadas — o dispositivo alerta sobre eventos como ligação down, falha de autenticação ou temperatura alta. O gestor recebe traps na porta UDP 162 e deve estar configurado para as interpretar.

3. Cacti — Gráficos com RRDtool

O Cacti é uma ferramenta de código aberto (GPL) especializada em gráficos de séries temporais baseada em RRDtool (Round Robin Database). É excelente para visualizar largura de banda, tráfego de interface, CPU, memória e qualquer métrica obtida via SNMP. O RRDtool armazena dados de forma eficiente — os pontos antigos são agregados, reduzindo o espaço de armazenamento ao longo do tempo.

A instalação do Cacti requer um servidor LAMP (Linux, Apache/Nginx, MySQL/MariaDB, PHP). O processo inclui configurar o snmpd em cada dispositivo a monitorizar, adicionar o dispositivo no Cacti com a community string correcta, seleccionar os templates de gráficos (interface traffic, CPU, memória) e aguardar que o poller (cron de 5 minutos) recolha os primeiros dados.

Funcionalidade Descrição
Poller SNMP Recolhe métricas por SNMP a cada 5 minutos (configurável)
RRDtool Base de dados round-robin — armazena dados sem crescimento infinito
Templates Gráficos pré-definidos para routers, switches, servidores
Limites Plugin Limite para alertas por email
Autenticação LDAP, Active Directory ou autenticação local

O Cacti é ideal quando a necessidade principal é visualizar tendências históricas de largura de banda e disponibilidade de interfaces. Não é uma plataforma de alerta robusta — para isso, o Zabbix ou PRTG são mais adequados. Muitas PME usam Cacti para gráficos e Zabbix para alertas, combinando as forças de cada ferramenta.

4. Zabbix — Monitorização Completa

O Zabbix é uma plataforma de monitorização de código aberto (GPL) que combina recolha de dados, visualização, alertas e mapas de rede numa única solução. Ao contrário do Cacti (focado em gráficos SNMP), o Zabbix suporta múltiplos métodos de recolha: SNMP, agentes Zabbix em servidores, verificações activas e passivas, JMX para Java, HTTP/HTTPS, ICMP, SSH e checks personalizados via scripts.

A arquitectura do Zabbix tem quatro componentes: o Server (motor central que processa dados e gera alertas), a Database (MySQL, PostgreSQL ou Oracle para histórico), o Frontend (interface web em PHP) e os Agents (instalados nos servidores para recolher métricas de CPU, memória, disco, processos). O servidor pode também funcionar sem agentes usando apenas SNMP — ideal para dispositivos de rede.

O sistema de alertas do Zabbix é particularmente poderoso: suporta triggers com expressões lógicas complexas (média móvel, taxa de variação, diferença entre valores), escalonamento (notificar primeiro o administrador, depois o gestor se não resolvido), e múltiplos canais (email, SMS, Slack, Telegram, webhook personalizado). Os templates do Zabbix cobrem centenas de dispositivos prontos a usar — Cisco, MikroTik, Juniper, HP, Dell, Synology.

Cenário Recomendação
PME com 10-50 dispositivos Zabbix com templates SNMP prontos a usar
Servidor único a monitorizar Agente Zabbix + auto-registo
Rede distribuída (multi-site) Zabbix Proxy em cada site
Alertas inteligentes Triggers com expressões e escalonamento

O Zabbix Proxy é um componente que permite descentralizar a recolha: cada site remoto tem um proxy que agrega dados localmente e envia ao servidor central, reduzindo tráfego WAN e permitindo monitorização mesmo quando o ligação ao servidor central está temporariamente indisponível.

5. PRTG — Solução Comercial

O PRTG (Paessler Router Traffic Grapher) é uma solução comercial de monitorização de rede desenvolvida pela Paessler. A versão freeware permite até 100 sensores gratuitamente — ideal para PME pequenas. Cada sensor monitoriza um aspecto específico (tráfego de uma interface, ping a um hospedeiro, espaço em disco, carga de CPU), pelo que 100 sensores cobrem aproximadamente 20-30 dispositivos dependendo do número de interfaces.

O PRTG destaca-se pela simplicidade: instalação em Windows, auto-descoberta de rede via SNMP, configuração quase totalmente visual sem necessidade de editar ficheiros de configuração. Suporta SNMP, WMI (Windows Management Instrumentation), NetFlow, sFlow, análise de pacotes, sensores HTTP, DNS, email e muito mais — tudo numa única interface web.

Plano Sensores Custo Adequado para
Freeware Até 100 Gratuito PME até 30 dispositivos
PRTG 500 500 ~€1.600/ano PME média (50-100 dispositivos)
PRTG 1000 1.000 ~€3.200/ano PME grande ou escritórios múltiplos

A principal vantagem do PRTG sobre o Zabbix é a curva de aprendizado mais baixa: em menos de uma hora é possível ter uma PME completamente monitorizada com auto-descoberta. A principal desvantagem é o modelo de licenciamento por sensor — ao contrário do Zabbix (ilimitado), o PRTG exige planeamento cuidadoso de quantos sensores são necessários, e o custo escala rapidamente para redes médias e grandes.

6. NetFlow e sFlow — Análise de Tráfego

O SNMP responde à pergunta “quanto tráfego passa por esta interface?” mas não responde a “que aplicações e utilizadores estão a gerar esse tráfego?”. Para isso existem o NetFlow (Cisco) e o sFlow (padrão aberto). Ambos exportam fluxos — registos de comunicação entre origem e destino com marcas temporais, portas, protocolo e volume de dados.

O NetFlow, desenvolvido pela Cisco, funciona na camada 3 (IP): o router inspecciona cada pacote e cria registos de fluxo (src IP, dst IP, src port, dst port, protocolo, bytes, pacotes). Exporta esses registos via UDP para um colector. A versão NetFlow v9 é a mais comum; o IPFIX é o padrão IETF baseado no NetFlow v9.

O sFlow (Sampled Flow) funciona de forma diferente: em vez de inspeccionar todos os pacotes, faz amostragem estatística (ex: 1 em cada 1000 pacotes). Isto reduz o impacto no CPU do switch e funciona na camada 2 (inclui informação de VLAN e Ethernet). É suportado por HP, Aruba, Juniper, MikroTik e muitos switches de outros fabricantes.

Comparação NetFlow sFlow
Origem Cisco (proprietário) InMon (padrão aberto)
Camada L3 (IP) L2-L7 (Ethernet + IP)
Amostragem Todos os pacotes (preciso) Estatístico (1 em N)
Impacto no CPU Médio-Alto Baixo
Suporte Cisco, Juniper, alguns outros HP, Aruba, Juniper, MikroTik
Porta UDP 2055 (típico) 6343 (padrão)

Para analisar os fluxos recolhidos, ferramentas como nfdump (comando do bloco de código acima), Nfsen (interface web para nfdump) e ntopng permitem identificar os principais emissores (equipamentos que mais comunicam), classificar tráfego por aplicação e detectar anomalias. O ntopng é particularmente útil em PME — fornece um painel visual em tempo real com mapas de tráfego, listas de hospedeiros e distribuição por protocolo.

7. Erros Comuns e Lista de Verificação

A implementação de monitorização de rede está recheada de armadilhas. Segue-se uma lista dos erros mais frequentes e a respectiva correcção, seguida de uma lista de verificação para garantir que nada fica por configurar.

Problema Causa Solução
SNMP timeout Firewall bloqueia UDP 161 ou snmpd só escuta em localhost Configurar agentAddress e abrir porta 161
Community string errada Dispositivo e gestor usam strings diferentes Verificar configuração em ambos os lados
Gráficos vazios no Cacti Poller não tem permissões ou cron não executa Verificar cacti.log e permissões do utilizador poller
Falsos alertas no Zabbix Limites demasiado sensíveis sem janela temporal Usar triggers com min(/hospedeiro/key,5m) para suavizar
NetFlow sem dados Router não exporta ou firewall bloqueia porta 2055 Verificar exportação e conectividade ao colector
SNMP v1/v2c em produção Configuração por defeito insegura Migrar para v3 com authPriv

⚠️ Monitorizar sem alertas configurados é como ter um alarme sem sirene — sempre definir limites e notificações.

Lista de verificação para implementação de monitorização:

  • Configurar SNMP v3 (authPriv) em todos os dispositivos de rede
  • Verificar conectividade SNMP com snmpwalk antes de adicionar à ferramenta
  • Definir intervalos de consulta adequados (1-5 min para tempo real, 15 min para tendências)
  • Configurar traps SNMP (UDP 162) para eventos assíncronos (ligação down, falhas)
  • Definir limites com janelas temporais para evitar falsos alertas
  • Configurar canais de notificação (email, SMS, Slack/Telegram) e testar
  • Implementar escalonamento de alertas (notificar equipa secundária se sem resposta)
  • Activar NetFlow/sFlow em routers de borda para análise de tráfego WAN
  • Verificar que o servidor de monitorização tem recursos suficientes (CPU, RAM, disco)
  • Configurar cópias de segurança da base de dados de monitorização (histórico é valioso)
  • Documentar a topologia monitorada e os OIDs/templates usados
  • Rever periodicamente os alertas configurados — remover os que nunca disparam

A monitorização de rede não é um projecto que se completa — é um processo contínuo. À medida que a rede cresce, novos dispositivos precisam de ser adicionados, limites precisam de ser ajustados e alertas precisam de ser afinados. O investimento inicial numa boa plataforma de monitorização (seja Cacti, Zabbix, PRTG ou uma combinação) paga-se na primeira vez que um problema é detectado antes de os utilizadores notarem.

Artigos Relacionados: