Vérifier la température et le ventilateur Sophos Firewall via SSH

La température n’est pas affichée dans le WebAdmin de Sophos Firewall. Sur une appliance XGS physique, il est toutefois possible de lire les valeurs matérielles dans l’Advanced Shell et de les comparer avec le journal matériel. La commande qui fournit les valeurs brutes des capteurs dépend du modèle.

Sur la XGS 138 testée ici, deux commandes en lecture seule suffisent pour un premier contrôle :

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

La première commande affiche les valeurs brutes actuelles de la puce de supervision. Le journal présente les valeurs essentielles plus clairement sous les noms Host_CPU_Temperature, NPU_CPU_Temperature et Fan_Speed_Avg. Une valeur élevée isolée ne prouve pas une surchauffe : il faut également tenir compte de l’évolution, de la charge, de la température ambiante, du ventilateur et des pannes observées.

⚠️ Important : l’Advanced Shell donne un accès direct au système d’exploitation. Les commandes présentées ici servent uniquement à lire des informations. Ne modifiez pas les seuils des capteurs ni la commande du ventilateur, ne supprimez aucun fichier et ne redémarrez aucun service.

Lire directement la température avec `sensors`

Le contrôle nécessite un accès SSH avec l’utilisateur admin. Après la connexion, ouvrez :

5. Device Management
3. Advanced Shell

L’article Se connecter à Sophos Firewall via SSH explique comment autoriser SSH de manière sûre et ouvrir la bonne console.

Dans l’Advanced Shell, affichez les capteurs actuels :

sensors

Cette commande a été exécutée sur une XGS 138 avec SFOS 22.0 GA Build 411. La CLI des capteurs bruts dépend du modèle : pour une XGS 2100, Sophos Hardware Development indique la commande suivante lorsque sensors ne renvoie aucune valeur :

xgs-1us-sensors -a

Ces alternatives ne doivent être utilisées que sur le modèle correspondant. /log/xgs-healthmond.log est la source la plus largement documentée et doit être consultée dans tous les cas. Sur une appliance virtuelle, cloud ou logicielle, les commandes de capteurs matériels peuvent être absentes, car SFOS n’a pas accès aux capteurs physiques de l’hyperviseur ou du serveur.

La sortie dépend du modèle. Elle contient généralement des canaux de température, des vitesses de ventilateur en RPM, des tensions et d’autres valeurs brutes de la puce de supervision matérielle. Il est préférable d’enregistrer d’abord la sortie complète plutôt que de filtrer uniquement ALARM. Sur certains modèles, un tel filtre afficherait de nombreux canaux bruts qui existent techniquement, mais qui ne sont pas associés à une mesure exploitable.

Contrôler les valeurs produit dans le journal matériel

Sophos documente /log/xgs-healthmond.log sur les appliances matérielles pour l’utilisation et la température du CPU, la vitesse du ventilateur ainsi que le port de gestion du NPU. Affichez les dernières entrées avec :

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

Pour une courte période d’observation, suivez le journal en direct :

tail -f /log/xgs-healthmond.log

Arrêtez l’affichage avec Ctrl+C. Il n’est pas nécessaire d’activer le débogage. xgs-healthmond.log est un nom de fichier journal, et non un nom valide à utiliser comme sous-système de débogage.

Les lignes suivantes sont particulièrement utiles :

Host_CPU_Temperature : température du CPU principal.
NPU_CPU_Temperature : température du NPU séparé, ou Xstream Flow Processor, si le modèle possède un NPU.
Fan_Speed et Fan_Speed_Avg : vitesse actuelle et vitesse agrégée du ventilateur en RPM.
Host_CPU_Usage et NPU_CPU_Usage : utilisation au moment de la mesure. Elle aide à mettre une hausse de température en relation avec une charge élevée.
Min, Max, Current et Avg : statistiques conservées par le moniteur d’état.

Sophos ne documente pas publiquement la fenêtre de temps exacte de ces statistiques. Il ne faut donc pas présenter Max comme le pic des cinq dernières minutes, depuis le dernier redémarrage ou sur toute la durée de vie de l’appliance. Pour un dossier de support, enregistrez la valeur avec son horodatage.

Interpréter correctement les valeurs brutes et les alarmes apparentes

La sortie de sensors provient directement de la supervision matérielle Linux. Une puce de capteurs peut proposer plus d’entrées que celles réellement connectées sur l’appliance ou correctement libellées pour SFOS. Toute ligne affichée n’est donc pas forcément une valeur produit exploitable.

Sur la XGS 138 testée, plusieurs lignes de tension se présentaient par exemple sous cette forme :

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

La valeur positive dépasse formellement le maximum configuré de 0.00 V, ce qui pousse la puce brute à signaler ALARM. Cela ne confirme toutefois pas à lui seul un défaut de tension ou de matériel. Un diagnostic fiable nécessiterait de connaître l’affectation de l’entrée et les seuils valides de la carte concernée.

D’autres anomalies apparentes doivent également être interprétées avec prudence :

Plusieurs canaux de ventilateur à 0 RPM ne signifient pas automatiquement que plusieurs ventilateurs sont en panne. Si le modèle n’utilise pas ces connecteurs et affiche également min = 0 RPM, il peut s’agir de canaux inutilisés.
Des valeurs comme -128 °C, 0 °C, 99 °C ou -1.0 peuvent correspondre à un capteur déconnecté, non pris en charge ou sans affectation exploitable.
intrusion0: ALARM concerne la détection d’ouverture du châssis et n’est pas une alarme de température.
high et crit s’appliquent uniquement au capteur à côté duquel ils apparaissent. Un seuil affiché pour CPUTIN ne doit pas être transposé à Host_CPU_Temperature sans preuve.

