Zabbix e Grafana no Docker em hardware barato: monitoramento de rede que cabe num Orange Pi

Monitoramento de rede costuma ser associado a servidor caro e software com licença. Não precisa ser assim. Neste artigo eu mostro a arquitetura que uso para rodar Zabbix 7 LTS e Grafana em Docker num Orange Pi 3 LTS com 2 GB de RAM, monitorando duas operadoras de internet e todos os equipamentos de uma rede pequena. O mesmo vale para Raspberry Pi 4 ou 5.

O projeto completo está no meu GitHub, em zabbix-e-grafana-2-wan.

Por que monitorar uma rede pequena

Em escritório, loja ou clínica, a pergunta de sempre é: “a internet caiu ou é o computador?”. Sem monitoramento, cada queda vira uma discussão com a operadora e uma tarde perdida. Com monitoramento você tem:

• A hora exata em que cada link caiu e voltou
• Latência e perda de pacote ao longo do dia
• Quais equipamentos estão ligados e respondendo
• Alertas antes que alguém precise reclamar

O hardware

Um computador de placa única (SBC) dá conta com folga. O Orange Pi 3 LTS tem processador Allwinner H6 de 4 núcleos ARM64, 2 GB de RAM e porta Gigabit. Com Ubuntu 22.04, o stack inteiro roda abaixo de 500 MB de memória.

Recomendações práticas:

• Use um cartão de boa qualidade ou, melhor, SSD via USB — banco de dados escreve muito.
• Fonte decente. Metade dos “bugs” de placa única é fonte fraca.
• Ligue a placa num nobreak junto com o roteador; senão ela cai junto e você perde o registro.

A arquitetura em containers

O docker-compose sobe quatro serviços:

1. PostgreSQL como banco do Zabbix (mais leve que MySQL nesse cenário)
2. Zabbix Server fazendo as coletas e disparando alertas
3. Zabbix Web (Nginx + PHP) para configuração
4. Grafana com o plugin do Zabbix para os painéis

Todos com imagens ARM64 oficiais. As variáveis sensíveis (senhas, tokens de alerta) ficam num arquivo .env fora do repositório.

Ajustes que fazem diferença em pouca memória:

• Reduzir StartPollers e CacheSize do Zabbix para o tamanho da rede
• Configurar shared_buffers do PostgreSQL de forma conservadora
• Diminuir o tempo de retenção de histórico detalhado (por exemplo, 7 dias) e manter tendências por mais tempo

Dual-WAN: duas operadoras, uma prova

O pulo do gato está na topologia. A placa fica entre os provedores e a rede, com uma interface para cada operadora. Assim dá para testar cada link pelo caminho dele, e não pelo caminho que o roteador escolheu.

Para cada link o Zabbix mede:

• Ping para destinos diferentes (DNS público, gateway da operadora, um servidor seu)
• Perda de pacote e jitter
• Resolução de DNS
• Disponibilidade calculada por dia e por mês

Quando um link cai, o alerta diz qual operadora, a hora e a duração. No fim do mês, o relatório de disponibilidade é o argumento que faltava para pedir desconto.

Para quem precisa de resolução ainda maior, criei o netmon, um monitor separado em Python puro que testa os dois links a cada 2 segundos, registra a hora do primeiro pacote perdido e gera um PDF — sem depender de nada além do Python que já vem no sistema.

Descoberta automática de dispositivos

Cadastrar equipamento por equipamento não escala. O Zabbix tem regras de discovery que varrem faixas de IP e criam os hosts sozinhos, aplicando templates por tipo (impressora, câmera, roteador). Com rotas estáticas, dá para enxergar inclusive redes atrás de outros roteadores.

Dica: dê nomes e IPs fixos aos equipamentos importantes no DHCP. O mapa fica legível e os alertas fazem sentido.

Painéis no Grafana

O Zabbix é ótimo para coletar e alertar, mas o Grafana é melhor para mostrar. Eu monto três painéis:

1. Visão geral: status dos dois links, latência das últimas 24 horas e lista do que está fora.
2. Operadoras: disponibilidade mensal, histórico de quedas e comparação entre links.
3. Rede interna: dispositivos online, tráfego por interface e mapa.

Um dashboard Grafana bem feito vira tela de TV no escritório e acaba com metade das perguntas.

Alertas que alguém lê

Alerta que vai para um e-mail que ninguém abre não serve. Configuro:

• WhatsApp ou Telegram para queda de link e equipamento crítico
• E-mail com resumo diário
• Atraso proposital de alguns minutos para não alertar por oscilação de segundos
• Escalonamento: se ninguém reconheceu o alerta em 30 minutos, avisa a próxima pessoa

Backup e manutenção

Monitoramento que some quando o cartão de memória morre não é monitoramento. O mínimo:

• Dump diário do PostgreSQL para outro disco ou para a nuvem
• Arquivos de configuração e docker-compose versionados no Git
• Atualizações de imagem com data marcada, nunca no automático

Erros comuns

• Monitorar tudo de uma vez: comece pelos links e pelos três equipamentos mais críticos. Depois amplie.
• Alertas demais: se tudo apita, ninguém olha. Ajuste limites até que cada alerta exija uma ação.
• Pingar só um destino: um DNS público fora do ar não significa que a sua internet caiu. Use pelo menos dois destinos diferentes por link.
• Esquecer o relógio: sem NTP configurado, a “hora exata da queda” deixa de ser exata.

Vale a pena fazer sozinho?

Se você gosta de Linux e tem tempo para ajustar, o repositório no GitHub tem tudo para começar. Se prefere receber pronto — placa configurada, painéis montados, alertas no seu WhatsApp e instalação na sua rede em São Paulo — veja o serviço de monitoramento de rede ou mande uma mensagem.