Monitorix: Monitorização Leve de Sistemas Linux

Um servidor pequeno — uma VPS, uma Raspberry Pi a fazer de gateway, uma máquina de testes — raramente justifica uma plataforma de monitorização com agentes e dashboards. Mas ignorá-lo também não é opção: um disco que enche, uma carga anormal, uma porta morta — um gráfico de 48 horas mostra tudo em segundos.

Neste artigo:

  1. Instalar o Monitorix
  2. A configuração: monitorix.conf e conf.d
  3. Os gráficos no browser: a porta 8080
  4. Escolher os gráficos: graph_enable, system e proc
  5. Discos e pontos de montagem: o módulo fs
  6. Rede: net, netstat e portas
  7. Processos: o módulo process
  8. Alertas por email: limiares e script
  9. Relatórios automáticos e Multihost
  10. Erros Comuns
  11. Checklist
  12. Artigos Relacionados
  13. Fontes Oficiais

O Monitorix faz esse trabalho intermédio: open source (GPLv2), escrito em Perl, criado para servidores Linux/UNIX em produção e até dispositivos embedded. Recolhe estatísticas para ficheiros RRD e serve os gráficos num servidor HTTP incluído — desde a versão 3.0 nem precisa de Apache ou Nginx (monitorix.org). Configuração num único ficheiro, instalação num comando.

Este guia parte de um Debian 12 ou 13 (ou Ubuntu LTS), com a variante Fedora/RHEL/Rocky via EPEL, e monta tudo: instalação, monitorix.conf e conf.d, os gráficos na porta 8080, os módulos system, fs, net e process, alertas por email e relatórios. A versão estável actual é a 3.16.0, de Novembro de 2024 — o Debian 13 e o EPEL 9 trazem-na; o Debian 12 e o Ubuntu 24.04 distribuem a 3.15.0.

1. Instalar o Monitorix

Em Debian e derivadas o pacote está nos repositórios oficiais desde o Debian 10 “Buster” — a página oficial de downloads diz para usar directamente o apt:

sudo apt update
sudo apt install monitorix

A versão varia com a distribuição: 3.15.0-1 no Debian 12 e no Ubuntu 24.04, 3.16.0-1 no Debian 13 “trixie” (packages.debian.org, packages.ubuntu.com). O pacote traz o daemon, a configuração e o serviço systemd, que arranca na instalação (doc Debian). Confirmar a versão e o arranque no boot:

monitorix -v
sudo systemctl enable --now monitorix

Em Fedora, RHEL e Rocky vive no EPEL — 3.16.0 no ramo EPEL 9 (downloads):

sudo dnf install epel-release
sudo dnf install monitorix

2. A configuração: monitorix.conf e conf.d

O daemon lê /etc/monitorix/monitorix.conf (em FreeBSD, /usr/local/etc/monitorix.conf) e, a seguir, tudo o que estiver em /etc/monitorix/conf.d/ — as opções dos ficheiros posteriores sobrepõem-se às anteriores — é a documentação oficial do Monitorix, a man page do monitorix.conf, que o diz. O registo principal vai para /var/log/monitorix; se log_file ficar vazio, sai pelo journal (journalctl -u monitorix).

O pacote Debian traz já um conf.d/00-debian.conf com opções adaptadas à distribuição, carregado depois do principal e por isso capaz de reescrever algumas delas (doc Debian).

A recomendação oficial é não editar o monitorix.conf: criar antes um conf.d/local.conf só com as secções alteradas. A regra, segundo a FAQ, é redeclarar a secção alterada e, dentro dela, a subsecção que muda por inteiro, com todas as suas opções — as restantes subsecções conservam os valores do monitorix.conf. No exemplo do gensens da FAQ, mudar uma linha da subsecção <list> exige redeclarar <gensens> e a <list> completa; o resto do bloco fica no principal. A vantagem: as actualizações do pacote nunca colidem com as alterações locais (FAQ).

A sintaxe é de estilo Perl: secções entre ângulos, valores com =, comentários com # e blocos inteiros comentáveis com / … /. Depois de qualquer alteração, reiniciar o serviço — o sinal SIGHUP só reabre o log, não relê a configuração (monitorix(8)):

sudo systemctl restart monitorix

3. Os gráficos no browser: a porta 8080