Pour une première évaluation, les valeurs nommées de xgs-healthmond.log sont donc plus fiables que des canaux bruts isolés et peu clairs. Conservez néanmoins les valeurs brutes inhabituelles dans l’extrait destiné au support afin que Sophos puisse les analyser pour le modèle concerné.

La Sophos Firewall est-elle trop chaude ?

Il faut d’abord distinguer la température ambiante de la température interne des composants. Sophos spécifie une température ambiante de fonctionnement de 0 à 40 °C pour les XGS 118, 128 et 138. Il s’agit de l’air au lieu d’installation ou dans le rack, et non de la température interne du CPU. La limite exacte du modèle installé figure dans ses Sophos Operating Instructions.

Une température interne du CPU de 70 °C, par exemple, ne peut donc pas être comparée à la limite ambiante de 40 °C. Sophos ne publie pas non plus une température normale universelle pour le CPU ou le NPU de tous les modèles XGS. Des affirmations générales telles que « tout est normal sous 80 °C » ou « le pare-feu est défectueux au-dessus de 90 °C » ne seraient donc pas fiables.

Une évaluation pertinente combine plusieurs observations :

Environnement : mesurez la température de l’air à l’entrée de l’appliance, pas uniquement celle de la pièce à un endroit éloigné. Si la sortie indique Chassis_Ambient_Temperature : -1.0, le pare-feu lui-même ne fournit pas de valeur ambiante exploitable.
Évolution : comparez des mesures prises avec une charge et une température ambiante similaires. Une hausse durable est plus significative qu’un bref pic.
Ventilateur : vérifiez que le ventilateur effectivement présent fonctionne et réagit lorsque la température augmente.
Charge : consignez simultanément l’utilisation du CPU et du NPU.
Symptômes : les redémarrages inattendus, blocages, erreurs NPU ou pannes répétées augmentent l’urgence.
Limite du modèle : vérifiez les conditions d’exploitation et de rack dans les instructions matérielles du modèle concerné.

Un châssis chaud ne prouve pas à lui seul un défaut. Il indique toutefois qu’il faut vérifier le flux d’air, la température du rack, le dégagement des ouvertures de ventilation et l’évolution de la température.

Exemple réel d’une XGS 138

Sur une XGS 138 avec SFOS 22.0 GA Build 411, le journal matériel contenait notamment :

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

À cet instant, le CPU principal était fortement sollicité, le ventilateur fonctionnait et, d’après le journal, le NPU répondait toujours correctement. La valeur maximale enregistrée de 82.5 °C mérite d’être examinée avec la charge, la température du rack et la panne précédente. L’extrait ne contient cependant aucune erreur thermique ou de ventilateur explicite et ne prouve pas à lui seul que la surchauffe a provoqué la panne.

Cette distinction est importante : un redémarrage peut temporairement atténuer un état thermique, mais aussi corriger un problème de logiciel, de charge ou de processus. Après une panne, enregistrez donc ensemble les données de température et les journaux système.

Poursuivre correctement le diagnostic après une panne

Si le pare-feu ne répondait plus ou n’a repris son fonctionnement qu’après un redémarrage, une seule mesure de température actuelle ne suffit pas. Documentez l’incident comme un possible défaut matériel ou système :

Notez le modèle, le numéro de série, la révision matérielle, la version SFOS, le build, l’heure et le comportement observé.
Contrôlez la température de l’air à l’entrée ainsi que l’état de la climatisation, du rack et du flux d’air.
Enregistrez la sortie de sensors et les dernières entrées de xgs-healthmond.log.
Recherchez les indications pertinentes dans les journaux matériels et système actuels :

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

Enregistrez un Consolidated Troubleshooting Report et les journaux utiles. Des informations volatiles peuvent déjà avoir disparu après un plantage ou un redémarrage.
Ne remplacez aucun ventilateur, n’ouvrez pas le châssis et ne modifiez aucune valeur de capteur. Une panne inexpliquée justifie déjà l’ouverture d’un dossier auprès du support ; l’urgence augmente en cas de répétition, de température excessive dans le rack, de hausse marquée de la température, d’erreur de ventilateur ou de problème NPU.

Pour préparer un éventuel remplacement, suivez Défaut matériel Sophos : préparer le RMA et le remplacement. La vérification de l’état du SSD via SMART est un contrôle distinct qui ne répond pas aux questions de température ou de ventilateur.

HA et supervision continue

Dans un cluster HA, contrôlez les deux appliances séparément. Chaque XGS possède ses propres capteurs, ventilateurs et journaux de dépannage locaux. Une appliance primaire sans anomalie ne prouve donc pas que l’appliance auxiliaire est également saine sur le plan thermique. Avec une position identique dans le rack et une charge comparable, le pair peut aussi servir de référence utile. L’article Haute disponibilité Sophos Firewall explique les rôles et les méthodes d’accès.

L’Advanced Shell et le journal matériel sont rapides pour un diagnostic ponctuel, mais ne remplacent pas la supervision en exploitation. Depuis SFOS 22, la MIB Sophos fournit, selon le modèle XGS, la température du CPU, celle du NPU et la vitesse du ventilateur. L’article Supervision matérielle SNMP explique la MIB, les OID, les limites selon le modèle, la configuration SNMPv3 sécurisée et les alertes.

Une bonne supervision établit d’abord une référence, puis déclenche des alertes en cas d’écarts durables, d’absence de valeurs de ventilateur attendues, d’inaccessibilité ou de défauts matériels réels. Elle ne doit pas appliquer sans vérification une limite CPU générique trouvée sur Internet à tous les modèles XGS.