Teste protocol pgsql gera erros de autenticação no PostgreSQL Nas 5.x, sem credenciais o teste usa utilizador/base pré-definidos; nas 5.x também há um problema na interpretação de respostas malformadas (corrigido na 6.0.0) Usar teste TCP sem protocol (com credenciais desde a 5.29.0, se precisares do handshake) — ver secção 9 monit -t passa mas algo falha em execução O teste valida sintaxe, não operação — pidfiles, caminhos, endpoints e credenciais só se provam em execução Teste controlado de falha/recuperação + alerta real numa caixa que a equipa leia (checklist)

style=”font-family:Arial,sans-serif;font-size:26px;font-weight:700;color:#1a202c;line-height:1.3;margin:0 0 18px 0;”>Monit: Monitorização e Reparação Automática de Serviços Linux

Neste artigo:

1. Instalar o Monit
2. O monitrc base: ciclo, log e alertas globais
3. Vigiar um serviço local: check process
4. Serviços remotos: HTTPS, conteúdo e ping
5. Recursos do sistema: carga, memória e discos
6. Ficheiros, checksums e scripts
7. A interface web e a linha de comandos
8. Alertas por email: relay, formato e fila
9. Dependências, grupos e modo passivo
10. Erros Comuns
11. Checklist
12. Artigos Relacionados
13. Fontes Oficiais

Há duas formas de lidar com um serviço que morre: avisar alguém, ou reparar sozinho. As plataformas de monitorização centralizadas fazem bem a primeira — gráficos, histórico, alertas por email — mas um aviso às 03:12 só se lê às 09:00, e entretanto a aplicação esteve em baixo quase seis horas. Falta a peça que repara sem esperar por ninguém.

Essa peça é o Monit. É um agente open source que corre no próprio servidor Linux (também macOS, BSD e Solaris), vigia processos, ficheiros, portas e recursos num ciclo de 30 a 60 segundos e, quando algo falha, executa a acção configurada — reiniciar o serviço, correr um script, disparar um alerta — antes de acordar alguém. A configuração vive num único ficheiro com sintaxe própria, a interface web vem incluída e a instalação cabe num apt install.

Este guia parte de um Debian 12 ou 13 (ou Ubuntu LTS) e monta tudo: instalação, configuração base, vigilância de serviços e recursos, testes remotos de portas e HTTPS, alertas por email, interface web e dependências entre serviços. Os exemplos seguem o manual oficial do Monit e as configurações de exemplo dos autores. Nos repositórios, o Debian 12 traz a 5.33.0 e o Debian 13 a 5.34.3 (packages.debian.org, bookworm) — a versão actual a montante é a 6.0.0, de Junho de 2026 (novidades).

1. Instalar o Monit

O pacote traz o binário, o ficheiro de configuração e o serviço systemd:

sudo apt update
sudo apt install monit
monit -V

O monit -V imprime a versão instalada. Nos sistemas Debian o serviço corre a partir de /lib/systemd/system/monit.service e a configuração principal fica em /etc/monit/monitrc — é este o caminho nas distribuições Debian-like, e não o ~/.monitrc genérico que o manual lista como por omissão (ver tutorial de referência).

Antes de qualquer edição, uma regra que vale para todo o artigo: o Monit só lê o ficheiro de configuração depois de validar a sintaxe, e recusa-se a arrancar com erros. O monit -t é o gate de todas as alterações:

sudo monit -t

Control file syntax OK

Se houver erro, o Monit imprime a mensagem e o número da linha no monitrc. E atenção às permissões: o ficheiro tem de ficar com permissões iguais ou mais restritas que 0700 — o Monit queixa-se e sai caso contrário, porque o monitrc pode conter passwords:

sudo chmod 600 /etc/monit/monitrc

2. O monitrc base: ciclo, log e alertas globais

O monitrc do pacote vem quase todo comentado e serve de documentação. As linhas que sustentam o resto do artigo:

set daemon 60
    with start delay 30
set log /var/log/monit.log
set alert root@localhost
      but not on { instance, action }
