Zabbix vs PRTG vs Nagios em 2026: Qual a Melhor Solução de Monitorização para PME?
✎ Duarte Spínola | 14 de Julho de 2026
Escolher uma solução de monitorização para infraestrutura é uma das decisões mais importantes para uma PME. Monitar servidores, switches, access points, VMs e serviços cloud permite detectar problemas antes que afectem os utilizadores, mas o mercado oferece dezenas de opções com modelos de licenciamento, arquitecturas e curvas de aprendizagem muito diferentes. Em 2026, três soluções continuam a dominar o segmento das PME: Zabbix (open-source, auto-hosted), PRTG Network Monitor da Paessler (freeware até 100 sensores, comercial acima disso) e Nagios Core (open-source, modular). Este artigo compara as três em termos técnicos e práticos, com comandos reais de instalação, tabelas de comparação e um guia de decisão.
As referências principais são a documentação oficial do Zabbix, a documentação do PRTG e a documentação do Nagios Core. Para detalhes de licenciamento, consulte a página de preços da Paessler e o site do Nagios.
1. Cenários Típicos de PME Portuguesas
Uma PME portuguesa típica com 25 dispositivos precisa de monitorizar uma mistura de infraestrutura física e virtual:
| Tipo de Dispositivo | Quantidade Típica | Protocolo Principal |
|---|---|---|
| Servidores Windows (AD, ficheiros, Hyper-V) | 4-6 | WMI / Agente |
| Servidores Linux (web, DB, Docker) | 3-5 | Agente / SSH |
| Switches geridos (HP, Cisco, TP-Link) | 3-5 | SNMP |
| Access points WiFi | 3-5 | SNMP |
| VMs (Hyper-V, Proxmox, VMware) | 5-8 | Agente / API |
| Firewall / Router | 1-2 | SNMP / API |
| Impressoras de rede | 2-3 | SNMP |
| Serviços cloud (Microsoft 365, AWS) | 2-3 | API / HTTP |
Neste cenário, cada dispositivo pode gerar entre 5 e 20 métricas (sensores), o que significa um total aproximado de 125 a 500 pontos de monitorização. Este volume é fundamental para entender as limitações do freeware PRTG (100 sensores) e a capacidade de escalabilidade de cada solução.
A escolha depende também da equipa disponível. Uma PME sem administrador de sistemas dedicado prefere uma solução com interface gráfica simples e configuração assistida. Uma PME com um sysadmin confortável com Linux e linha de comandos pode aproveitar todo o potencial de soluções open-source como Zabbix ou Nagios.
2. Comparação Técnica Geral
| Característica | Zabbix | PRTG Network Monitor | Nagios Core |
|---|---|---|---|
| Modelo de licenciamento | Open-source (GPL v2) | Freeware 100 sensores / Comercial | Open-source (GPL v2) |
| Linguagem principal | C / PHP | Delphi / C++ | C |
| Interface web | Sim (PHP frontend) | Sim (AJAX-based) | Sim (CGI básico) |
| Base de dados | PostgreSQL, MySQL, Oracle | SQLite (interno) | Ficheiros de texto |
| Agente próprio | Zabbix Agent / Agent 2 | PRTG Probe (Windows) | Nagios Remote Plugin Executor (NRPE) |
| SNMP | v1, v2c, v3 | v1, v2c, v3 | v1, v2c, v3 (via plugins) |
| Auto-discovery | Nativo (network discovery) | Nativo (auto-discovery) | Via add-ons (Nmap, scripts) |
| Dashboards | Nativo (global dashboards) | Nativo (dashboards por sensor) | Básico (via add-ons) |
| Mapas de rede | Nativo (mapas interactivos) | Nativo (mapas georreferenciados) | Via add-ons (NagVis) |
| API | JSON RPC | REST API (HTTP) | Não nativo (via add-ons) |
| Repositório de templates | Zabbix Integrations | Sensores pré-configurados | Nagios Exchange |
| Curva de aprendizagem | Moderada | Baixa | Alta |
| Comunidade | Muito activa | Comunidade commercial | Muito activa (histórica) |
| Documentação oficial | zabbix.com/manuals | paessler.com/manuals/prtg | Nagios Core docs |
A tabela acima resume as diferenças fundamentais. Zabbix oferece a combinação mais completa de funcionalidades nativas sem custo. PRTG sacrifica flexibilidade por simplicidade. Nagios Core é o mais minimalista — a funcionalidade estende-se através de plugins e add-ons da comunidade, mas exige mais configuração manual.
3. Zabbix: Instalação e Configuração
O Zabbix é uma solução de monitorização distribuída com arquitectura server-agent. O servidor central recolhe dados de agentes instalados nos hosts ou via SNMP sem agente. A documentação oficial de instalação está em zabbix.com/download, que gera comandos específicos conforme a distribuição e versão.
Instalação via pacotes (Ubuntu 24.04)
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_7.0-2+ubuntu24.04_all.deb
sudo apt update
# Instalar servidor, frontend e agente
sudo apt install -y zabbix-server-pgsql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts pgsql-client zabbix-agent2
# Criar base de dados
sudo -u postgres createuser –pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
# Importar esquema inicial
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix
# Configurar credenciais no ficheiro do servidor
sudo sed -i ‘s/^DBPassword=.*/DBPassword=sua_password/’ /etc/zabbix/zabbix_server.conf
# Iniciar serviços
sudo systemctl restart zabbix-server zabbix-agent2 apache2
sudo systemctl enable zabbix-server zabbix-agent2 apache2
Após a instalação, o frontend está disponível em http://servidor/zabbix. O utilizador predefinido é Admin com password zabbix — deve ser alterada imediatamente. O guia de configuração rápida está disponível na documentação oficial de quickstart.
Instalação via Docker
docker network create zabbix-net
# Iniciar base de dados PostgreSQL
docker run -d –name zabbix-pgsql \
–network zabbix-net \
-e POSTGRES_USER=zabbix \
-e POSTGRES_PASSWORD=zabbix_pwd \
-e POSTGRES_DB=zabbix \
postgres:16-alpine
# Iniciar servidor Zabbix
docker run -d –name zabbix-server \
–network zabbix-net \
-e DB_SERVER_HOST=zabbix-pgsql \
-e POSTGRES_USER=zabbix \
-e POSTGRES_PASSWORD=zabbix_pwd \
-e POSTGRES_DB=zabbix \
-p 10051:10051 \
zabbix/zabbix-server-pgsql:ubuntu-7.0-latest
# Iniciar frontend web
docker run -d –name zabbix-web \
–network zabbix-net \
-e ZBX_SERVER_HOST=zabbix-server \
-e DB_SERVER_HOST=zabbix-pgsql \
-e POSTGRES_USER=zabbix \
-e POSTGRES_PASSWORD=zabbix_pwd \
-e POSTGRES_DB=zabbix \
-p 8080:8080 \
zabbix/zabbix-web-nginx-pgsql:ubuntu-7.0-latest
O frontend Docker fica disponível em http://servidor:8080. A documentação de instalação detalha todas as opções de configuração, incluindo suporte para MySQL em vez de PostgreSQL.
Configuração do agente em hosts remotos
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_7.0-2+ubuntu24.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent2
# Configurar o servidor Zabbix no agente
sudo sed -i ‘s/^Server=.*/Server=IP_DO_SERVIDOR_ZABBIX/’ /etc/zabbix/zabbix_agent2.conf
sudo sed -i ‘s/^ServerActive=.*/ServerActive=IP_DO_SERVIDOR_ZABBIX/’ /etc/zabbix/zabbix_agent2.conf
sudo sed -i ‘s/^Hostname=.*/Hostname=nome-do-host/’ /etc/zabbix/zabbix_agent2.conf
sudo systemctl restart zabbix-agent2
sudo systemctl enable zabbix-agent2
O Zabbix Agent 2 suporta monitorização de Docker, PostgreSQL, MySQL, Redis, MongoDB e Kubernetes nativamente, conforme a documentação de integrações. O agente original (Zabbix Agent) continua disponível para cenários mais simples.
4. PRTG Network Monitor: Instalação e Configuração
PRTG Network Monitor é uma solução comercial da Paessler que corre exclusivamente em Windows Server. A versão freeware permite até 100 sensores gratuitamente, sem limite de tempo. Um sensor é uma métrica individual — por exemplo, ping num host conta como 1 sensor, mas monitorizar CPU + RAM + disco num servidor conta como 3 sensores.
Instalação
A instalação do PRTG é feita através de um instalador gráfico disponível em paessler.com/prtg:
- Descarregar o instalador (requer Windows Server 2019 ou superior)
- Executar como administrador e seguir o assistente
- Definir a password de administrador durante a instalação
- Após a instalação, o interface web fica disponível em
https://servidor:8443ouhttp://servidor:8080
O PRTG também pode correr numa VM Windows no Proxmox, Hyper-V ou VMware. Não existe versão Linux nativa — é uma limitação importante para PME sem infraestrutura Windows.
Configuração inicial via interface web
A configuração do PRTG é inteiramente gráfica, sem necessidade de editar ficheiros de configuração:
- Aceder a
https://servidor:8443e autenticar com as credenciais definidas - O assistente de auto-discovery pergunta um intervalo de IP e detecta dispositivos automaticamente
- Para cada dispositivo detectado, o PRTG cria sensores recomendados com base no tipo de dispositivo (switch → portas SNMP, servidor Windows → CPU/RAM/disco via WMI)
- Sensores adicionais podem ser adicionados manualmente via “Add Sensor” em cada dispositivo
A documentação oficial do PRTG descreve todos os tipos de sensores disponíveis (mais de 250 tipos pré-configurados).
Instalação de Probe remoto
Para monitorizar redes remotas sem expor todos os dispositivos à internet, o PRTG usa “Probes” — mini-agentes que reportam ao servidor central:
- No servidor PRTG, ir a Setup > PRTG Probe Administration > Add Probe
- Definir um nome e gerar uma probe key
- Na máquina remota (Windows), instalar o PRTG Probe (download separado no site da Paessler)
- Inserir a probe key durante a configuração do Probe
O Probe comunica com o servidor via ligação encriptada (port 23560), simplificando a monitorização de filiais sem VPN site-to-site.
Limitação do freeware
A versão freeware tem um limite de 100 sensores. Para uma PME com 25 dispositivos, se cada dispositivo tiver em média 5 sensores, o total é 125 — já acima do limite gratuito. A página de preços detalha os planos comerciais (PRTG 500, PRTG 1000, etc.).
5. Nagios Core: Instalação e Configuração
Nagios Core é o motor de monitorização open-source mais antigo dos três (lançado em 1999 como NetSaint). A sua arquitectura baseia-se num motor central que executa plugins de monitorização e lê configuração de ficheiros de texto. Não tem base de dados — o estado é mantido em memória e em ficheiros. A documentação oficial cobre a instalação e configuração.
Instalação em Ubuntu 24.04
sudo apt update
sudo apt install -y build-essential apache2 php libapache2-mod-php php-gd libgd-dev unzip
# Criar utilizador e grupo do Nagios
sudo useradd -m -s /bin/bash nagios
sudo groupadd nagcmd
sudo usermod -aG nagcmd nagios
sudo usermod -aG nagcmd www-data
# Descarregar e compilar Nagios Core 4.x
cd /tmp
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.5.9.tar.gz
tar xzf nagios-4.5.9.tar.gz
cd nagios-4.5.9
./configure –with-command-group=nagcmd
make all
sudo make install
sudo make install-commandmode
sudo make install-config
sudo make install-init
sudo make install-webconf
# Criar utilizador web para interface
sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
# Instalar plugins padrão
cd /tmp
wget https://nagios-plugins.org/download/nagios-plugins-2.4.12.tar.gz
tar xzf nagios-plugins-2.4.12.tar.gz
cd nagios-plugins-2.4.12
./configure –with-nagios-user=nagios –with-nagios-group=nagios
make
sudo make install
# Iniciar e activar serviço
sudo systemctl enable nagios
sudo systemctl start nagios
sudo systemctl restart apache2
O interface web fica disponível em http://servidor/nagios com o utilizador nagiosadmin. A documentação de configuração descreve a estrutura dos ficheiros.
Configuração de um host
A configuração do Nagios é feita editando ficheiros de texto. O exemplo seguinte define um host e um serviço:
define host {
use linux-server
host_name servidor-web
alias Servidor Web Produção
address 192.168.1.10
check_command check-host-alive
max_check_attempts 3
check_interval 5
retry_interval 1
check_period 24×7
notification_interval 30
notification_period 24×7
notifications_enabled 1
}
define service {
use generic-service
host_name servidor-web
service_description CPU Load
check_command check_nrpe!check_load
check_interval 5
retry_interval 1
}
Após editar a configuração, validar e reiniciar:
sudo systemctl restart nagios
Instalação de NRPE em hosts remotos
O NRPE (Nagios Remote Plugin Executor) permite executar plugins no host remoto. A documentação de monitorização Linux descreve o processo. O código-fonte está no GitHub do NagiosEnterprises.
sudo apt update
sudo apt install -y nagios-nrpe-server nagios-plugins
# Configurar servidor Nagios permitido
sudo sed -i ‘s/^allowed_hosts=.*/allowed_hosts=IP_DO_SERVIDOR_NAGIOS/’ /etc/nagios/nrpe.cfg
sudo systemctl restart nagios-nrpe-server
sudo systemctl enable nagios-nrpe-server
Nagios XI (versão comercial)
Para PME que preferem não configurar ficheiros de texto, existe o Nagios XI, a versão comercial com interface web completo, auto-discovery nativo e relatórios avançados. O Nagios XI tem um custo de licenciamento, mas elimina grande parte da complexidade de configuração do Nagios Core.
6. Tipos de Monitorização: SNMP, Agente, ICMP, WMI e API
Cada solução suporta diferentes métodos de monitorização. A tabela seguinte compara os tipos disponíveis em cada plataforma:
| Tipo de Monitorização | Zabbix | PRTG | Nagios Core |
|---|---|---|---|
| ICMP (ping) | Nativo | Nativo | Plugin check_ping |
| SNMP v1/v2c | Nativo | Nativo | Plugin check_snmp |
| SNMP v3 | Nativo | Nativo | Plugin check_snmp |
| Agente próprio | Zabbix Agent / Agent 2 | PRTG Probe (Windows) | NRPE |
| WMI (Windows) | Nativo (via agente) | Nativo | Plugin check_wmi_plus |
| API REST | Nativo (HTTP agent) | Nativo (HTTP sensor) | Via scripts custom |
| SSH (sem agente) | Nativo | Não | Plugin check_by_ssh |
| HTTP/HTTPS | Nativo | Nativo | Plugin check_http |
| JDBC (bases de dados) | Nativo | Nativo | Plugin check_db |
| JMX (Java) | Nativo | Nativo | Plugin check_jmx |
| VMware vSphere | Nativo (via API) | Nativo | Plugin check_vmware_api |
| Docker | Nativo (Agent 2) | Via script | Via plugin externo |
SNMP
O SNMP é o protocolo universal para monitorização de equipamentos de rede (switches, routers, access points, impressoras). Todos os três suportam SNMP v1, v2c e v3. A documentação de SNMP do Zabbix descreve a configuração de SNMP no Zabbix, incluindo a descoberta automática de interfaces de rede via SNMP.
No Zabbix, a configuração SNMP é feita no nível do host, definindo a community string (v2c) ou credenciais (v3). Os templates SNMP pré-configurados (disponíveis em zabbix.com/integrations) cobrem equipamentos de marcas como Cisco, HP, Juniper, TP-Link e MikroTik.
No PRTG, basta adicionar um sensor “SNMP” ao dispositivo e seleccionar a métrica desejada (tráfego de porta, CPU, memória, etc.). O PRTG inclui bibliotecas SNMP MIB pré-carregadas.
No Nagios, o SNMP é tratado via check_snmp, um plugin que aceita OID e community string como parâmetros:
/usr/local/nagios/libexec/check_snmp -H 192.168.1.1 -C public -o .1.3.6.1.4.1.9.2.1.58.0 -w 80 -c 95
WMI
O WMI (Windows Management Instrumentation) é essencial para monitorizar servidores Windows sem instalar agente. O PRTG tem suporte nativo excelente para WMI — basta fornecer credenciais de domínio e o PRTG recolhe CPU, memória, disco, serviços e eventos. O Zabbix também suporta WMI, mas recomenda-se a instalação do agente para desempenho superior. No Nagios, o WMI é possível via check_wmi_plus, um plugin externo da comunidade disponível no Nagios Exchange.
API
A monitorização via API é cada vez mais relevante para serviços cloud (Microsoft 365, AWS, Azure, Google Cloud). O Zabbix oferece o tipo de item “HTTP Agent” que permite fazer chamadas HTTP/JSON e extrair valores via JSONPath. O PRTG tem o sensor “HTTP JSON” equivalente. O Nagios requer scripts personalizados (em Python, Bash, etc.) chamados via check_command.
O Zabbix também tem uma API JSON RPC completa que permite automatizar a configuração de hosts, templates e alertas programaticamente — útil para integração com sistemas de provisionamento.
7. Alertas, Notificações, Dashboards e Mapas de Rede
Alertas e Notificações
| Característica | Zabbix | PRTG | Nagios Core |
|---|---|---|---|
| Nativo (SMTP/TLS) | Nativo (SMTP/TLS) | Nativo (sendmail/postfix) | |
| SMS | Via gateway SMS ou API | Nativo (via Business SMS) | Via scripts externos |
| Slack | Via webhook | Nativo (sensor de notificação) | Via plugin externo |
| Microsoft Teams | Via webhook | Nativo (sensor de notificação) | Via plugin externo |
| Webhook genérico | Nativo | Nativo | Via scripts externos |
| Escalonamento | Nativo (níveis e regras) | Nativo (chedules e dependências) | Via configuração manual |
| Eventos de tempo de inactividade (downtime) | Nativo | Nativo | Nativo |
| Dependências entre hosts | Nativo | Nativo | Nativo |
A documentação de notificações do Zabbix detalha a configuração de medias types (email, SMS, webhook), regras de escalonamento e notificações baseadas em triggers.
Exemplo de configuração de webhook Slack no Zabbix:
# URL: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
# Method: POST
# Body (JSON):
{
“channel”: “#alertas-infra”,
“text”: “{ALERT.MESSAGE}”,
“username”: “Zabbix”
}
No PRTG, as notificações são configuradas via Setup > Notification Templates, onde se pode definir email, SMS, webhook, ou execução de programa. O PRTG tem templates pré-configurados para Slack e Teams.
No Nagios, as notificações são definidas nos ficheiros de configuração:
define contact {
contact_name admin-infra
use generic-contact
alias Administrador de Infraestrutura
email [email protected]
service_notification_commands notify-by-slack
host_notification_commands notify-by-slack
}
define command {
command_name notify-by-slack
command_line /usr/local/bin/slack-notify.sh “$HOSTNAME$” “$SERVICEDESC$” “$SERVICESTATE$” “$SERVICEOUTPUT$”
}
O script slack-notify.sh envia uma mensagem para o webhook do Slack usando curl.
Dashboards
| Característica | Zabbix | PRTG | Nagios Core |
|---|---|---|---|
| Dashboards personalizados | Sim (drag-and-drop, global) | Sim (por sensor/grupo) | Não (via add-ons) |
| Gráficos em tempo real | Sim | Sim | Sim (via PNP4Nagios) |
| SLA widgets | Sim | Sim (via sensores SLA) | Via add-ons |
| Geomap | Sim | Sim | Não |
| Multi-ecrã (NOCC) | Sim | Sim | Via add-ons (NagVis) |
| Exportação de relatórios | PDF, CSV nativo | PDF, HTML, CSV nativo | Via add-ons (Nagios Report) |
| Disponibilidade histórica | Sim (gráficos long-term) | Sim (histórico limitado por edição) | Sim (via add-ons) |
O Zabbix introduziu em 2024 (versão 7.0 LTS) dashboards globais partilháveis com widgets customizáveis, correlação de eventos e SLA calculado automaticamente. O interface web permite criar dashboards públicos (sem autenticação) para monitores de NOCC.
O PRTG tem um sistema de dashboards baseado em sensores, onde cada sensor pode ser exibido como um widget. Os dashboards do PRTG são menos flexíveis que os do Zabbix, mas mais simples de configurar.
O Nagios Core não tem dashboards nativos. A solução comum é instalar o NagVis, um add-on que cria mapas visuais e dashboards sobre os dados do Nagios, ou usar o PNP4Nagios para gráficos de performance.
Mapas de Rede
O Zabbix tem um construtor de mapas nativo que permite criar topologias de rede interactivas com ícones, ligações e estado em tempo real. É possível criar mapas hierárquicos (mapa geral → mapa de detalhe de cada região) e adicionar indicadores de tráfego nas ligações entre nós.
O PRTG tem funcionalidade equivalente com mapas georreferenciados (usando coordenadas GPS) e mapas de topologia baseados em grupos de dispositivos.
O Nagios Core não tem mapas nativos. O NagVis é o add-on padrão da comunidade para esta funcionalidade, disponível no Nagios Exchange.
8. Templates, Auto-Discovery e Escalabilidade
Templates e Packs
| Solução | Repositório Oficial | Quantidade Estimada | Comunidade |
|---|---|---|---|
| Zabbix | zabbix.com/integrations | 500+ templates oficiais | 1000+ contribuídos |
| PRTG | Sensores integrados (250+ tipos) | 250+ tipos de sensor | Comunidade PRTG |
| Nagios | exchange.nagios.org | 4000+ plugins | Comunidade activa |
O Zabbix tem o sistema de templates mais estruturado. Um template agrupa items, triggers, gráficos e dashboards que podem ser aplicados a múltiplos hosts. A documentação de templates descreve como criar, importar e exportar templates em JSON/XML. Templates oficiais cobrem sistemas operativos (Windows, Linux, macOS), bases de dados (PostgreSQL, MySQL, Oracle, MongoDB), aplicações (Apache, Nginx, Docker, Kubernetes), hardware (Dell iDRAC, HP iLO, Supermicro) e equipamentos de rede (Cisco, HP, Juniper, MikroTik, TP-Link).
O PRTG não usa o conceito de “templates” da mesma forma — em vez disso, cada tipo de sensor é um template implícito. Ao adicionar um sensor “SNMP CPU Load” a um switch, o PRTG aplica automaticamente a configuração SNMP correcta para esse tipo de equipamento.
O Nagios depende de plugins individuais. O Nagios Exchange é o repositório central da comunidade, com mais de 4000 plugins e add-ons. A qualidade e manutenção variam significativamente — alguns plugins são robustos e bem mantidos, outros são scripts abandonados.
Auto-Discovery
| Característica | Zabbix | PRTG | Nagios Core |
|---|---|---|---|
| Network discovery (varredura IP) | Nativo | Nativo | Via add-on (Nmap) |
| Descoberta de serviços | Nativo (SNMP, HTTP, etc.) | Nativo | Via scripts |
| Auto-registo de agentes | Nativo | N/A (Probe é manual) | Não |
| Descoberta de interfaces de rede | Nativo via SNMP | Nativo via SNMP | Via script |
| Templates automáticos | Sim (regras LLD) | Sim (sensor factory) | Não nativo |
| Low-Level Discovery (LLD) | Nativo (file systems, portas de rede, etc.) | Limitado | Não nativo |
O Zabbix destaca-se com o Low-Level Discovery (LLD), que detecta automaticamente entidades dentro de um host — partições de disco, interfaces de rede, portas de switch, processos — e cria items/triggers para cada uma. Se um novo disco for adicionado a um servidor, o Zabbix detecta-o automaticamente e começa a monitorizá-lo sem intervenção manual. A documentação de discovery detalha esta funcionalidade.
O PRTG tem auto-discovery de rede que detecta dispositivos num intervalo IP e cria sensores recomendados. É mais simples que o LLD do Zabbix, mas menos flexível — não descobre entidades dentro de um dispositivo automaticamente.
O Nagios Core não tem auto-discovery nativo. A solução comum é usar scripts baseados em Nmap ou o add-on NConf para gestão de configuração. O Nagios XI (comercial) já inclui auto-discovery nativo.
Escalabilidade
| Métrica | Zabbix | PRTG | Nagios Core |
|---|---|---|---|
| Dispositivos suportados (recomendado) | 10 000+ (com tuning) | 100 a 10 000 (conforme licença) | 1 000 a 5 000 (com tuning) |
| Sensores/métricas por servidor | 100 000+ (com PostgreSQL tuned) | Até 10 000 (PRTG 10000) | ~10 000 (com recursos adequados) |
| Proxy/Zona distribuída | Sim (Zabbix Proxy) | Sim (Remote Probe) | Sim (distributed monitoring via NSCA) |
| Alta disponibilidade nativa | Sim (HA cluster nativo desde 6.0) | Não (cold standby apenas) | Não (via add-ons) |
| Repositório de histórico | PostgreSQL/MySQL (escalável) | Interno (limitado por edição) | Ficheiros (NRDP/NDOMod para DB) |
O Zabbix é o mais escalável dos três. Com Zabbix Proxies distribuídos, uma única instância pode monitorizar dezenas de milhares de dispositivos. A documentação descreve a arquitectura de proxies para cenários distribuídos. O suporte nativo a alta disponibilidade (introduzido na versão 6.0) permite um cluster activo-passivo sem add-ons externos.
O PRTG escala conforme a licença: PRTG 500 (500 sensores), PRTG 1000, PRTG 2500, até PRTG 10000. Cada nível tem um custo crescente. Para PME, a versão freeware (100 sensores) ou PRTG 500 costuma ser suficiente. Para ambientes maiores, o PRTG torna-se caro rapidamente.
O Nagios Core escala razoavelmente, mas sem base de dados nativa, o histórico de dados é limitado. Para retenção longa, é necessário integrar com sistemas externos (Graphite, InfluxDB) via NDOMod ou NRDP. A escalabilidade horizontal requer arquitectura distribuída com NSCA (Nagios Service Check Acceptor).
9. Custos para PME com 25 Dispositivos
Para uma PME com 25 dispositivos e aproximadamente 125 sensores (5 métricas por dispositivo), os custos reais são:
Zabbix
| Item | Custo |
|---|---|
| Licença software | 0 (open-source GPL v2) |
| Servidor (VM com 2 vCPU, 4 GB RAM, 50 GB disco) | Custo da infraestrutura existente |
| Sistema operativo | 0 (Linux) |
| Suporte comercial (opcional) | A partir de 900 EUR/ano (Zabbix Support) |
| Formação (opcional) | Zabbix oferece certificação gratuita online |
| Total ano 1 (sem suporte) | 0 EUR |
| Total ano 1 (com suporte) | ~900 EUR |
PRTG Network Monitor
| Item | Custo |
|---|---|
| Licença freeware (100 sensores) | 0 EUR |
| PRTG 500 (500 sensores) | ~1 600 EUR/ano (subscription) |
| PRTG 1000 (1000 sensores) | ~2 800 EUR/ano (subscription) |
| Servidor (Windows Server) | Licença Windows Server (~700 EUR) |
| Suporte | Incluído na subscrição comercial |
| Total ano 1 (freeware 100 sensores) | ~700 EUR (apenas Windows Server) |
| Total ano 1 (PRTG 500) | ~2 300 EUR (licença + Windows Server) |
Os preços do PRTG podem variar conforme a região e promoções. Consulte paessler.com/pricing para cotações actualizadas. A versão freeware (100 sensores) é perpetua, mas não inclui suporte técnico oficial nem actualizações para novas versões — apenas corre a versão instalada no momento.
Nagios Core
| Item | Custo |
|---|---|
| Licença software | 0 (open-source GPL v2) |
| Servidor (VM com 1 vCPU, 2 GB RAM, 20 GB disco) | Custo da infraestrutura existente |
| Sistema operativo | 0 (Linux) |
| Plugins e add-ons | 0 (comunidade open-source) |
| Suporte comercial (opcional) | Não disponível para Core (apenas Nagios XI) |
| Total ano 1 | 0 EUR |
Nagios XI (alternativa comercial)
| Item | Custo |
|---|---|
| Licença Standard (até 1 000 nodes) | ~3 495 USD/ano |
| Licença Enterprise | ~5 995 USD/ano |
| Total ano 1 (Standard) | ~3 495 USD (~3 200 EUR) |
Resumo de Custos
| Solução | Custo Ano 1 | Custo Ano 2+ | Inclui Suporte |
|---|---|---|---|
| Zabbix (auto-hosted) | 0 EUR | 0 EUR | Não (opcional 900 EUR/ano) |
| PRTG Freeware (100 sensores) | ~700 EUR (Windows Server) | 0 EUR | Não |
| PRTG 500 | ~2 300 EUR | ~1 600 EUR | Sim |
| Nagios Core | 0 EUR | 0 EUR | Não |
| Nagios XI Standard | ~3 200 EUR | ~3 200 EUR | Sim |
Para uma PME com 25 dispositivos, o Zabbix e o Nagios Core são gratuitos. O PRTG freeware pode ser suficiente se o número de sensores for inferior a 100, mas 25 dispositivos com 5 sensores cada já excede o limite. A versão PRTG 500 resolve a limitação, mas introduz um custo anual recorrente.
10. Integração com Grafana e Troubleshooting Comum
Integração com Grafana
O Grafana é a plataforma de visualização mais popular para dados de monitorização. A integração com cada solução varia:
| Solução | Plugin Grafana | Tipo | Estado |
|---|---|---|---|
| Zabbix | Alexander Zobnin Zabbix App | DataSource | Oficial (comunidade) |
| PRTG | PRTG Data Source (comunidade) | DataSource | Experimental |
| Nagios Core | Via InfluxDB/Graphite intermediário | DataSource indirecto | Requer NDOMod |
A integração Zabbix + Grafana é a mais madura e amplamente utilizada. O plugin de Alexander Zobnin permite criar dashboards no Grafana que consomem dados directamente do Zabbix via API JSON RPC. Para instalar:
grafana-cli plugins install alexanderzobnin-zabbix-app
sudo systemctl restart grafana-server
Após a instalação, configurar o data source no Grafana:
- Ir a Configuration > Data Sources > Add data source
- Seleccionar “Zabbix”
- Definir URL:
http://servidor-zabbix/api_jsonrpc.php - Definir credenciais (utilizador e password do Zabbix)
- Em “Trends”, activar “Enable trends” para usar dados históricos agregados
O plugin no Grafana suporta alertas, annotations, métricas de problema e triggers do Zabbix directamente no Grafana. É possível criar dashboards híbridos que combinam dados do Zabbix com dados de outras fontes (Prometheus, InfluxDB, etc.) — algo que não é possível no interface nativo do Zabbix.
Para PRTG, a integração com Grafana é limitada. Existe um plugin experimental da comunidade, mas não é mantido activamente. A abordagem mais comum é exportar dados do PRTG via API REST e enviar para InfluxDB, que o Grafana consome como data source nativo.
Para Nagios Core, a integração com Grafana requer uma camada intermédia. O fluxo típico é: Nagios → NDOMod → InfluxDB/Graphite → Grafana. Alternativamente, pode-se usar o PNP4Nagios para gerar gráficos RRD e exportá-los. Esta integração é mais complexa e requer manutenção de múltiplos componentes.
Troubleshooting Comum
#### Zabbix
| Problema | Causa Provável | Solução |
|---|---|---|
| Agente não comunica | Firewall bloqueia porta 10050/TCP | sudo ufw allow 10050/tcp no host do agente |
| SNMP timeout | Community string incorrecta ou firewall | Verificar community string e acesso SNMP no dispositivo |
| Frontend mostra “Zabbix server is not running” | Servidor não arrancou ou DB password errada | Verificar /var/log/zabbix/zabbix_server.log e credenciais em zabbix_server.conf |
| Gráficos sem dados | Timezone errado entre servidor e agente | Sincronizar NTP em ambos: sudo timedatectl set-ntp true |
| Trigger não dispara | Expressão do trigger incorrecta | Testar com zabbix_get -s host -k item.key |
| Alto uso de CPU no servidor | demasiados processos poller | Reduzir StartPollers em zabbix_server.conf ou aumentar recursos |
| Disco cheio com histórico | Retenção demasiado longa | Reduzir HistoryStoragePeriod ou configurar particionamento de tabela |
Verificar comunicação agente-servidor:
zabbix_get -s 192.168.1.10 -k agent.version
# No agente, verificar se está a escutar
sudo ss -tlnp | grep 10050
#### PRTG
| Problema | Causa Provável | Solução |
|---|---|---|
| Sensores em estado “Down” sem motivo | WMI sem permissões suficientes | Configurar credenciais WMI com privilégios de administrador |
| Probe remoto não conecta | Firewall bloqueia porta 23560 | Abrir porta 23560/TCP entre Probe e servidor |
| Limite de 100 sensores atingido | Versão freeware | Remover sensores desnecessários ou actualizar para PRTG 500 |
| Interface web lento | demasiados sensores num único Probe | Distribuir sensores por múltiplos Probes |
| Notificações não chegam | SMTP mal configurado | Verificar em Setup > System Administration > Email |
| Sensores WMI lentos | Consultas WMI pesadas | Considerar instalar PRTG Probe no servidor Windows em vez de WMI remoto |
#### Nagios Core
| Problema | Causa Probável | Solução |
|---|---|---|
| “Error: Could not open config file” | Erro de sintaxe no ficheiro .cfg | Validar com nagios -v /usr/local/nagios/etc/nagios.cfg |
| Plugin retorna “No output” | Plugin não produz output válido | Testar plugin manualmente: /usr/local/nagios/libexec/check_* |
| NRPE: Connection refused | NRPE não está a correr ou firewall bloqueia | Verificar sudo systemctl status nagios-nrpe-server e porta 5666/TCP |
| NRPE: Could not complete SSL handshake | Versão NRPE incompatível ou SSL desactivado | Verificar dont_blame_nrpe e allowed_hosts em nrpe.cfg |
| Interface web mostra 403 | Permissões Apache incorrectas | sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin |
| Notificações não enviam | sendmail/postfix não configurado | Instalar e configurar postfix: sudo apt install postfix |
Verificar configuração do Nagios:
sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# Verificar estado do serviço
sudo systemctl status nagios
# Verificar log
sudo tail -f /usr/local/nagios/var/nagios.log
11. Guia de Decisão: Qual Escolher?
Escolher Zabbix se:
- A PME tem um sysadmin com conhecimento de Linux
- Se quer evitar custos de licenciamento
- Se precisa de dashboards e mapas de rede nativos sem add-ons
- Se prevê crescimento para mais de 100 dispositivos
- Se se quer integrar com Grafana para visualização avançada
- Se alta disponibilidade nativa é necessária
- Se a monitorização de serviços cloud via API é importante
Escolher PRTG se:
- A PME não tem sysadmin dedicado e precisa de setup rápido
- Há infraestrutura Windows Server disponível
- O número de sensores é inferior a 100 (freeware) ou orçamento permite licença comercial
- A simplicidade de configuração gráfica é prioridade
- Não há necessidade de personalização avançada
- Mapas georreferenciados são necessários
Escolher Nagios Core se:
- A PME tem conhecimento técnico de Linux e ficheiros de configuração
- Se quer a solução mais leve em recursos (funciona com 1 vCPU e 1 GB RAM)
- A flexibilidade de plugins é importante (4000+ plugins disponíveis)
- Se quer uma solução testada e estável há mais de 25 anos
- Não há necessidade de dashboards nativos (ou instalar NagVis)
- Se já existe conhecimento prévio do ecosistema Nagios
Quadro Resumo de Decisão
| Critério | Vencedor |
|---|---|
| Menor custo total | Zabbix / Nagios Core (empate) |
| Setup mais rápido | PRTG |
| Maior flexibilidade | Zabbix |
| Menor consumo de recursos | Nagios Core |
| Melhor integração com Grafana | Zabbix |
| Auto-discovery mais completo | Zabbix |
| Dashboards nativos | Zabbix |
| Comunidade e documentação | Zabbix |
| Estabilidade histórica | Nagios Core |
| Simplicidade para não-técnicos | PRTG |
Checklist Pré-Produção
- [ ] Definir lista completa de dispositivos a monitorizar (IP, tipo, protocolo)
- [ ] Verificar requisitos de hardware do servidor de monitorização (vCPU, RAM, disco)
- [ ] Instalar e actualizar o sistema operativo do servidor
- [ ] Configurar NTP em todos os dispositivos e servidor de monitorização
- [ ] Configurar SNMP em switches, routers e access points (preferencialmente v3)
- [ ] Abrir portas de firewall necessárias (10050/10051 Zabbix, 5666 NRPE, 161/162 SNMP, 23560 PRTG Probe)
- [ ] Instalar agentes nos servidores a monitorizar (Zabbix Agent 2 ou NRPE)
- [ ] Importar templates adequados para cada tipo de dispositivo
- [ ] Configurar auto-discovery e verificar dispositivos detectados
- [ ] Configurar alertas e notificações (email, Slack/Teams, webhook)
- [ ] Testar alertas: forçar um evento (ex.: parar um serviço) e confirmar notificação
- [ ] Configurar períodos de manutenção (downtime) para janelas de actualização
- [ ] Criar dashboards para equipas técnicas e gestão
- [ ] Criar mapa de rede com topologia visual
- [ ] Definir retenção de histórico (dias para dados detalhados vs agregados)
- [ ] Configurar backup da base de dados / configuração do servidor de monitorização
- [ ] Documentar procedimento de recuperação do servidor de monitorização
- [ ] Configurar HTTPS no interface web (certificado válido ou Let’s Encrypt)
- [ ] Alterar passwords predefinidas (Admin/zabbix, nagiosadmin)
- [ ] Configurar dependências entre hosts para evitar alertas em cascata
- [ ] Validar relatório de disponibilidade (SLA) após 7 dias de recolha
- [ ] Se integrar com Grafana: instalar plugin, configurar data source e testar
