Controllare temperatura e ventola di Sophos Firewall via SSH

La temperatura non viene visualizzata nel WebAdmin di Sophos Firewall. Su un’appliance XGS fisica è tuttavia possibile leggere i valori hardware nella Advanced Shell e confrontarli con il log hardware. Il comando che restituisce i valori grezzi dei sensori dipende dal modello.

Per un primo controllo sulla XGS 138 testata qui bastano due comandi di sola lettura:

sensors
tail -n 100 /log/xgs-healthmond.log

Il primo comando mostra i valori grezzi attuali del chip dei sensori. Il log presenta i valori più importanti in modo più chiaro come Host_CPU_Temperature, NPU_CPU_Temperature e Fan_Speed_Avg. Un singolo valore elevato non dimostra un surriscaldamento: contano anche l’andamento, il carico, la temperatura ambiente, la ventola e i guasti osservati.

⚠️ Importante: la Advanced Shell offre accesso diretto al sistema operativo. I comandi mostrati qui leggono soltanto informazioni. Non modificare le soglie dei sensori o il controllo della ventola, non eliminare file e non riavviare servizi.

Leggere direttamente la temperatura con sensors

Il controllo richiede l’accesso SSH con l’utente admin. Dopo l’accesso, aprire:

5. Device Management
3. Advanced Shell

L’articolo Connettersi a Sophos Firewall via SSH spiega come autorizzare SSH in modo sicuro e aprire la console corretta.

Nella Advanced Shell, richiamare la vista attuale dei sensori:

sensors

Il comando è stato eseguito su una XGS 138 con SFOS 22.0 GA Build 411. La CLI dei sensori grezzi dipende dal modello: per una XGS 2100, Sophos Hardware Development indica il seguente comando quando sensors non restituisce valori:

xgs-1us-sensors -a

Queste alternative devono essere utilizzate solo sul modello corrispondente. /log/xgs-healthmond.log è la fonte documentata più ampiamente e va controllata in ogni caso. Sulle appliance virtuali, cloud o software, i comandi dei sensori hardware potrebbero non essere disponibili perché SFOS non può accedere ai sensori fisici dell’hypervisor o del server.

L’output varia in base al modello. In genere contiene canali di temperatura, velocità delle ventole in RPM, tensioni e altri valori grezzi del chip di monitoraggio hardware. Conviene salvare prima l’output completo anziché filtrare soltanto ALARM. Su alcuni modelli un filtro simile mostrerebbe numerosi canali grezzi tecnicamente presenti, ma privi di un’associazione significativa.

Controllare i valori di prodotto nel log hardware

Sophos documenta /log/xgs-healthmond.log sulle appliance hardware per utilizzo e temperatura della CPU, velocità della ventola e porta di gestione NPU. Per mostrare le voci più recenti:

tail -n 100 /log/xgs-healthmond.log

Per una breve osservazione, seguire il log in tempo reale:

tail -f /log/xgs-healthmond.log

Interrompere la visualizzazione con Ctrl+C. Non è necessario attivare il debug. xgs-healthmond.log è il nome di un file di log, non un nome valido da utilizzare come sottosistema di debug.

Sono particolarmente utili le righe seguenti:

• Host_CPU_Temperature: temperatura della CPU principale.
• NPU_CPU_Temperature: temperatura della NPU separata, o Xstream Flow Processor, se il modello dispone di una NPU.
• Fan_Speed e Fan_Speed_Avg: velocità attuale e aggregata della ventola in RPM.
• Host_CPU_Usage e NPU_CPU_Usage: utilizzo al momento della misurazione. Aiuta a collegare un aumento di temperatura a un carico elevato.
• Min, Max, Current e Avg: valori statistici mantenuti dal monitor di integrità.

Sophos non documenta pubblicamente l’intervallo temporale esatto di queste statistiche. Max non va quindi descritto come il picco degli ultimi cinque minuti, dal riavvio più recente o dell’intera vita dell’appliance. Per un caso di supporto, salvare il valore insieme al relativo timestamp.