O servidor HTTP embutido vem activo por omissão na porta 8080/TCP: basta abrir o endereço http://localhost:8080/monitorix no browser. O bloco que o controla no monitorix.conf:

Interface web do Monitorix com gráficos de carga do sistema, memória e processos
Interface web do Monitorix: os gráficos RRDtool de carga do sistema, memória, processos, entropia e uptime, gerados no próprio servidor.
<httpd_builtin>
	enabled = y
	host =
	port = 8080
	user = nobody
	group = nobody
	log_file = /var/log/monitorix-httpd
	hosts_deny =
	hosts_allow =
	autocheck_responsiveness = y
	<auth>
		enabled = n
		hosts_deny = all
		msg = Monitorix: Restricted access
		htpasswd = /var/lib/monitorix/htpasswd
	</auth>
</httpd_builtin>
  • host vazio liga o servidor a todas as interfaces; um endereço (127.0.0.1) restringe o acesso à própria máquina.
  • hosts_deny/hosts_allow seguem a lógica dos TCP-Wrappers: a pesquisa para no primeiro match — comportamento dos TCP-Wrappers clássicos.
  • autocheck_responsiveness = y mitiga uma fraqueza conhecida do servidor embutido, que pode bloquear sob pedidos hostis: a cada minuto verifica a resposta e reinicia sozinho sem ela — uma auto-protecção do servidor HTTP embutido.

Sem autenticação por omissão. Se o 8080 fica acessível além do localhost, activar o bloco <auth>: autenticação Basic, ficheiro de passwords gerado com o htpasswd.pl do pacote (ou o htpasswd do Apache) e hosts_deny = all — tudo o que não estiver em hosts_allow tem de se autenticar. Duas regras do manual: o crypt() usa só os primeiros 8 caracteres da password, e o : é proibido por ser o separador.

⚠ ⚠️ **Atenção

** expor a porta 8080 para fora sem o bloco <auth> activo é deixar abertos a qualquer pessoa os gráficos do servidor — tráfego, portas à escuta, utilizadores ligados.

4. Escolher os gráficos: graph_enable, system e proc

Cada módulo activa-se com um y na secção <graph_enable>. A configuração de origem traz dez ligados por omissão — system, kern, proc, fs, net, netstat, serv, port, user e int — e todo o resto desligado. O gráfico system mostra o load average (1, 5 e 15 minutos), a alocação de memória, os processos activos, a entropia e o uptime; o kern o uso global do kernel; o proc abre um gráfico por núcleo de CPU.

Duas armadilhas do proc.pm: o max define o número de núcleos e vem por omissão com 4 — num servidor maior há que ajustar; e cada mudança redimensiona o ficheiro proc.rrd e apaga o histórico guardado nele.

Nos primeiros minutos a página pode não mostrar dados — os gráficos demoram a encher (FAQ). A página refresca-se a cada 150 segundos (refresh_rate) e um duplo clique amplia qualquer gráfico (enable_zoom).

5. Discos e pontos de montagem: o módulo fs

O fs.pm vigia a ocupação e a actividade I/O dos sistemas de ficheiros. O <list> usa os mesmos nomes que a saída do df — com o swap como caso especial — e cada grupo de até 8 sistemas de ficheiros origina um gráfico:

<fs>
	<list>
		0 = /, swap, /boot, /home, /mnt/backup
	</list>
	<desc>
		/ = Root
		/mnt/backup = Backups
	</desc>
	<devmap>
		/home = /dev/mapper/vg0-home
	</devmap>
</fs>
  • No bloco, desc muda o rótulo do ponto de montagem no gráfico — “/ = Root” faz o disco de sistema aparecer como “Root” em vez de “/”.
  • devmap resolve os casos em que o Monitorix não detecta sozinho o dispositivo por trás do ponto de montagem — no exemplo, liga /home ao volume lógico /dev/mapper/vg0-home; o nome tem de existir em /proc/diskstats, a tabela de discos que o kernel expõe.

⚠ ⚠️ **Atenção

** cada vez que muda o número de grupos no <list>, o Monitorix redimensiona o fs.rrd e apaga todo o histórico guardado. Definir bem os grupos à primeira.

6. Rede: net, netstat e portas

O net.pm mede o tráfego por interface. Os nomes do list são os do ip link e cada entrada do <desc> leva descrição e os valores rigid e limit da escala:

