Monitorização: o mínimo que vale a pena num servidor pessoal
Num servidor pessoal não vai haver observabilidade. Não há tempo, não há necessidade, e montar três contentores de métricas para um blogue é um passatempo — legítimo, mas é um passatempo e não monitorização.
O objetivo é mais modesto e mais útil: saber antes de quem visita. E isso cabe em três perguntas.
1. Está de pé?
É a que falha primeiro, a mais fácil de responder, e a que quase todos respondem mal — porque põem a verificação dentro da máquina que querem verificar.
Aconteceu aqui, e serve de exemplo: o servidor ficou inacessível e o que se via era que as portas 22, 80, 443 e 5432 estavam todas mortas ao mesmo tempo, enquanto o router respondia. Quatro serviços independentes não avariam juntos — aquilo não era o Postgres nem o proxy, era a máquina. E tudo o que estivesse a correr nela para avisar estava morto também.
Daí a única regra que importa nesta pergunta: a verificação tem de vir de fora. Um serviço externo a bater no endereço público, a cada poucos minutos. É a peça que, se tivesse de existir uma só, seria esta.
E no endereço público, não no IP: assim o mesmo teste cobre o DNS, o certificado e o proxy, que são três das causas mais comuns de o site estar em baixo com a máquina perfeitamente de pé.
2. Está a servir?
De pé e a servir são coisas diferentes — é o assunto do artigo dos healthchecks. Para a monitorização o que interessa é onde bater: num caminho que responda depressa e não faça trabalho.
export function GET() {
return Response.json({ ok: true, uptime: process.uptime() });
}Este, de propósito, não toca na base de dados. Um healthcheck que consulta o Postgres faz o contentor ser reiniciado sempre que a base tem um soluço, e transforma uma indisponibilidade de dez segundos num ciclo de reinícios que dura até alguém intervir. O estado da base é uma pergunta legítima — mas é outra pergunta, e não deve poder matar o processo.
3. Está a ficar sem quê?
Esta é a mais valiosa, porque é a única que avisa antes. Há exactamente duas coisas que derrubam servidores pessoais, e as duas são previsíveis com dias de antecedência:
O disco. Registos que ninguém roda, imagens antigas do Docker, cópias de segurança a acumular. E um disco cheio não dá um erro honesto — dá sintomas que não se parecem com a causa, como no artigo das armadilhas do espaço em Linux.
O certificado. Renova-se sozinho até ao dia em que não renova, e o aviso que interessa é o dos trinta dias, não o do dia seguinte ao fim.
Um limiar em cada um destes, e está feita a parte que realmente poupa madrugadas.
4. O que não vale a pena montar
Métricas que nunca ninguém vai olhar. Um painel com quarenta gráficos num servidor pessoal é trabalho de instalação que nunca mais é lido, e dá a sensação confortável de estar coberto.
E, pior, alertas sobre os quais não se age. Um aviso que chega todas as semanas e que não tem resposta treina a ignorar o canal — e no dia em que chegar o que importava, chega ao mesmo sítio onde os outros foram ignorados. Um alerta a que não se responde é pior do que nenhum, porque gasta a credibilidade do aviso.
O critério para acrescentar um: há alguma coisa que eu faria às três da manhã por causa disto? Se não houver, é um gráfico, não é um alerta.
5. O mínimo, em concreto
Verificação externa do endereço público, a bater no caminho de saúde.
Limiar de espaço em disco.
Aviso de validade do certificado, com antecedência de semanas.
Rotação dos registos configurada, que é o que evita o alarme do disco em primeiro lugar.
E uma cópia de segurança que já foi restaurada ao menos uma vez — porque a que nunca foi testada é uma suposição, como no artigo da regra 3-2-1.
O resumo
De fora, não de dentro. No nome, não no IP. Num caminho que não faça trabalho nem possa matar o processo. E só o que se tivesse de agir a seguir.
O resto é passatempo — e a prova é simples: enquanto não existir a verificação externa, a forma de descobrir que o servidor está em baixo continua a ser tentar usá-lo.