PRTG Network Monitor
A alternativa comercial mais citada ao lado de Zabbix/Nagios/LibreNMS — arquitetura, modelo de licenciamento, limitações reais e onde ele se encaixa (ou não) no contexto de ISP.
Nesta página
1. O que é e história Básico
1.1 Origem do nome
PRTG originalmente significava "Paessler Router Traffic Grapher" — o nome entrega a genealogia: nasceu na mesma linhagem conceitual do MRTG (Multi Router Traffic Grapher), a ferramenta pioneira de gráfico de tráfego via SNMP dos anos 1990 que também deu origem ao Cacti (ver página de Sistemas, categoria Monitoramento). A diferença é que o PRTG evoluiu pra um produto comercial completo, com empresa, suporte pago e roadmap dedicado — enquanto MRTG/Cacti seguiram como projetos open-source.
1.2 Linha do tempo
- 2001 — Dirk Paessler funda a Paessler GmbH, em Nuremberg, Alemanha
- 29 de maio de 2003 — primeiro lançamento do PRTG
- Software escrito em Delphi — decisão de tecnologia que explica boa parte do histórico de dependência de Windows no servidor core (ver seção 8)
- Hoje disponível em 3 formatos: PRTG Network Monitor (instalação própria, standalone), PRTG Enterprise Monitor (redes grandes/distribuídas), PRTG Hosted Monitor (SaaS — Paessler hospeda o core pra você)
- Paessler afirma mais de 500.000 usuários usando o produto diariamente (número institucional da própria empresa, não auditado por terceiro)
1.3 Proposta de valor central
O diferencial de mercado do PRTG nunca foi "fazer algo que o open-source não faz" — SNMP, ICMP, WMI, NetFlow, todos os protocolos de coleta são os mesmos usados por Zabbix/LibreNMS/Cacti. O diferencial é reduzir o tempo até o primeiro dashboard funcionando: auto-discovery mais guiado, mais de 250 tipos de sensor pré-configurados prontos pra usar, interface pensada pra quem não quer (ou não tem tempo/equipe pra) configurar tudo manualmente do zero. Isso tem um preço — literal, financeiro — que é o ponto central do comparativo na seção 6.
2. Arquitetura — Core, Sensor, Probe Intermediário
2.1 Sensor — a unidade atômica de monitoramento
No vocabulário do PRTG, um sensor monitora um valor específico — o tráfego de uma porta de switch, o uso de CPU de um servidor, o espaço livre de um disco. Um device (dispositivo) é o "container" que representa o equipamento real (ex: uma OLT), e recebe múltiplos sensores dentro dele. Regra prática oficial: em média, 5 a 10 sensores por dispositivo são necessários pra cobertura razoável. Isso importa porque toda a estrutura de licenciamento do PRTG é contada em número de sensores, não em número de dispositivos — ver seção 3.
2.2 Core Server e Probes
A instalação sempre tem um PRTG Core Server — onde fica a configuração, o banco de dados histórico, a interface web e o motor de notificações. Toda coleta de fato acontece através de probes:
- Local Probe — roda no próprio Core Server, criada automaticamente na instalação, suficiente pra monitorar uma LAN única
- Classic Remote Probe — instalada num sistema Windows separado, útil pra monitorar sub-redes atrás de firewall, filiais remotas, ou distribuir carga de coleta pra fora do Core Server
- Multi-Platform Probe — versão mais recente que roda em sistemas não-Windows, conectando ao Core através de um servidor NATS (mensageria)
Detalhe operacional relevante: se a conexão entre uma probe remota e o Core cair, a probe continua monitorando sozinha e guarda os resultados em buffer local (até 500.000 resultados de sensor, ocupando de 50 a 200 MB de RAM na máquina da probe) — quando a conexão volta, os dados acumulados são enviados de uma vez. Isso evita perder histórico numa queda de link entre a probe e o Core, mas também significa que alertas em tempo real não disparam durante a desconexão.
3. Modelo de licenciamento Intermediário
Toda a diferenciação entre os planos do PRTG é o número máximo de sensores — não há diferença de recursos entre plano pequeno e grande, só quantidade de coisas que dá pra monitorar simultaneamente. Existe uma edição Freeware, gratuita, limitada a 100 sensores — inclusive com direito a 1 cluster failover (par master+backup) mesmo na versão gratuita. Acima de 100 sensores, é preciso licença paga, escalonada por faixas de sensor. Há também um período de avaliação de 30 dias com todos os recursos liberados, sem limite de sensor, antes de decidir.
Ponto crítico pra dimensionar orçamento: "100 sensores grátis" parece bastante até você fazer a conta com a própria regra oficial da Paessler (5-10 sensores por dispositivo). Isso dá, na prática, pra monitorar 10 a 20 dispositivos de verdade na faixa gratuita — uma central pequena de OLT+switches já pode estourar isso rápido. Preços específicos por faixa mudam com o tempo — consulte sempre a tabela oficial atual da Paessler antes de decidir, não um número fixado aqui.
4. Escala e Alta Disponibilidade Avançado
4.1 Limites práticos recomendados oficialmente
A própria Paessler documenta como regra prática: instalações típicas raramente têm problema de performance abaixo de 5.000 sensores, 30 remote probes e 30 contas de usuário num único Core Server. Acima disso, entra na conversa de arquitetura mais elaborada (múltiplos Cores, PRTG Enterprise Monitor). Um detalhe pouco intuitivo: num cluster, a carga de monitoramento dobra a cada nó adicional — porque todo nó do cluster monitora tudo de forma independente, não é um esquema de balanceamento de carga entre nós, é redundância completa.
4.2 Cluster — como funciona de verdade
Um cluster PRTG é formado por um nó master e até 4 nós failover, cada um sendo uma instalação completa do PRTG capaz de monitorar e alertar sozinha. Todo objeto criado no "cluster probe" (criado automaticamente ao formar o cluster) é monitorado por todos os nós simultaneamente — não é um nó de standby passivo, é redundância ativa real. Se o master cai, um failover assume o papel de master até o original voltar, sem perda de configuração nem histórico.
5. Limitação real documentada Crítico
Esta seção existe porque quase todo material sobre PRTG disponível é institucional/promocional — aqui vai uma limitação real, confirmada pela própria equipe de suporte da Paessler em fórum oficial, não achismo de terceiro.
Remote probes não podem ser clusterizadas entre si. Só os nós Core (master + failovers) formam cluster com redundância verdadeira. Se você tem uma probe remota instalada num datacenter ou filial pra monitorar aquele segmento específico, e ela cai, não existe failover automático pra essa probe — o cluster protege o Core, não as probes remotas individualmente.
Usuários pedem essa funcionalidade desde pelo menos 2016 em fórum público oficial da Paessler. A resposta institucional da própria empresa, também pública, foi direta: implementar isso exigiria esforço grande de desenvolvimento e teste, beneficiaria só uma fração pequena da base de clientes, e por isso é "altamente improvável" de ser implementado no curto prazo. Ou seja: não é bug, é decisão de produto — mas é uma limitação de arquitetura real que qualquer avaliação séria de HA multi-site precisa considerar antes de comprar.
6. PRTG vs. alternativas open-source Avançado
| Critério | PRTG | Zabbix / LibreNMS / Cacti |
|---|---|---|
| Custo | Escalona com nº de sensores — pode ficar caro rápido em ISP com muitos dispositivos | Zero custo de licença — custo é só tempo de configuração/equipe |
| Tempo até 1º dashboard | Menor — auto-discovery guiado + 250+ sensores prontos | Maior — geralmente exige configurar template/OID manualmente |
| Suporte oficial | Sim, pago, com SLA — relevante pra ISP que não pode ficar sem monitoramento | Comunidade / consultoria terceirizada paga à parte |
| Customização profunda | Possível (sensores customizados, PRTG Sensor Hub), mas dentro do modelo do produto | Total — código aberto, sem limite de customização |
| Multi-plataforma no core | Historicamente Windows-centric (herança do Delphi) — hoje com opções Linux/hosted, mas legado pesa | Nativo Linux na maioria dos casos — mais alinhado ao resto da stack típica de NOC |
Não existe "melhor" absoluto — existe encaixe de contexto. Ver recomendação prática na seção 7.
7. Aplicação em contexto de ISP Intermediário
O PRTG suporta nativamente os protocolos que importam pra monitoramento de rede de acesso — SNMP (potência óptica de OLT, uso de porta de switch), NetFlow/sFlow/jFlow (visibilidade de tráfego por origem/destino), WMI (servidores Windows do NOC, se houver). Cenário onde ele tende a fazer mais sentido pra um provedor brasileiro: ISP de porte médio/grande, com equipe pequena de NOC e sem tempo/expertise dedicada pra manter uma stack open-source configurada e mantida — o custo da licença compra tempo de engenharia que, em equipe enxuta, é mais escasso que dinheiro.
Pra ISP pequeno começando do zero, com orçamento apertado e alguém disposto a configurar Zabbix/LibreNMS manualmente, o argumento financeiro pesa pro lado open-source — especialmente considerando que o "custo" real do PRTG cresce junto com a rede, exatamente no momento em que ela mais precisa de monitoramento robusto.
8. Segurança Avançado
Pontos de atenção padrão pra qualquer NMS centralizado, PRTG incluso: o Core Server concentra credenciais SNMP/WMI/API de toda a infraestrutura monitorada — comprometer o Core é potencialmente comprometer visibilidade (e em alguns casos, acesso de gerência) de tudo que ele monitora. Restringir acesso administrativo ao Core, usar SNMPv3 (com autenticação/criptografia) em vez de SNMPv1/v2c sempre que o equipamento suportar, e manter as probes remotas atualizadas são práticas básicas que valem tanto pra PRTG quanto pra qualquer NMS concorrente.
9. Configuração de exemplo — sensor SNMP de potência óptica Intermediário
Fluxo típico pra monitorar potência óptica de uma OLT via PRTG (independente de fabricante, desde que exponha o OID via SNMP — ver o artigo de Wiki técnica do seu fabricante específico pro OID exato):
- Adicionar a OLT como Device no PRTG, com o IP de gerência e a community/credencial SNMP configurada
- Rodar auto-discovery no device — o PRTG tenta identificar sensores padrão aplicáveis automaticamente
- Se o sensor de potência óptica específico não vier pronto (comum em equipamento de nicho, fora da lista de "principais fabricantes" já mapeados pelo PRTG), adicionar manualmente um sensor "SNMP Custom", apontando pro OID exato do fabricante
- Configurar threshold de alerta no canal do sensor (ex: warning em -25dBm, erro em -28dBm — valores de referência, confirme a faixa real do seu equipamento)
- Associar uma notificação (e-mail, push, webhook) ao sensor, testando o disparo antes de considerar em produção
10. Indicadores de dimensionamento Avançado
| Indicador | O que revela | Sinal de alerta |
|---|---|---|
| % de sensores usados vs. limite da licença | Proximidade de precisar upgrade de plano | Acima de 80% — planejar orçamento com antecedência, não emergencialmente |
| Tempo de scan vs. intervalo configurado | Saúde de performance do Core/probe | Scan demorando mais que o intervalo — Core/probe subdimensionado |
| Buffer de probe remota em uso | Estabilidade do link entre probe e Core | Buffer enchendo com frequência — link probe↔Core instável, investigar antes de perder dado |
11. Exercícios práticos Intermediário
Exercício 1. Um ISP quer monitorar 15 OLTs, cada uma com 8 sensores relevantes (potência óptica agregada, CPU, temperatura, uplinks etc). Isso cabe na edição Freeware (100 sensores)?
Ver gabarito
15 OLTs × 8 sensores = 120 sensores — já ultrapassa o limite de 100 da Freeware. E isso é só as OLTs; switches, servidores de NOC e outros dispositivos ainda vão somar mais. Esse é exatamente o cálculo que a seção 3 alertou: "100 sensores grátis" acaba rápido numa rede de ISP real.
Exercício 2. Você tem uma probe remota monitorando um PoP a 200km da sede, e quer garantir que, se essa probe específica cair, outra assuma automaticamente o monitoramento daquele PoP. O recurso de Cluster do PRTG resolve isso?
Ver gabarito
Não. O Cluster do PRTG dá redundância pro Core Server (master + failovers), não pras remote probes individualmente — essa é a limitação documentada na seção 5. Se a probe do PoP remoto cair, não existe failover automático pra ela; o monitoramento daquele PoP fica interrompido até a probe voltar ou alguém instalar/ativar uma segunda probe manualmente naquele local.
Exercício 3. Um equipamento de nicho (fabricante pequeno, pouco comum) não tem sensor pré-configurado no PRTG pra ler a potência óptica dele. O que fazer?
Ver gabarito
Criar um sensor SNMP Custom, apontando manualmente pro OID exato daquele fabricante (disponível no MIB dele, ou já documentado na Wiki técnica do seu portal, se o fabricante já tiver sido mapeado ali). Alternativa: checar o PRTG Sensor Hub, onde a comunidade compartilha sensores customizados prontos — pode ser que alguém já tenha resolvido esse fabricante específico antes de você.
12. Troubleshooting comum Intermediário
Checar conectividade de rede entre os dois (a probe precisa alcançar o Core, incluindo através de firewall/NAT se aplicável), e confirmar que o Core está aceitando conexões de remote probe na configuração administrativa.
Verificar se o Core/probe está sobrecarregado (muitos sensores, intervalo de scan curto demais pra capacidade de hardware disponível) — sintoma clássico de estar acima dos limites práticos recomendados (seção 4.1).
Comportamento esperado se foi a conexão entre probe remota e Core que caiu — a probe buffereia localmente mas não dispara notificação em tempo real nesse cenário, só quando reconecta e sincroniza (ver seção 2.2).
Não é bug, é o modelo — monitore o indicador de "% de sensores usados" (seção 10) continuamente, não só quando já estourou.
13. Glossário
Perguntas da Comunidade sobre PRTG
Dúvida sobre licenciamento, sensor customizado pra fabricante de nicho, ou se vale a pena migrar de Zabbix? Pergunte pra quem já decidiu isso na prática.
Fazer pergunta sobre PRTG14. Referências
- Paessler AG — Documentação oficial (paessler.com/manuals/prtg): arquitetura de probes, cluster, requisitos de sistema
- Paessler Knowledge Base — FAQ oficial e discussão pública sobre clustering de remote probes (kb.paessler.com)
- Paessler AG — Blog oficial (blog.paessler.com), release notes de cluster support
- Wikipedia — "Paessler PRTG" (histórico de lançamento e dados institucionais básicos)
Conteúdo técnico independente, sem afiliação com a Paessler AG. Preços e limites de plano mudam com o tempo — confirme sempre a tabela oficial atual antes de decisão de compra. Nenhum trecho deste artigo é cópia literal das fontes citadas.