Come monitorare l'uptime dei server: controlli, strumenti e allarmi

Per monitorare l'uptime di un server, eseguite controlli automatici dall'esterno del server (ping, porta TCP o richieste HTTP da più località), raccogliete i segnali di salute del server con un agent e avvisate solo quando più località falliscono di seguito. Poi registrate ogni interruzione, così ogni mese potete calcolare la disponibilità rispetto al vostro SLA.

Punti chiave

• I controlli sintetici esterni rispondono a "gli utenti riescono a raggiungerlo?"; gli agent interni rispondono a "perché è fermo?". Servono entrambi.
• Controllate da almeno tre località e avvisate dopo fallimenti consecutivi, per evitare falsi allarmi dovuti a un singolo percorso di rete difettoso. Microsoft raccomanda almeno cinque località di test per i test di disponibilità di Azure.
• Verificate ciò che usano gli utenti: una richiesta HTTPS che controlla codice di stato e contenuto della pagina vale più di un ping.
• Una disponibilità del 99,9% ammette comunque circa 43,8 minuti di downtime al mese. Sappiate cosa consente il vostro obiettivo prima di impostare le soglie di allarme.
• Escludete in modo coerente le finestre di manutenzione concordate e calcolate l'uptime ogni mese dagli stessi dati.

Che cos'è il monitoraggio dell'uptime di un server?

Il monitoraggio dell'uptime di un server è il controllo continuo che un server e i servizi su di esso siano raggiungibili e rispondano correttamente. Produce due cose: allarmi quando qualcosa si ferma e uno storico che potete trasformare in una percentuale di disponibilità.

Uptime e disponibilità sono collegati ma non identici. Un server può essere acceso (uptime alto) mentre il suo servizio web restituisce errori (disponibilità bassa). Per la maggior parte delle aziende il numero che conta è la disponibilità del servizio, così come la vedono gli utenti.

Quanto downtime consente ogni obiettivo di uptime?

La disponibilità è (tempo totale − downtime) ÷ tempo totale. La tabella converte gli obiettivi più comuni in downtime ammesso, usando un mese medio di 730 ore.

Un obiettivo stringente cambia il modo di monitorare. Al 99,99% un intervallo di controllo di cinque minuti non riesce nemmeno a rilevare ogni violazione, quindi servono controlli ogni minuto o più frequenti e una risposta in reperibilità misurata in minuti. Il capitolo del libro SRE di Google sull'accettare il rischio (embracing risk) spiega perché ogni "nove" in più costa di più e perché l'obiettivo deve seguire le esigenze del business.

Quali controlli eseguire?

Controlli esterni (sintetici)

• Ping ICMP: mostra che l'host risponde in rete. Economico, ma molti firewall lo bloccano e un host può rispondere al ping mentre le sue applicazioni sono ferme.
• Controlli sulle porte TCP: confermano che un servizio è in ascolto, per esempio 443 per HTTPS, 3389 per RDP o 5432 per PostgreSQL.
• Controlli HTTP(S): richiedono un URL e verificano codice di stato, tempo di risposta e un contenuto atteso. Usate un endpoint di health dedicato che testi anche la connessione al database.
• Controlli dei certificati TLS: avvisano prima della scadenza di un certificato. Un certificato scaduto è un'interruzione per gli utenti anche quando il server è in salute.
• Controlli DNS: confermano che il nome venga risolto all'indirizzo corretto.

Segnali interni (basati su agent)

• Heartbeat: l'agent si segnala ogni minuto; un heartbeat mancante significa che l'host o l'agent è fermo.
• Contatore di uptime del sistema: mostra i riavvii non pianificati. Su Linux usate uptime o last reboot; su Windows, l'event ID 6008 nel log di sistema registra uno spegnimento imprevisto.
• Metriche delle risorse: CPU, memoria, spazio e latenza del disco. Dischi pieni ed esaurimento della memoria sono cause frequenti di "acceso ma non funzionante".
• Stato di servizi e processi: il web server, il database o il job pianificato sono in esecuzione?

Per gli host Windows, la nostra guida su come monitorare le prestazioni di Windows Server elenca i contatori da raccogliere.

Quali strumenti possono monitorare l'uptime dei server?

La scelta conta meno della configurazione. Anche uno strumento self-hosted va monitorato: se il vostro unico server di monitoraggio si trova nello stesso rack dei server che controlla, un'interruzione di corrente li mette fuori uso entrambi. Eseguite almeno un controllo esterno da una rete diversa o da un servizio cloud.

Come impostare allarmi di uptime senza falsi positivi