set mail-format {
    from: monit@$HOST
    subject: [$SERVICE] $EVENT at $DATE
    message: $DESCRIPTION
        Servidor: $HOST
        Acção:    $ACTION
        Data:     $DATE
}
include /etc/monit.d/*.cfg

Linha a linha:

• set daemon 60 — o intervalo do ciclo de vigilância (sintaxe SET DAEMON <seconds>). Sem esta linha, o Monit corre os testes uma vez e sai — o modo daemon é o modo por omissão só quando esta linha existe.
• with start delay 30 — espera 30 segundos depois do reboot antes do primeiro ciclo, para não reiniciar serviços que o arranque ainda está a levantar. Por omissão o Monit começa a verificar imediatamente.
• set log — registo em ficheiro próprio, com syslog como alternativa (a forma antiga set logfile está deprecada).
• set alert — o destinatário global de todos os eventos. O filtro but not on { instance, action } silencia os eventos internos do próprio Monit (arranques, recargas), que de outra forma inundam a caixa de entrada.
• set mail-format — o formato do email. O Monit expande as variáveis $SERVICE, $EVENT, $DATE, $HOST, $ACTION e $DESCRIPTION em cada alerta.
• include — cada serviço pode viver num ficheiro separado (aceita globs, até 1024 ficheiros incluídos).

Depois de cada alteração ao monitrc: sudo monit -t e, sem erros, sudo systemctl restart monit — ou sudo monit reload para recarregar sem reiniciar o serviço.

3. Vigiar um serviço local: check process

A unidade básica do monitrc é o check. Este bloco vigia o nginx, reinicia-o se a porta 80 deixar de responder e desarma a vigilância se entrar em loop:

check process nginx with pidfile /run/nginx.pid
    start program = "/usr/bin/systemctl start nginx"
    stop program = "/usr/bin/systemctl stop nginx"
    if failed port 80 protocol http for 2 cycles then restart
    if 3 restarts within 5 cycles then unmonitor

• A pidfile tem de ser a que o serviço realmente escreve — no nginx de Debian é a directiva pid /run/nginx.pid no nginx.conf. Quando o serviço não cria pidfile (o sshd do systemd, por exemplo, corre sem daemonizar), usa-se a forma matching, que procura o processo por padrão: check process sshd matching "/usr/sbin/sshd". O Monit confirma sempre que o PID no ficheiro pertence a um processo vivo — um PID deixado por um crash não engana o teste, que também detecta processos zombie (FAQ oficial).
• start/stop recebem o caminho absoluto de um executável. O Monit usa a chamada execv e não é uma shell: pipes e && não funcionam directamente — para composições, embrulhar em /bin/bash -c 'comando && comando'.
• for 2 cycles exige duas falhas consecutivas antes da acção. Sem ele, uma falha isolada de um ciclo dispara o restart à toa.
• A guarda if 3 restarts within 5 cycles then unmonitor é o travão do loop infinito: se o serviço cair, for reiniciado e voltar a cair três vezes em cinco ciclos, o Monit desarma a vigilância em vez de reiniciar para sempre. Nota: desarmar também significa deixar de tentar reparar — o serviço fica sem reparação automática até alguém assumir o alerta, corrigir e reactivar com sudo monit monitor nginx. Para voltar a vigiar: sudo monit monitor nginx.

Um teste extra com valor de segurança — avisar quando o PID muda entre dois ciclos, sinal de que alguém reiniciou o serviço fora do controlo do Monit (o exemplo do manual usa-o no sshd):

check process sshd matching "/usr/sbin/sshd"
    if changed pid then alert

4. Serviços remotos: HTTPS, conteúdo e ping

Para vigiar serviços que não vivem no mesmo servidor usa-se check host. O exemplo valida o certificado TLS de um site e responde ao ping:

check host web-publico with address www.exemplo.pt
    if failed
        port 443
        protocol https
        with ssl options {verify: enable}
    then alert
    if failed ping with timeout 10 seconds then alert

• check host testa serviços remotos — não existe pidfile nem start/stop, só testes de rede e a acção (tipicamente alert).
• with ssl options {verify: enable} liga a validação do certificado TLS — por omissão o Monit não exige certificados válidos (exemplo do manual).
• O ping envia ICMP e tolera perda de pacotes até certo limite. Nota do manual para redes reais: muitos operadores filtram ICMP, e nesse caso o teste falha sempre — o aviso de indisponibilidade seria um falso permanente.

Também se pode exigir conteúdo na resposta, não só a porta aberta:

check host api with address api.exemplo.pt
    if failed
        port 443
        protocol https with ssl options {verify: enable}
        request "/health"
        with content = "OK"
        for 2 cycles
    then alert

• request pede um documento específico (por omissão é /) e with content exige um padrão no corpo da resposta — a API pode estar de pé e a devolver erros na mesma. No bloco da API, o with content = "OK" procura um padrão no corpo da resposta — não valida a resposta da aplicação como um todo: um endpoint de saúde deve devolver conteúdo inequívoco (evitar páginas de manutenção que devolvem 200 com HTML genérico). O with ssl options {verify: enable} repete a validação do certificado neste teste — quem copiar só este bloco obtém a mesma garantia do bloco anterior.
• O Monit trata respostas com status HTTP de 400 ou superior como falha. Para o caso inverso — uma página que deve devolver 404 — o manual mostra o status = 404 a inverter o teste.

5. Recursos do sistema: carga, memória e discos

O check system vigia o servidor como um todo e o check filesystem os pontos de montagem:

check system $HOST
    if loadavg (1min) per core > 2 for 5 cycles then alert
    if loadavg (5min) per core > 1.5 for 10 cycles then alert
    if cpu usage > 95% for 5 cycles then alert
    if memory usage > 90% then alert
    if swap usage > 25% then alert

check filesystem rootfs with path /
    if space usage > 85% then alert
    if inode usage > 85% then alert

• $HOST expande para o nome da máquina — é o nome que aparece nos alertas e na interface web. Sem DNS, escrever directamente uma string descritiva.
• per core normaliza o load average pelo número de cores do CPU — sem ele, os limiares teriam de acompanhar o hardware de cada servidor.
• O check filesystem mede espaço e inodes: sistemas com milhões de ficheiros pequenos podem esgotar inodes com disco livre, e o teste de espaço não apanha o caso.
• O valor máximo de ciclos por teste é 64 — limiares que exijam janelas maiores têm de usar outra estratégia (por exemplo, um check program com lógica própria).

Duas notas das release notes da 6.0.0: a memória por processo passa a reportar-se em PSS (memória partilhada dividida pelos processos que a usam) em vez de RSS — o limiar if memory usage > 90% do check system continua a medir a memória do sistema como antes, não passa a medir PSS — os valores baixam em relação a versões anteriores, mas reflectem melhor a contribuição real de cada processo. E há testes novos de actividade de swap (pagein/pageout), com a regra prática dos autores: até 10 páginas por segundo é paginação menor, acima de 100 sustentadas é pressão de memória, acima de 1000 é thrashing — por exemplo if pageout > 50 per second for 20 cycles then alert num check system. Estes dois testes são da 6.0.0: nos pacotes do Debian 12/13 (5.33.0/5.34.3) a sintaxe pagein/pageout não existe — é preciso compilar a versão a montante ou escolher outro teste.

6. Ficheiros, checksums e scripts

O mesmo agente serve de watchdog de segurança: vigiar que binários e configurações não mudam.

check file sshd_config with path /etc/ssh/sshd_config
    if failed sha1 checksum then alert
    if failed permission 644 then unmonitor
    if failed uid root then unmonitor

• checksum falhado significa que o conteúdo mudou — alguém editou ou substituiu o ficheiro. Desde a 6.0.0 o hash por omissão é SHA256 (antes MD5), com md5, sha1 ou sha256 à escolha.
• permission, uid e gid apanham alterações de permissões e de dono — o padrão dos exemplos dos autores é unmonitor nestes testes, para o Monit deixar de vigiar um ficheiro que foi adulterado. Consequência que interessa: depois de desarmado, o Monit deixa de verificar esse ficheiro — alterações posteriores já não disparam este teste até alguém investigar o alerta e reactivar com sudo monit monitor sshd_config.
• O padrão de segurança do manual para binários é mais duro: if failed checksum then unmonitor num executável faz o Monit deixar de o vigiar — e, com depends on (secção 9), os serviços que dele dependem param também — em vez de arriscar executar um binário substituído.

Para logs que devem ter actividade, o teste de timestamp:

check file syslog with path /var/log/syslog
    if timestamp is older than 1 hour then alert

E o check program corre um script e avalia o código de saída — é a porta para qualquer lógica própria:

check program verifica_backup with path /usr/local/bin/verifica-backup.sh
    every "30 6 * * *"
    if status != 0 then alert

• status != 0 dispara quando o script sai com erro — o exit code é todo o contrato.
• O timeout por omissão é 300 segundos: um script que demore mais é morto e gera um evento de timeout. Muda-se com with timeout N seconds.
• O every aceita expressão cron já nas versões 5.x; a 6.0.0 melhorou a precisão ao minuto e a garantia de execução única por ocorrência (antes, quando o ciclo de polling se desalinhava, o teste podia ser saltado) — em 5.x a mesma expressão funciona, mas sem essa garantia. A forma simples every 5 cycles continua válida para espaçar testes.
• Um clássico do género: a saúde SMART dos discos, com o pacote smartmontools instalado — check program disco_sda with path "/usr/sbin/smartctl -H /dev/sda" e if status != 0 then alert (o smartctl sai com código não-zero quando o disco falha o teste de saúde).

7. A interface web e a linha de comandos

A interface web está incluída e ativa-se com um bloco:

set httpd port 2812
    use address 127.0.0.1
    allow admin:"PalavraPasse"

• use address 127.0.0.1 liga a interface apenas ao loopback — sem esta linha, o Monit fica acessível em todas as interfaces do servidor. Para acesso remoto por rede, os allow aceitam também redes inteiras (allow 192.168.1.0/255.255.255.0) e o bloco SSL com pemfile para HTTPS.
• Os mesmos allow criam utilizadores read-only (allow operador:senha read-only) — vêem tudo mas não têm botões de start/stop — e grupos PAM (allow @admins).
• Quem preferir não abrir porta nenhuma usa socket Unix: set httpd unixsocket /var/run/monit.sock com allow utilizador:senha.

Do exterior, um túnel SSH chega para o loopback:

ssh -L 2812:127.0.0.1:2812 admin@servidor

Depois é abrir http://localhost:2812 no browser: estado de cada serviço, histórico de eventos e os botões de start/stop/restart.

A web é também a base da linha de comandos — monit status, monit summary, monit restart nginx, monit unmonitor nginx falam com o daemon na porta TCP 127.0.0.1:2812 por omissão (ou no socket). Sem HTTP activo, a maioria destes comandos fica sem funcionalidade — os autores recomendam expressamente manter o HTTP activo e ligado ao localhost quando a segurança preocupa.

8. Alertas por email: relay, formato e fila

Os alertas do monitrc da secção 2 precisam de um relay SMTP:

set mailserver smtp.exemplo.pt
    port 587
    username "[email protected]"
    password "PalavraPasse"
    using SSL with options {verify: enable}

• A porta 587 por si só não garante transporte protegido: o using SSL é o que obriga à negociação TLS e o valida o certificado do servidor — a verificação vem desactivada por omissão nas opções SSL do Monit. Confirma as opções com o teu relay (STARTTLS na 587 ou SMTPS na 465) e testa a entrega real para uma caixa que a equipa leia — o root@localhost da secção 2 serve no servidor local, mas com um relay externo não se pode presumir que seja aceite ou entregue. Vários servidores separados por vírgula fazem failover — o Monit tenta o primeiro e passa ao seguinte se estiver em baixo (set mailserver smtp.exemplo.pt, smtp2.exemplo.pt).
• O timeout por omissão da ligação SMTP é 30 segundos.

set alert [email protected] only on { nonexist, timeout, resource, connection }
set alert root@localhost but not on { instance, action }

set eventqueue basedir /var/monit slots 5000

check process postgresql with pidfile /var/run/postgresql/12-main.pid
    start program = "/usr/bin/systemctl start postgresql"
    stop program = "/usr/bin/systemctl stop postgresql"
    group base-dados
    if failed host 127.0.0.1 port 5432 then restart

check process nginx with pidfile /run/nginx.pid
    start program = "/usr/bin/systemctl start nginx"
    stop program = "/usr/bin/systemctl stop nginx"
    group web
    depends on postgresql
    if failed port 80 protocol http for 2 cycles then restart