Interpretare correttamente valori grezzi e apparenti allarmi

L’output di sensors proviene direttamente dal monitoraggio hardware di Linux. Un chip dei sensori può offrire più ingressi di quelli effettivamente collegati sull’appliance o etichettati in modo significativo per SFOS. Non tutte le righe visualizzate rappresentano quindi un valore di prodotto utilizzabile.

Sulla XGS 138 testata, ad esempio, diverse righe di tensione apparivano in questa forma:

in1: +1.78 V  (min = +0.00 V, max = +0.00 V)  ALARM

La lettura positiva supera formalmente il massimo configurato di 0.00 V, facendo sì che il chip grezzo segnali ALARM. Questo da solo non conferma un guasto di tensione o hardware. Per una diagnosi affidabile servirebbero l’associazione dell’ingresso e le soglie valide della scheda specifica.

Anche altre apparenti anomalie richiedono cautela:

• Più canali delle ventole che mostrano 0 RPM non significano automaticamente che più ventole siano guaste. Se il modello non utilizza questi connettori e mostra anche min = 0 RPM, potrebbero essere canali inutilizzati.
• Valori come -128 °C, 0 °C, 99 °C o -1.0 possono indicare un sensore scollegato, non supportato o non associato in modo utilizzabile.
• intrusion0: ALARM riguarda il rilevamento di apertura dello chassis e non è un allarme di temperatura.
• high e crit valgono soltanto per il sensore accanto al quale compaiono. Una soglia mostrata per CPUTIN non deve essere trasferita a Host_CPU_Temperature senza prove.

Per una prima valutazione, i valori denominati in xgs-healthmond.log sono quindi più affidabili dei singoli canali grezzi poco chiari. Conservare comunque i valori grezzi anomali nell’estratto destinato al supporto, in modo che Sophos possa valutarli per il modello specifico.

Sophos Firewall è troppo calda?

Occorre innanzitutto distinguere tra temperatura ambiente e temperatura interna dei componenti. Sophos specifica per XGS 118, 128 e 138 una temperatura ambiente di esercizio compresa tra 0 e 40 °C. Si tratta dell’aria nel luogo di installazione o nel rack, non della temperatura interna della CPU. Il limite esatto del proprio modello è riportato nelle relative Sophos Operating Instructions.

Una temperatura interna della CPU di, ad esempio, 70 °C non può quindi essere confrontata con il limite ambientale di 40 °C. Sophos inoltre non pubblica una temperatura normale di CPU o NPU valida in generale per tutti i modelli XGS. Affermazioni generiche come «fino a 80 °C è tutto normale» o «sopra i 90 °C il firewall è guasto» non sarebbero pertanto affidabili.

Una valutazione utile combina diverse osservazioni:

1. Ambiente: misurare la temperatura dell’aria in prossimità della presa d’aria dell’appliance, non soltanto la temperatura della stanza in un punto distante. Se l’output mostra Chassis_Ambient_Temperature : -1.0, il firewall non fornisce un valore ambiente utilizzabile.
2. Andamento: confrontare misurazioni effettuate con carico e temperatura ambiente simili. Un aumento persistente è più significativo di un picco breve.
3. Ventola: verificare che la ventola effettivamente presente funzioni e reagisca all’aumento della temperatura.
4. Carico: registrare contemporaneamente l’utilizzo di CPU e NPU.
5. Sintomi: riavvii inattesi, blocchi, errori NPU o guasti ripetuti aumentano l’urgenza.
6. Limite del modello: verificare le condizioni operative e del rack nelle istruzioni hardware del modello specifico.

Anche uno chassis caldo da solo non dimostra un guasto. Indica però che è opportuno controllare flusso d’aria, temperatura del rack, aperture di ventilazione libere e andamento nel tempo.

