Como fazer monitoramento de rede: passo a passo para provedores
Como fazer monitoramento de rede: comece pelo inventário do que derruba mais assinantes, configure a coleta só de leitura em cada equipamento, defina limite e destinatário para cada alerta e ligue as dependências entre eles. Depois, meça de fora do seu ASN e ajuste tudo com duas a quatro semanas de histórico real.
Resumo
- O monitoramento útil começa pela borda, pelo concentrador e pelo CGNAT, e só depois chega ao switch de cliente.
- A coleta por SNMPv3 com usuário só de leitura não altera nada na configuração do equipamento.
- O tempo para perceber uma falha é a soma do intervalo de coleta, das tentativas exigidas e do envio do aviso.
- Alerta sem dono e sem roteiro vira ruído, e ruído ensina a equipe a ignorar o painel inteiro.
Como funciona o monitoramento de rede num provedor
O monitoramento de rede funciona em cinco movimentos: coletar números dos equipamentos, guardar o histórico, comparar com um limite, avisar alguém e registrar o que foi feito. Se um desses elos falta, a falha passa sem ser vista ou é vista e ninguém age.
Na prática, um servidor separado da rede de produção pergunta a cada equipamento, em intervalos fixos, quanto tráfego passou em cada interface, quanta CPU está em uso e se as sessões estão de pé. Essas respostas viram séries de tempo, e as regras de alerta olham para elas o tempo todo.
Ferramenta é a parte fácil. O trabalho que separa um painel bonito de um monitoramento de rede para provedor que funciona é decidir o que medir, com que limite e quem responde por cada aviso, antes de instalar qualquer coisa.
1 · Coleta
Ler o equipamento
SNMP, API ou telemetria trazem contadores de interface, CPU, memória e estado das sessões.
2 · Histórico
Guardar a série
Cada leitura fica gravada com data e hora, o que permite comparar a noite de hoje com a da semana passada.
3 · Regra
Comparar com o limite
A regra decide se o valor é normal, se merece aviso ou se é incidente grave.
4 · Aviso
Chamar o responsável certo
O alerta vai para quem pode agir, com gravidade e um roteiro curto do que conferir primeiro.
5 · Registro
Fechar o ciclo
O que foi feito fica anotado, e o limite é revisto se o aviso era falso.
A etapa 5 é a que mais falta nos provedores. Sem ela, o mesmo alerta falso toca toda noite durante meses.
O que entra na coleta e o que fica de fora
Entram os pontos em que uma falha atinge muitos assinantes de uma vez. O que afeta um cliente só, como o roteador Wi-Fi da casa dele, fica para o atendimento e para o sistema de gestão.
- Borda e trânsito: uso, erros e descartes de cada link, estado das sessões e CPU do roteador.
- Serviços de assinante: sessões PPPoE ativas, uso de portas do CGNAT, resposta do RADIUS e do DNS.
- Acesso: OLTs, portas PON e potência óptica, que pedem coleta própria e muitas vezes um modelo específico.
- Infraestrutura do POP: temperatura, fonte e bateria, que derrubam tudo quando falham juntas.
Como fazer monitoramento de rede em sete passos
Os sete passos abaixo valem tanto para começar do zero quanto para refazer uma ferramenta herdada. A ordem importa, porque alerta criado antes do inventário quase sempre fica com o limite errado.
- Inventário: liste equipamentos, links e serviços, com o número de assinantes que depende de cada um e quem é o responsável.
- Servidor de coleta: reserve uma máquina virtual fora do roteador de borda, com disco para guardar pelo menos um ano de tendência.
- Acesso de leitura: crie em cada equipamento um usuário SNMPv3 sem permissão de escrita, liberado só para o endereço do coletor.
- Modelos por tipo: aplique um modelo de coleta por família de equipamento, para que o mesmo item tenha o mesmo nome em toda a rede.
- Limites e gravidade: defina, ponto a ponto, quando é aviso e quando é incidente, e quem recebe cada um.
- Dependências: diga à ferramenta que, se o switch do POP cai, os equipamentos atrás dele não devem gerar alerta próprio.
- Revisão com dados reais: depois de duas a quatro semanas, corte os alertas que tocaram sem motivo e ajuste os limites pelo histórico.
Em provedores que já têm um Zabbix antigo, o passo 1 costuma revelar dezenas de equipamentos desligados ainda cadastrados e POPs novos que nunca entraram. Limpar isso antes de criar alertas novos economiza semanas de ruído.
Que equipamentos monitorar primeiro?
Comece por onde a queda custa mais: borda, concentradores PPPoE, CGNAT e servidores de autenticação. Uma hora parada num desses pontos atinge a base inteira, enquanto um switch de prédio atinge poucas dezenas.
Um critério simples ajuda a ordenar a lista: multiplique o número de assinantes que dependem do equipamento pela chance de ele falhar sem aviso. Equipamento único, sem redundância e antigo vai para o topo.
Exemplo: coleta SNMPv3 só de leitura no MikroTik e no Huawei
O exemplo abaixo cria um acesso SNMPv3 com autenticação e criptografia, sem escrita e restrito ao endereço do coletor. Depois, um teste a partir do servidor confirma que a leitura funciona antes de cadastrar o equipamento.
# RouterOS 7 (MikroTik): comunidade v3 só de leitura, aceita só do coletor
/snmp community add name=noc-leitura addresses=192.0.2.10/32 \
security=private authentication-protocol=SHA1 encryption-protocol=AES \
authentication-password=TROCAR-auth encryption-password=TROCAR-priv \
read-access=yes write-access=no
/snmp set enabled=yes contact="noc@provedor.exemplo" location="POP-Centro"
# Huawei VRP: grupo v3 com visão de leitura e ACL para o coletor
acl number 2001
rule 5 permit source 192.0.2.10 0
snmp-agent
snmp-agent sys-info version v3
snmp-agent mib-view included leitura iso
snmp-agent group v3 grupo-noc privacy read-view leitura acl 2001
snmp-agent usm-user v3 noc-leitura group grupo-noc
snmp-agent usm-user v3 noc-leitura authentication-mode sha
snmp-agent usm-user v3 noc-leitura privacy-mode aes128
# No servidor de coleta: ler os contadores de 64 bits das interfaces
snmpwalk -v3 -l authPriv -u noc-leitura -a SHA -A 'TROCAR-auth' \
-x AES -X 'TROCAR-priv' 198.51.100.1 IF-MIB::ifHCInOctets
Repare em dois detalhes. O primeiro é o contador ifHCInOctets, de 64 bits: o contador antigo, de 32 bits, dá a volta em poucos segundos num link de 10 Gbps e gera gráficos com picos falsos. O segundo é a restrição por endereço, que impede que qualquer máquina da rede leia a configuração do equipamento.
Se o snmpwalk responde com a lista de interfaces, o equipamento pode entrar na ferramenta. Se dá tempo esgotado, confira primeiro o filtro de firewall do próprio roteador, que costuma bloquear a porta 161 vinda de fora da rede de gerência.
Quer a coleta montada e documentada na sua rede?
No monitoramento de rede para provedores, um Especialista configura o acesso de leitura, os modelos, os limites e as dependências, e entrega a lista de alertas para você aprovar.
Monitoramento de rede em tempo real é possível?
É possível chegar perto, mas todo monitoramento tem um atraso, que vem do intervalo de coleta e das tentativas exigidas antes do alerta. Saber calcular esse atraso evita prometer à diretoria um aviso instantâneo que a ferramenta não entrega.
A conta é simples: tempo para perceber a falha = intervalo de coleta × número de leituras ruins exigidas + tempo de envio da notificação. Exigir mais de uma leitura ruim evita alarme por um pacote perdido, mas aumenta o atraso.
| Forma de coleta | Intervalo | Leituras ruins exigidas | Atraso aproximado |
|---|---|---|---|
| Ping ao equipamento | 60 segundos | 3 | Cerca de 3 minutos |
| SNMP de interface de borda | 60 segundos | 2 | Cerca de 2 minutos |
| SNMP do restante da rede | 5 minutos | 2 | Cerca de 10 minutos |
| Trap ou syslog enviado pelo equipamento | No momento do evento | 1 | Segundos, se a mensagem chegar |
| Telemetria por streaming | 10 segundos | 3 | Cerca de 30 segundos |
A linha do trap mostra por que vale combinar formas de coleta. O roteador avisa na hora quando uma interface ou sessão cai, mas a mensagem viaja por UDP e pode se perder; a coleta periódica confirma o estado logo depois.
SNMP ou telemetria: quando vale o streaming?
Vale quando picos de segundos derrubam a qualidade, como microrrajadas num link de trânsito que parece folgado na média de cinco minutos. Para CPU, memória e temperatura, o SNMP de minuto em minuto resolve.
A telemetria exige equipamento compatível e um coletor próprio, como o Prometheus. O guia de implantação de Prometheus mostra quando vale juntá-lo ao Zabbix sem duplicar alertas.
Erros comuns ao montar o monitoramento
Os erros mais caros não são de ferramenta, mas de critério, e quase todos produzem o mesmo sintoma: alerta demais ou alerta nenhum. Confira os seis abaixo antes de culpar o software.
Evite estes seis erros
- Copiar limites de outro provedor: um aviso a 80% de uso faz sentido num link folgado e chega tarde num rádio que já opera no limite.
- Alertar no primeiro pacote perdido: uma leitura ruim isolada acorda alguém à toa e ensina a equipe a silenciar o celular.
- Esquecer as dependências: sem elas, a queda de um switch de POP vira dezenas de alertas e esconde a causa.
- Coletar tudo de todos: milhares de itens sem uso enchem o disco e deixam a ferramenta lenta justamente no dia da falha.
- Medir só de dentro do ASN: o coletor interno não vê um prefixo que sumiu da internet; parte dos testes precisa partir de fora.
- Ninguém dono do alerta: aviso que vai para um grupo inteiro costuma ser lido por todos e tratado por ninguém.
Quando a ferramenta já tem histórico, ela também serve para antecipar falhas, como potência óptica caindo semana após semana. A análise preditiva de falhas parte exatamente desse histórico.
Checklist para saber se o monitoramento está pronto
O monitoramento está pronto quando uma falha simulada gera um alerta só, no destinatário certo, dentro do atraso calculado. O checklist abaixo transforma isso em itens que a equipe confere numa tarde.
Antes de dar o monitoramento como entregue
- Todo equipamento do inventário aparece na ferramenta, e nenhum desligado continua cadastrado.
- Cada alerta tem limite, gravidade, destinatário e um roteiro de até cinco linhas.
- Derrubar de propósito uma interface de teste gerou um único alerta, no tempo calculado.
- Desligar o switch de um POP de teste não gerou alertas dos equipamentos atrás dele.
- Pelo menos um teste parte de fora do ASN e confere se os prefixos do provedor respondem.
- O histórico guarda detalhe de 30 dias e tendência de um ano, com disco sobrando.
- Existe documento dizendo o que é monitorado, por quê e com que limite.
Cinco ou mais marcas indicam uma base confiável. Abaixo disso, a ferramenta ainda depende da memória de quem a montou.
Monitorar não é a mesma coisa que tratar. A Táquion Tech monitora redes de provedores e entrega a ferramenta com os alertas aprovados; quem acorda para cada alerta é a sua equipe ou um NOC contratado, como explica o guia sobre o que é NOC telecom.
Perguntas frequentes
Qual a diferença entre monitorar e fazer gerência de rede?
Monitorar é observar e avisar, sem mexer na configuração. Gerência inclui agir na rede, como mudar rotas, ajustar equipamentos e controlar mudanças; o monitoramento alimenta essas decisões com dados.
Como funciona o monitoramento de rede quando o coletor cai?
Se o próprio servidor de coleta para, nenhum alerta sai e o painel parece calmo. Por isso vale um teste externo simples, de outro lugar, que avisa quando o coletor deixa de responder.
Dá para ter monitoramento de rede em tempo real só com SNMP?
Com SNMP de minuto em minuto, a falha aparece em um a três minutos, o que atende a maioria dos provedores. Para segundos, combine traps, syslog ou telemetria por streaming nos equipamentos que suportam.
Quanto tempo leva para montar o monitoramento do zero?
Depende do número de equipamentos e de quantas marcas diferentes a rede tem. A coleta básica sobe rápido, mas o ajuste fino dos limites só termina depois de algumas semanas de histórico real.
Preciso monitorar cada ONU dos assinantes?
Não na coleta geral da rede, porque isso multiplica os itens sem ajudar a ver falhas grandes. ONUs e portas PON pedem coleta própria, como no monitoramento de OLTs, com alertas agrupados por região.
Fontes
- RFC 3414: User-based Security Model (USM) for SNMPv3: autenticação e criptografia por usuário no SNMPv3
- RFC 2863: The Interfaces Group MIB: contadores de 64 bits (ifHCInOctets) para interfaces de alta velocidade
- Documentação oficial do Zabbix: itens, triggers e dependências entre hosts