Monitorizar o seu servidor

Módulo 8: Cópias de segurança e monitorização · Tempo de leitura: 10 minutos

Objetivo de aprendizagem: No final desta lição, saberá determinar o que monitoriza no seu servidor (do exterior e do interior), que limiares fazem sentido e como garantir que um alerta chega realmente até si sem ficar afogado em alertas.

Conceitos-chave: monitorização do exterior, monitorização do interior, uptime, verificação http, verificação de porta, expiração do certificado, espaço em disco, memória, load, heartbeat (dead man's switch), limiar, canal de alerta, fadiga de alarmes, gráficos do fornecedor

Porquê monitorizar?

Sem monitorização, fica a saber dos problemas através dos seus clientes, ou nem sequer fica a saber. Um site em baixo desde sábado, um certificado que expirou, um disco que encheu, uma cópia de segurança que falha silenciosamente há três semanas: tudo coisas que poderia ter visto a tempo. Monitorizar significa que um programa vigia continuamente e o avisa quando algo não está bem.

Uma boa monitorização responde a duas perguntas:

1. Funciona para o utilizador? Isso mede-se a partir do exterior.
2. Algo vai correr mal em breve? Isso mede-se no interior: disco, memória, atualizações, cópias de segurança.

Do exterior: o que o utilizador vê

A monitorização do exterior corre numa máquina diferente do seu servidor, de preferência noutro fornecedor. É lógico: se o seu servidor estiver em baixo, já não consegue avisar ninguém.

O certificado merece atenção especial. Os certificados Let's Encrypt têm uma validade curta e são renovados automaticamente (lição 7.3), mas se essa renovação falhar silenciosamente, só dá por isso quando os visitantes recebem um aviso. Desde junho de 2025, a própria Let's Encrypt deixou de enviar e-mails de lembrete sobre certificados a expirar e recomenda ela mesma a monitorização. Uma verificação de certificado que avise quando faltam menos de 14 dias de validade não é, portanto, um luxo.

Um programa habitual para fazer isto por conta própria é o Uptime Kuma, que irá instalar num contentor na lição 9.4. Nesse caso, de preferência não o coloque no mesmo servidor que deve monitorizar, ou combine-o com uma segunda verificação externa. Existem também serviços de terceiros que fazem o mesmo; escolha um que lhe convenha e verifique onde estão sediados se os alertas puderem conter dados dos seus clientes.

Do interior: o que vai correr mal em breve

Alguns problemas só se veem do exterior quando já é tarde demais. Esses medem-se no próprio servidor:

Pode fazer isto com um script simples e um temporizador (lição 6.3) que envia um alerta quando um limiar é ultrapassado, ou com um programa de monitorização com um agente no servidor (exemplos open source conhecidos são o Netdata e a combinação Prometheus com node_exporter). Comece pelo pouco: disco, serviços falhados e cópias de segurança apanham a maioria dos problemas.

Os gráficos no painel do seu fornecedor (processador, memória, rede, disco ao longo de um dia até um ano) são um ótimo complemento para ver tendências: se o seu disco cresce alguns por cento todos os meses, sabe quando ficará cheio. Na WebOké encontram-se no ecrã do VPS; noutros fornecedores, de forma semelhante. Normalmente não enviam alertas, pelo que não substituem a monitorização.

O heartbeat: alertar quando nada acontece

Algumas coisas devem ser monitorizadas precisamente pela ausência de um sinal. A cópia de segurança desta noite é o melhor exemplo: se o script nem sequer arrancar (temporizador desligado, servidor desligado, script avariado), também não surge nenhuma mensagem de erro.

A solução chama-se heartbeat ou dead man's switch: a sua monitorização espera um sinal todos os dias. No fim, e apenas se tudo tiver corrido bem, o script de cópia de segurança envia um pequeno pedido http para um URL fixo e secreto da sua monitorização:

restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/null

Se o sinal não chegar durante um dia, recebe um alerta. O Uptime Kuma tem para isso o tipo de monitor Push; existem também programas que pode alojar por conta própria, como o Healthchecks. Assim, com uma única linha, verifica se a sua cópia de segurança correu realmente.

Alertas que chegam, e não demasiados

Um alerta que ninguém lê não é monitorização. Trate de três coisas:

1. Um canal de alerta que vê realmente: uma notificação push no telemóvel, um canal de chat, SMS. O e-mail é possível, mas apenas se o seu servidor conseguir enviar e-mail de forma fiável, e o e-mail passa facilmente despercebido. Para os alertas mais importantes, utilize dois canais.
2. Não depender daquilo que monitoriza. Se é o próprio servidor a enviar o e-mail sobre um disco cheio, esse e-mail não chega quando o disco está cheio. A monitorização do exterior e um heartbeat resolvem isso.
3. Poucos, mas justificados. Se receber todos os dias dez alertas com os quais nada faz, acabará por ignorá-los, incluindo aquele que realmente importa. Chama-se a isto fadiga de alarmes. Defina os limiares de modo que um alerta signifique: tem de fazer alguma coisa. Faça com que um alerta só dispare após algumas verificações falhadas seguidas (por exemplo, três vezes), para que um único pacote perdido não o acorde.

Teste os seus alertas: desligue um serviço por momentos e veja se o alerta chega e quanto tempo demorou.

O que não deve fazer

• Páginas de monitorização abertas a todos com nomes e endereços internos. Uma página de estado pública é aceitável, mas mostre apenas o que os visitantes podem saber.
• Uma conta de administrador da sua monitorização sem palavra-passe forte e 2FA. Quem entrar na sua monitorização pode desativar os alertas.
• Agentes com mais permissões do que o necessário. Um agente de monitorização normalmente não precisa de ser root.

Resumo

• Monitorize do exterior se funciona (http, porta, certificado, DNS), a partir de outra máquina, e do interior se algo vai correr mal em breve (disco, memória, serviços, atualizações, cópias de segurança).
• Os certificados merecem uma verificação própria: desde junho de 2025, a Let's Encrypt deixou de enviar e-mails de lembrete.
• Um heartbeat alerta para a ausência de um sinal; ideal para cópias de segurança e tarefas agendadas.
• Escolha um canal de alerta que vê realmente, independente do próprio servidor, e defina limiares de modo que cada alerta exija uma ação.
• Os gráficos do seu fornecedor mostram tendências, mas normalmente não enviam alertas.

Questionário

Exercício

Exercício O8.3: A sua lista de monitorização. Elabore uma lista de monitorização para o seu próprio servidor: que verificações do exterior (com que intervalo e a partir de onde), quais do interior (com limiares), que heartbeat(s) e por que canal chegam os alertas. Configure pelo menos uma verificação externa de http ou de certificado e um heartbeat (por exemplo, para a sua cópia de segurança) e teste o alerta desligando um serviço por momentos. Anote quanto tempo demorou até o alerta chegar.

Para saber mais

• Deixou de ter acesso ao seu VPS: o que fazer?
• Let's Encrypt, Expiration Notification Service Has Ended: https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
• Uptime Kuma (GitHub): https://github.com/louislam/uptime-kuma
• VPS: do primeiro início de sessão a um servidor seguro 8.3: Monitorização a partir do exterior e do interior
• VPS: do primeiro início de sessão a um servidor seguro 7.1: Uptime Kuma: monitorizar os seus sites e o seu servidor