<net>
	max = 10
	list = eth0, enp1s0
	<desc>
		eth0 = LAN 1GbE, 0, 1000
		enp1s0 = WAN Fibra, 0, 1000
	</desc>
	gateway = eth0
</net>

O gateway identifica a interface de saída — a referência dos relatórios de tráfego Internet (traffacct). O netstat.pm conta as ligações por estado com cmd = ss (por omissão) ou cmd = netstat.

O port.pm é o mais exigente: precisa do iptables, onde o Monitorix acrescenta as suas regras de contagem (tabela filter por omissão). O mesmo porto em TCP e UDP distingue-se por sufixos (53t e 53u). O último campo do <desc>, o L, marca a porta como “deve estar à escuta”: sem daemon a responder, o fundo do gráfico fica vermelho — um serviço parado salta à vista (documentado no módulo port.pm):

<port>
	max = 9
	list = 22, 80, 443, 53t, 53u
	<desc>
		22 = SSH, tcp, in, 0, 1000, L
		80 = HTTP, tcp, in, 0, 1000, L
		443 = HTTPS, tcp, in, 0, 1000, L
		53t = DNS, tcp, in, 0, 1000, L
		53u = DNS, udp, in, 0, 1000, L
	</desc>
</port>

Em IPv6, os protocolos tcp6 e udp6 fazem o mesmo com o ip6tables (opção ipv6_disabled = n por omissão).

7. Processos: o módulo process

O process.pm segue processos por nome, com a mesma lógica de grupos do fs — até 10 processos por grupo e um gráfico por grupo. A procura usa o ps -eo pid,comm,command, logo os nomes são os da coluna comm (ou um substring do comando completo):

<process>
	<list>
		0 = nginx, sshd, postgresql, php-fpm
	</list>
	<desc>
		postgresql = PostgreSQL
	</desc>
	time_unit = hour
</process>

Atenção ao interruptor: por omissão o módulo vem desligado — no <graph_enable> mude process = n para process = y. Caso contrário os gráficos de processos não aparecem, por mais que o bloco <process> esteja configurado. É o mesmo esquema dos outros gráficos: dez módulos activos por omissão, todo o resto desligado.

Cada processo ganha gráficos de instâncias, memória, CPU e uptime. A contabilidade de I/O por processo exige kernel ≥ 2.6.20 (documentado no módulo process.pm). O time_unit muda a unidade do gráfico de uptime — minute, hour ou day (por omissão day). Como nos outros módulos, mudar o número de grupos redimensiona o process.rrd e limpa o histórico.

8. Alertas por email: limiares e script

Os alertas por gráfico seguem um padrão comum: intervalo de tempo, limiar e script externo que corre quando o valor se mantém excedido durante esse intervalo. O script recebe três argumentos — intervalo, limiar e valor actual no disparo, conforme a documentação dos alertas.

O alerta de carga vive no system.pm e vigia o menor entre os loads de 5 e 15 minutos (min($load5, $load15) no código) — um pico curto de 5 minutos não dispara sozinho, e a carga a descer cancela mais cedo:

<system>
	<alerts>
		loadavg_enabled = y
		loadavg_timeintvl = 600
		loadavg_threshold = 4.0
		loadavg_script = /usr/local/bin/system.loadavg-alert.sh
	</alerts>
</system>

Leitura: o menor dos loads de 5 e 15 minutos acima de 4.0 durante 600 segundos dispara o script — no system.pm, o valor testado é min($load5, $load15), não o de 15 minutos sozinho. Por omissão vem desligado (loadavg_enabled = n), com limiar 5.0 e intervalo de 3600 segundos.

O mesmo esquema no fs, agora sobre o percentual de ocupação de cada sistema de ficheiros:

<fs>
	<alerts>
		/ = 3600, 90, /usr/local/bin/fs-root-alert.sh
	</alerts>
</fs>

Aqui: a partição / acima de 90% durante uma hora dispara o script com o valor de ocupação — cada sistema de ficheiros da lista tem o seu alerta.

O pacote traz um script de exemplo pronto a adaptar — no Debian, /usr/share/doc/monitorix/examples/monitorix-alert.sh. O truque é um único script com symlinks: o prefixo do nome do symlink (tudo antes do primeiro hífen) entra no assunto do email e identifica a origem do alerta (script oficial):

