C’è una convinzione abbastanza diffusa nel mondo sysadmin: per monitorare bene un’infrastruttura servono dashboard scintillanti, stack complessi e licenze costose.

Poi arrivi in produzione, magari con zero budget, e scopri una cosa molto più semplice: non ti serve tutto questo.

Ti serve capire cosa sta succedendo.

Il punto di partenza: tre domande fondamentali

Quando gestisco un server (o un piccolo cluster), alla fine tutto si riduce sempre a tre domande:

• Il server è vivo?
• È in salute?
• Sta per rompersi?

Se riesci a rispondere rapidamente a queste tre, sei già messo meglio di tanti setup “enterprise”.

Questa filosofia emerge chiaramente anche nel documento che ho letto recentemente: il focus non è sui grafici, ma sulla capacità di interpretare lo stato del sistema.

E onestamente, sono d’accordo.

CPU, RAM e carico: i segnali deboli

La maggior parte dei problemi nasce sempre dagli stessi punti:

• CPU saturata
• memoria esaurita
• swap che inizia a lavorare troppo
• load average fuori controllo

Qui non serve reinventare nulla. I classici strumenti bastano e avanzano:

top
htop
free -m
uptime

Il trucco non è usarli. Il trucco è sapere cosa è “normale” per il tuo sistema.

Se hai 4 core e un load average che resta sopra 6 per minuti, non è più un picco: è un problema.

Disco pieno: il killer silenzioso

Se c’è una cosa che mi ha fatto perdere tempo negli anni, è il disco pieno.

Quando succede:

• i log smettono di scrivere
• i database iniziano a comportarsi male
• i servizi falliscono… senza dirlo chiaramente

E spesso te ne accorgi troppo tardi.

Due comandi, sempre:

df -h
du -sh /var/log/*

La differenza la fa l’automazione. Un semplice script schedulato (cron o systemd timer) che controlla la soglia, diciamo 80% e manda un alert, ti salva la giornata.

Non è elegante. Ma funziona.

I log: il futuro scritto in anticipo

Una cosa che ho imparato col tempo: i log non servono per il post-mortem.

Servono per prevenire.

File come:

• /var/log/syslog
• /var/log/messages
• log applicativi
• log del web server

raccontano cosa sta per succedere.

Gli strumenti? Sempre quelli:

tail -f
grep
journalctl -xe

Se inizi a vedere errori ripetuti, connessioni fallite, timeout, retry continui il problema è già in corso. Devi solo accorgertene.

Servizi: meglio prevenire che riavviare alle 3 di notte

Altra lezione semplice: i servizi non sempre “cadono in modo rumoroso”.

A volte restano lì, zombie.

Un piccolo script che controlla lo stato di servizi critici (nginx, ssh, database, docker…) e fa due cose:

• prova un restart
• manda una notifica

può fare una differenza enorme.

Sì, esistono soluzioni più sofisticate. Ma questo approccio ha un vantaggio: lo capisci completamente.

Rete: quando il problema non è il server

Quante volte succede:

“Il server è lento”

E invece è la rete.

Qui entrano in gioco strumenti spesso sottovalutati:

ss -tulnp
ping
traceroute
tcpdump

Connessioni bloccate in TIME_WAIT o CLOSE_WAIT? Latenza che sale improvvisamente?

Sono segnali chiari. Basta guardarli.

Alerting: semplice, ma efficace

Non serve un sistema complesso per essere avvisati.

Basta poco:

• cron / timer
• script bash
• email o notifiche

La regola è una sola:

devi sapere del problema prima dell’utente.

Tutto il resto è secondario.

La vera differenza: conoscere il proprio sistema

Qui sta il punto più importante.

Non è lo strumento.

È la conoscenza.

Annotati:

• utilizzo CPU normale
• consumo memoria tipico
• crescita del disco
• orari di picco
• comportamento dei servizi

Quando qualcosa devia da questo baseline, lo noti subito.

E inizi anche a prevedere i problemi, non solo a reagire.

Conclusione

Negli anni ho provato tanti strumenti di monitoraggio. Alcuni ottimi, altri meno.

Ma ogni volta torno a questa idea:

prima di aggiungere complessità, sfrutta quello che hai già.

Linux ti dà tutto il necessario:

• comandi solidi
• strumenti semplici
• possibilità di automazione

Il resto è disciplina.

E forse è proprio questo il bello del nostro mestiere: non servono sempre strumenti migliori.

Serve capire meglio.

Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.

Risorse:

• Crowdsec
• Canale Telegram