Esempio reale di una XGS 138

Su una XGS 138 con SFOS 22.0 GA Build 411, il log hardware mostrava tra l’altro:

Fan_Speed_Avg : 6081 RPM
NPU_CPU_Temperature : +61.3 Degrees C
Host_CPU_Temperature : +71.5 Degrees C
Host_CPU_Usage : 86.7681 %
{Host_CPU_Temperature} Min: +69.5 Max: +82.5 Current: +71.5 Avg: 71.8534

In quel momento la CPU principale era sottoposta a un carico elevato, la ventola era in funzione e, secondo il log, la NPU continuava a rispondere correttamente. Il valore massimo registrato di 82.5 °C merita una verifica insieme a carico, temperatura del rack e guasto precedente. Tuttavia, l’estratto non contiene alcun errore esplicito di temperatura o ventola e da solo non dimostra che il surriscaldamento abbia causato il guasto.

Questa distinzione è importante: un riavvio può attenuare temporaneamente una condizione termica, ma anche risolvere un problema di software, carico o processo. Dopo un guasto, salvare quindi insieme i dati di temperatura e i log di sistema.

Continuare correttamente la verifica dopo un guasto

Se il firewall non rispondeva o è tornato a funzionare soltanto dopo un riavvio, una singola misurazione attuale della temperatura non basta. Documentare l’evento come possibile guasto hardware o di sistema:

1. Annotare modello, numero di serie, revisione hardware, versione SFOS, build, ora e comportamento osservato.
2. Controllare la temperatura dell’aria presso la presa d’aria e lo stato di climatizzazione, rack e flusso d’aria.
3. Salvare l’output di sensors e le voci più recenti di xgs-healthmond.log.
4. Cercare indicazioni rilevanti nei log hardware e di sistema attuali:

grep -Ei 'temp|thermal|fan|overheat|critical|fault' /log/xgs-healthmond.log /log/syslog.log

5. Salvare un Consolidated Troubleshooting Report e i log rilevanti. Dopo un arresto anomalo o un riavvio, alcune informazioni volatili potrebbero già non essere più disponibili.
6. Non sostituire ventole, non aprire lo chassis e non modificare i valori dei sensori. Un guasto non chiarito giustifica già l’apertura di un caso di supporto; guasti ripetuti, temperatura del rack eccessiva, aumento significativo della temperatura, errori della ventola o problemi NPU ne aumentano l’urgenza.

Per un’eventuale sostituzione, seguire Guasto hardware Sophos: preparare RMA e sostituzione. Il controllo dello stato dell’SSD tramite SMART è una verifica separata e non risponde alle domande sulla temperatura o sulla ventola.

HA e monitoraggio continuo

In un cluster HA, controllare separatamente entrambe le appliance. Ogni XGS possiede sensori, ventole e log di troubleshooting locali propri. Un’appliance primaria senza anomalie non dimostra quindi che anche l’appliance ausiliaria sia priva di anomalie termiche. Con la stessa posizione nel rack e un carico comparabile, il peer può anche fornire un utile valore di confronto. L’articolo High Availability di Sophos Firewall spiega ruoli e modalità di accesso.

La Advanced Shell e il log hardware sono rapidi per una diagnosi una tantum, ma non sostituiscono il monitoraggio operativo. Da SFOS 22, la MIB Sophos fornisce, a seconda del modello XGS, temperatura CPU, temperatura NPU e velocità della ventola. SNMP Hardware Monitoring spiega MIB, OID, limiti dei modelli, configurazione SNMPv3 sicura e avvisi.

Un buon monitoraggio stabilisce innanzitutto una baseline e genera allarmi in presenza di deviazioni persistenti, valori attesi della ventola mancanti, mancata raggiungibilità e guasti hardware reali. Non dovrebbe applicare senza verifica a tutti i modelli XGS un limite generico della CPU trovato su Internet.