sudo cp /usr/share/doc/monitorix/examples/monitorix-alert.sh /usr/local/bin/
sudo chmod 755 /usr/local/bin/monitorix-alert.sh
sudo ln -s monitorix-alert.sh /usr/local/bin/system.loadavg-alert.sh
sudo ln -s monitorix-alert.sh /usr/local/bin/fs-root-alert.sh

O envio usa o comando mail e o destinatário define-se em MAILTO dentro do script — o servidor precisa de um MTA (ou de um mailx apontado a um relay) para os alertas chegarem.

9. Relatórios automáticos e Multihost

Para além dos alertas por limiar, o emailreports envia em horário fixo um relatório com os gráficos escolhidos:

<emailreports>
	enabled = y
	url_prefix = http://localhost:8080
	smtp_hostname = localhost
	from_address = [email protected]
	hour = 7
	minute = 30
	<daily>
		enabled = y
		graphs = system, fs, net
		to = [email protected]
	</daily>
	<weekly>
		enabled = n
		graphs = system, fs
		to = [email protected]
	</weekly>
</emailreports>

O funcionamento: o Monitorix vai buscar os gráficos ao url_prefix (o mesmo endereço do browser), compõe o relatório e entrega-o por SMTP no smtp_hostname. O enabled global não chega — cada intervalo (daily, weekly, monthly, yearly) tem o seu próprio interruptor. O diário sai à hora de hour e minute (por omissão 00:00); o semanal na primeira segunda-feira, o mensal no primeiro dia do mês, o anual no primeiro dia do ano.

Se a autenticação do ponto 3 estiver activa, o url_prefix aceita credenciais embutidas (http://utilizador:palavrapasse@localhost:8080) — ou, mais limpo, 127.0.0.1 no hosts_allow do <auth>, que contorna a autenticação para a própria máquina.

Para testar sem esperar pelo horário, o daemon tem o envio pontual (monitorix(8)):

sudo monitorix -c /etc/monitorix/monitorix.conf -e report=daily,graphs=system+fs,[email protected]

Para vigiar vários servidores a partir de um só ecrã, o modo Multihost agrega os gráficos de servidores remotos com o Monitorix instalado — regra dura: a mesma versão em todos, senão os gráficos não aparecem correctamente — está documentado na secção Multihost da documentação oficial.

Erros Comuns

Sintoma Causa provável Correcção
Gráficos sem dados nos primeiros minutos Comportamento normal: a recolha começa no arranque Esperar — os gráficos demoram a mostrar actividade (FAQ)
Só o esqueleto da página, sem gráficos Servidor web sem permissão de escrita em /imgs Corrigir a propriedade/permissões do directório (FAQ)
“The requested URL / was not found” no servidor embutido URL usado não coincide com base_url e base_cgi Alinhar as duas opções com o URL real (FAQ)
500 Internal Server Error com Apache/Nginx pela frente Servidor externo e httpd_builtin ambos activos httpd_builtin enabled = n e reiniciar (FAQ)
Histórico dos gráficos desapareceu Mudou o número de grupos no fs/process ou o max do proc Documentado: o .rrd redimensiona e perde o histórico
Alerta de load ou de disco nunca dispara loadavg_enabled = n, script sem execução ou caminho relativo Activar o alerta, chmod 755 e caminho absoluto no *_script
Emails dos relatórios não chegam smtp_hostname sem relay ou secção desligada Apontar o relay SMTP e activar enabled = y no intervalo
port.pm sem dados Falta o iptables Instalar o iptables — o módulo acrescenta regras na tabela filter
Faltam gráficos de núcleos CPU proc.pm max = 4 por omissão Ajustar o max ao número real de cores (apaga histórico)

Checklist

  • [ ] monitorix -v mostra a versão e o serviço está activo
  • [ ] http://localhost:8080/monitorix abre a página principal
  • [ ] Configuração local em conf.d/local.conf, sem editar o monitorix.conf
  • [ ] <auth> activo se o 8080 sai do localhost
  • [ ] proc max igual ao número real de núcleos
  • [ ] fs <list> com os pontos de montagem reais do df (máx. 8 por grupo)
  • [ ] net <list> com as interfaces reais e o gateway correcto
  • [ ] process <list> com os serviços críticos do servidor
  • [ ] port.pm com a flag L nas portas sempre à escuta
  • [ ] Alertas de load e disco activos, script executável, caminho absoluto
  • [ ] emailreports com relay SMTP, testado com monitorix -e

Artigos Relacionados

Fontes Oficiais