1. Usate più località. Microsoft raccomanda almeno cinque località di test per i test di disponibilità di Azure e una soglia di allarme pari al numero di località meno due, per esempio tre in errore su cinque.
2. Richiedete fallimenti consecutivi. L'opzione di retry di Azure segnala un errore solo dopo tre tentativi consecutivi falliti; Microsoft osserva che circa l'80% degli errori scompare al nuovo tentativo.
3. Impostate la gravità in base all'impatto. Un portale clienti in produzione chiama il tecnico in reperibilità; un server di test apre un ticket.
4. Instradate gli allarmi a chi può agire, con escalation se nessuno li prende in carico entro un tempo stabilito.
5. Silenziate la manutenzione pianificata nello strumento di monitoraggio, anziché ignorare gli allarmi per abitudine.
6. Avvisate anche al ripristino, così il team sa quando l'incidente è concluso.

Le indicazioni SRE di Google sul monitoraggio dei sistemi distribuiti aggiungono una regola utile: ogni chiamata deve essere urgente, azionabile e richiedere un intervento umano. Tutto il resto va in un ticket o in una dashboard.

Come riportare l'uptime rispetto a uno SLA

• Definite che cosa conta come fermo, per esempio "l'endpoint di health fallisce da tre località su cinque per due controlli consecutivi".
• Concordate quali finestre di manutenzione sono escluse e registratele nello strumento.
• Calcolate la disponibilità mensile dai risultati dei controlli, non a memoria o dalle note dei ticket.
• Tenete un registro delle interruzioni con inizio, fine, causa e soluzione. Gli schemi ricorrenti, come interruzioni dopo ogni notte di patch, mostrano dove investire.
• Confrontate il vostro valore con quanto garantisce il cloud provider. Ad esempio, l'Amazon Compute SLA garantisce il 99,99% di uptime mensile per EC2 distribuito su più availability zone di una regione, ma solo il 99,5% per una singola istanza EC2. La disponibilità della vostra applicazione non può mai superare quella della sua dipendenza più debole.

Il monitoraggio vi informa delle interruzioni; la ridondanza le previene. Eseguite i carichi critici su più server o availability zone dietro un load balancer, così un singolo guasto non fa cadere il servizio. WorkBuster, una piattaforma SaaS per il recruiting, gira su EC2 dietro un Application Load Balancer con MySQL RDS multi-AZ, un gruppo di auto-scaling e dashboard e allarmi CloudWatch; il caso di studio WorkBuster mostra l'intera configurazione.

Come vi aiuta Opsio

Opsio gestisce monitoraggio e incident response 24/7 per server e carichi di lavoro cloud su AWS, Azure e Google Cloud. Configuriamo controlli, instradamento degli allarmi e report mensili di disponibilità, e i nostri tecnici intervengono sugli allarmi. Consultate le pagine sui nostri servizi di monitoraggio e supporto cloud, sul monitoraggio remoto dell'infrastruttura e sull'osservabilità con Prometheus e Grafana.

Domande frequenti

Come verifico da quanto tempo un server è attivo?

Su Linux, eseguite uptime o last reboot. Su Windows, aprite la scheda Prestazioni di Task Manager, eseguite systeminfo e leggete "System Boot Time" (ora di avvio del sistema), oppure controllate il log eventi di sistema. Questi strumenti mostrano il tempo dall'ultimo avvio, non se i servizi erano disponibili.

Con quale frequenza vanno eseguiti i controlli di uptime?

Ogni uno-cinque minuti per la maggior parte dei servizi di produzione. Adattate l'intervallo al vostro obiettivo: al 99,99% avete solo circa 4,4 minuti di downtime al mese, quindi un intervallo di cinque minuti è troppo lento per misurarlo.

Il ping basta per monitorare l'uptime di un server?

No. Il ping dimostra solo che lo stack di rete risponde. Aggiungete un controllo TCP o HTTPS sul servizio da cui dipendono gli utenti, idealmente con una verifica del contenuto, più controlli basati su agent sul server stesso.

Qual è una buona percentuale di uptime per un server?

Per le applicazioni aziendali il 99,9% è un obiettivo comune; i servizi rivolti ai clienti puntano spesso al 99,95% o più. Obiettivi più alti richiedono ridondanza: AWS, per esempio, garantisce solo il 99,5% per una singola istanza EC2 ma il 99,99% per EC2 distribuito su più availability zone.

Posso monitorare l'uptime gratuitamente?

Sì. Strumenti open source come Prometheus con blackbox_exporter, Zabbix o Nagios non costano nulla di licenza, anche se si paga in hosting e tempo di manutenzione. I controlli nativi dei cloud provider costano poco per un numero ridotto di endpoint.

Letture correlate

• Che cos'è il monitoraggio cloud
• Che cos'è il monitoraggio in tempo reale di server e applicazioni?
• Come monitorare le prestazioni di Windows Server? Strumenti e metriche