Una buona soglia di avviso per un server scatta quando qualcuno deve intervenire, e altrimenti resta in silenzio. In pratica significa: generare avvisi sui valori prolungati e non sui singoli picchi, misurare il carico per core della CPU e non come numero assoluto, controllare la memoria disponibile e lo swap invece della “RAM usata”, avvisare presto sullo spazio su disco e sulla velocità con cui cresce, e considerare ogni riavvio non pianificato come qualcosa da sapere. Dividi gli avvisi in un livello di warning per l’orario di lavoro e un livello critico che può svegliare qualcuno, e rivedi i valori dopo ogni incidente.
Questa guida passa in rassegna ogni metrica, spiega che aspetto ha una soglia sensata e si chiude con una tabella di valori di partenza. Sono punti di partenza, non regole: ogni server ha la sua normalità, e la soglia giusta è quella che la rispecchia.
A cosa serve una soglia
Ogni avviso costa attenzione. Un avviso che scatta senza richiedere alcuna azione insegna a ignorare il successivo, e il successivo potrebbe essere reale. Prima di impostare una soglia, rispondi a tre domande:
Cosa si rompe se questo valore continua così, e quanto presto?
Cosa farebbe concretamente la persona che riceve l’avviso?
Può aspettare fino a domattina?
Se non si rompe nulla e nessuno interverrebbe, è un grafico, non un avviso. Se può aspettare fino a domattina, è un warning. Solo ciò che non può aspettare dovrebbe arrivare su un telefono di notte.
Livelli warning e critico
Due livelli per metrica funzionano bene per la maggior parte dei team:
Warning: qualcosa sta andando nella direzione sbagliata. Invialo via email o in un canale della chat del team e gestiscilo in orario di lavoro.
Critico: un’interruzione è vicina o già in corso. Invialo come notifica push a chi è reperibile, di giorno o di notte.
Se il tuo strumento di monitoraggio prevede una sola soglia per metrica, puoi ottenere lo stesso effetto con l’instradamento: imposta la soglia dove serve un intervento e scegli il canale per ogni server. Un avviso sul disco di una macchina di staging può andare via email; lo stesso avviso sul database di produzione può andare nella chat del team di reperibilità. Le notifiche di Uptimecheck si scelgono per ogni monitor, e questo rende semplice la suddivisione. Con i turni di reperibilità, gli avvisi push raggiungono chi è reperibile in quel momento, e l’escalation può trattenere un canale da 5 a 60 minuti e avvisare solo se il problema persiste e nessuno l’ha preso in carico.
La durata conta più dei picchi
La fonte di rumore più comune è l’avviso su una singola lettura. Una CPU al 100 percento per dieci secondi durante un deploy, un backup o la ricostruzione di una cache è normale. Una CPU al 100 percento per venti minuti non lo è. Dove lo strumento lo consente, aggiungi una durata: “sopra il 90 percento per 10 minuti” invece di “sopra il 90 percento”.
Dove non lo consente, usa metriche che si attenuano già nel tempo. Il load average a 15 minuti è un buon esempio: un breve picco lo sposta appena, mentre un sovraccarico prolungato lo spinge in alto e lo mantiene lì.
CPU
Una CPU alta, di per sé, è raramente un problema. Un server occupato è un server che fa il suo lavoro. La CPU diventa un problema quando resta satura abbastanza a lungo da far accodare le richieste e salire i tempi di risposta. Genera avvisi sull’utilizzo prolungato e osservalo insieme ai tempi di risposta dei tuoi controlli di uptime. Se la CPU è al 95 percento e i tempi di risposta sono stabili, il server è occupato, non in difficoltà.
Load average per core
Su Linux, il load average è all’incirca il numero di processi in esecuzione o in attesa della CPU, e su Linux anche di quelli in attesa di I/O su disco, mediato su 1, 5 e 15 minuti. Un carico assoluto di 4 non dice nulla da solo: su un server a 16 core è leggero, su un server a 2 core è il doppio di quanto la macchina possa reggere. Dividilo per il numero di core prima di confrontarlo; te lo dice nproc.
Il valore a 1 minuto reagisce in fretta ed è rumoroso. Usalo per la diagnosi, non per gli avvisi.
Il valore a 15 minuti è quello su cui generare avvisi. Sopra 1 per core significa che il lavoro si sta accodando; molto sopra, per molto tempo, significa che gli utenti se ne accorgono.
Un carico alto con CPU bassa di solito indica processi in attesa del disco o di uno storage di rete. Guarda l’I/O, non il codice.
RAM e swap
“RAM usata” è una metrica fuorviante su Linux. Il kernel usa la memoria libera per la cache dei file e la restituisce quando le applicazioni ne hanno bisogno, quindi un server in salute mostra spesso la memoria quasi piena. Guarda invece la memoria disponibile, la colonna “available” di free -m, che conteggia la cache recuperabile.
Lo swap dice di più. Un server che normalmente non usa lo swap e comincia a farlo è sotto pressione di memoria, e le prestazioni crollano non appena la memoria attiva viene spostata su disco. Due segnali utili:
Uso dello swap che compare o cresce su un server che di solito non ne usa.
Memoria disponibile in calo costante per giorni, spesso indizio di un memory leak in un processo di lunga durata.
I server di database sono un caso a parte: sono configurati apposta per usare la maggior parte della memoria. Imposta le loro soglie in base a ciò che vedi in una settimana normale.
Spazio su disco e crescita
Un disco pieno è una delle cause più comuni di interruzioni evitabili. I database smettono di scrivere, i log smettono di ruotare, le sessioni non possono essere salvate e i backup falliscono. Il disco è anche la metrica più facile da impostare bene, perché cambia raramente in fretta e lascia il tempo di agire se l’avviso arriva presto.
Usa una soglia percentuale per warning e critico, ma adattala alla dimensione. Su un volume da 2 TB, il 10 percento libero equivale ancora a 200 GB; su un volume da 20 GB sono 2 GB, che un solo log fuori controllo può divorare in un pomeriggio.
Controlla la crescita oltre al livello. Un disco al 70 percento cresciuto di 10 punti questa settimana è più urgente di uno fermo all’85 percento da un anno.
Sappi cosa lo riempie: log, backup conservati in locale, upload, immagini Docker, file di database. Ognuno ha una soluzione diversa.
Rete
Per il traffico di rete è difficile fissare una soglia, perché la normalità varia con l’ora del giorno e la stagione. Due situazioni meritano un avviso. Un traffico molto sopra il livello abituale, vicino alla capacità del collegamento, può indicare un picco di traffico, uno scraper o un attacco. Un traffico che scende quasi a zero su un server di solito molto attivo può significare che è stato tolto dal load balancer o che ha perso la rete, anche se la macchina sembra a posto. Ricava l’intervallo normale da qualche settimana di storico prima di impostare dei valori.
Riavvii
Un riavvio non pianificato vale sempre la pena di saperlo. Può trattarsi di un aggiornamento del kernel, di una manutenzione del provider di hosting, di un crash o di un evento di memoria esaurita. Anche quando tutto torna su, i servizi non impostati per l’avvio al boot, i job pianificati previsti durante il riavvio e i volumi montati possono restare in uno stato anomalo. Genera un avviso per ogni riavvio fuori da una finestra di manutenzione, a livello warning se il server si è ripreso da solo.
Valori di partenza
I valori qui sotto sono esempi di partenza per un tipico server web o applicativo. Usali per le prime settimane, poi adattali a ciò che osservi.
MetricaWarning (esempio)Critico (esempio)CPUSopra l’85% per 15 minutiSopra il 95% per 15 minuti, con tempi di risposta in aumentoLoad average (15 min)Sopra 1 per coreSopra 2 per coreMemoria disponibileSotto il 15%Sotto il 5%SwapQualsiasi uso su un server che normalmente non ne usaOltre il 50% dello swap in usoDiscoSopra l’80%, o pieno entro una settimana al ritmo attualeSopra il 90%, o pieno entro un giornoReteBen fuori dall’intervallo normale per l’ora del giornoVicino alla capacità del collegamento, o vicino a zero su un server molto attivoRiavvioQualsiasi riavvio fuori da una finestra di manutenzioneServizi non ripartiti dopo un riavvio
Il monitoraggio dei server di Uptimecheck rileva CPU, memoria, disco e rete ogni minuto su Linux, macOS e Windows. Imposti le soglie per CPU, memoria e disco per ogni server, con una durata come 5 o 15 minuti, e ricevi avvisi anche per i riavvii e quando un server smette di comunicare, così una macchina che non invia più dati non viene mai scambiata per una tranquilla. Per capire perché questi valori contano, leggi come mantenere attivo il tuo sito con il monitoraggio dello stato del server.
Tieni d’occhio anche i sintomi
Le metriche del server descrivono le cause. I tuoi utenti vivono i sintomi: pagine lente, errori e job falliti. Monitora entrambi. Un controllo di uptime con validazione della risposta ti dice quando il sito non funziona, e un heartbeat ti dice quando il backup non è stato completato. Quando un avviso sui sintomi e uno sulle risorse scattano insieme, la causa di solito è evidente. Quando scatta solo quello sulle risorse, spesso hai il tempo di risolvere prima che qualcuno se ne accorga.
Questo ti permette anche di alzare le soglie dei server con sicurezza. Se il sito viene controllato ogni minuto, non deve essere un avviso sulla CPU a intercettare un’interruzione. Può essere tarato come segnale precoce invece che come ultima risorsa. Lo stesso ragionamento vale per i controlli dei siti web; leggi come ridurre i falsi allarmi nel monitoraggio uptime.
Rivedi le soglie dopo gli incidenti
Le soglie non sono mai definitive. Dopo ogni incidente, e una volta al mese per i server più rumorosi, chiediti:
È scattato un avviso prima che gli utenti se ne accorgessero? Se no, quale metrica si è mossa per prima, e una soglia più bassa l’avrebbe intercettata?
Quali avvisi sono scattati senza che nessuno intervenisse? Alzali, aggiungi una durata o spostali su un canale diurno.
L’avviso ha raggiunto qualcuno in grado di intervenire? Se no, cambia l’instradamento.
La normalità del server è cambiata dopo un aggiornamento, una migrazione o un aumento del traffico?
Scrivi le risposte nel report dell’incidente, così ogni modifica ha una motivazione. Il modello di postmortem per gli incidenti ha una sezione proprio per questo.
Riepilogo
Genera avvisi su ciò che richiede una persona, con l’urgenza che ha davvero. Usa valori prolungati, carico per core, memoria disponibile e swap, livello e crescita del disco, e ogni riavvio non pianificato. Parti da valori di esempio, impara la normalità di ogni server e affina dopo ogni incidente.
Uptimecheck mette il monitoraggio dei server accanto ai controlli di uptime, agli heartbeat e alle pagine di stato in un unico account. Inizia la prova gratuita di 14 giorni, senza carta di credito.