Naar de inhoud
Avanet

Sophos Firewall temperatuur en ventilator via SSH controleren

Sophos Firewall

De Sophos Firewall toont geen temperatuur in WebAdmin. Op een fysieke XGS-appliance kunnen de hardwarewaarden echter in de Advanced Shell worden uitgelezen en met het hardwarelog worden vergeleken. Welk commando ruwe sensorwaarden retourneert, hangt af van het model.

Voor een snelle controle op de hier geteste XGS 138 volstaan eerst twee alleen-lezencommando’s:

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

Het eerste commando toont de actuele ruwe waarden van de sensorchip. Het log ordent de belangrijkste waarden begrijpelijker als Host_CPU_Temperature, NPU_CPU_Temperature en Fan_Speed_Avg. Eén hoge waarde bewijst nog geen oververhitting; doorslaggevend zijn verloop, belasting, omgevingstemperatuur, ventilator en waargenomen uitval.

⚠️ Belangrijk: De Advanced Shell geeft directe toegang tot het besturingssysteem. De hier getoonde commando’s lezen alleen informatie. Stel geen sensorgrenzen in, wijzig de ventilatorregeling niet en verwijder geen bestanden of herstart geen services.

Temperatuur rechtstreeks met sensors uitlezen

Voor de controle is SSH-toegang met de gebruiker admin nodig. Open na het aanmelden:

5. Device Management
3. Advanced Shell

In Via SSH verbinding maken met Sophos Firewall staat hoe SSH veilig wordt vrijgegeven en de juiste console wordt geopend.

Roep in de Advanced Shell de actuele sensorweergave op:

sensors

Het commando is uitgevoerd op een XGS 138 met SFOS 22.0 GA Build 411. De CLI voor ruwe sensoren is modelafhankelijk: voor een XGS 2100 noemt Sophos Hardware Development het volgende commando wanneer sensors geen waarden retourneert:

xgs-1us-sensors -a

Gebruik zulke alternatieven alleen op het bijbehorende model. /log/xgs-healthmond.log is de breder gedocumenteerde bron en moet in elk geval worden gecontroleerd. Op virtuele, cloud- of software-appliances kunnen hardware-sensorcommando’s ontbreken, omdat SFOS daar geen toegang heeft tot de fysieke sensoren van de hypervisor of server.

De uitvoer verschilt per model. Gebruikelijk zijn temperatuurkanalen, ventilatorsnelheden in RPM, spanningen en aanvullende ruwe waarden van de hardwaremonitoringchip. Het is verstandig eerst de volledige uitvoer vast te leggen en niet alleen op ALARM te filteren. Zo’n filter zou bij sommige modellen veel technisch aanwezige maar niet zinvol toegewezen ruwe kanalen tonen.

Productwaarden in het hardwarelog controleren

Sophos documenteert /log/xgs-healthmond.log op hardware-appliances voor CPU-belasting en -temperatuur, ventilatorsnelheid en de NPU-managementpoort. Toon de laatste vermeldingen met:

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

Voor een korte observatie kan het log live worden gevolgd:

tail -f /log/xgs-healthmond.log

Stop de weergave met Ctrl+C. Debugging hoeft hiervoor niet te worden geactiveerd. xgs-healthmond.log is een logbestandsnaam en geen geldige naam die als debugsubsystem kan worden gebruikt.

In dit log zijn vooral de volgende regels nuttig:

  • Host_CPU_Temperature: temperatuur van de hoofd-CPU.
  • NPU_CPU_Temperature: temperatuur van de afzonderlijke NPU, oftewel de Xstream Flow Processor, als het model een NPU heeft.
  • Fan_Speed en Fan_Speed_Avg: actuele respectievelijk samengevatte ventilatorsnelheid in RPM.
  • Host_CPU_Usage en NPU_CPU_Usage: belasting op het meetmoment. Daarmee kan een temperatuurstijging aan hoge belasting worden gekoppeld.
  • Min, Max, Current en Avg: statistische waarden die door de Health Monitor worden bijgehouden.

Sophos documenteert het exacte tijdvenster van deze statistische waarden niet openbaar. Max mag daarom niet worden omschreven als piekwaarde van de laatste vijf minuten, sinds de laatste reboot of over de hele levensduur. Leg voor een supportcase de meetwaarde samen met het tijdstip vast.

Ruwe waarden en schijnbare alarmen correct beoordelen

De uitvoer van sensors komt rechtstreeks uit Linux-hardwaremonitoring. Een sensorchip kan meer ingangen aanbieden dan op de concrete appliance werkelijk zijn aangesloten of door SFOS zinvol zijn benoemd. Daarom is niet elke zichtbare regel een bruikbare productwaarde.

Op de geteste XGS 138 verschenen bijvoorbeeld meerdere spanningsregels met dit patroon:

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

De positieve meetwaarde ligt formeel boven het geprogrammeerde maximum van 0.00 V, waardoor de ruwe chip ALARM meldt. Daaruit volgt nog geen bevestigd spannings- of hardwaredefect. Voor een betrouwbare diagnose ontbreken de toewijzing van de ingang en de geldige grenswaarden van het concrete board.

Andere afwijkingen moeten even voorzichtig worden gelezen:

  • Meerdere ventilatorkanalen met 0 RPM betekenen niet automatisch dat meerdere ventilatoren defect zijn. Als een model deze aansluitingen niet gebruikt en tegelijk min = 0 RPM toont, kunnen het ongebruikte kanalen zijn.
  • Waarden zoals -128 °C, 0 °C, 99 °C of -1.0 kunnen een niet-aangesloten, niet-ondersteunde of niet bruikbaar toegewezen sensor aanduiden.
  • intrusion0: ALARM hoort bij de chassisdetectie en is geen temperatuuralarm.
  • high en crit gelden alleen voor de sensor waarbij ze worden weergegeven. Een grens bij CPUTIN mag zonder bewijs niet op Host_CPU_Temperature worden toegepast.

Voor een eerste beoordeling zijn de benoemde waarden uit xgs-healthmond.log daarom betrouwbaarder dan afzonderlijke onduidelijke ruwe kanalen. Bewaar afwijkende ruwe waarden wel in het supportfragment, zodat Sophos ze modelspecifiek kan controleren.

Is de Sophos Firewall te warm?

Maak eerst onderscheid tussen omgevingstemperatuur en interne componenttemperatuur. Sophos specificeert de XGS 118, 128 en 138 voor een omgevingstemperatuur van 0 tot 40 °C. Daarmee wordt de lucht op de bedrijfslocatie of in het rack bedoeld, niet de interne CPU-temperatuur. De exacte grens voor het eigen model staat in de betreffende Sophos Operating Instructions.

Een interne CPU-temperatuur van bijvoorbeeld 70 °C kan daarom niet met de omgevingsgrens van 40 °C worden vergeleken. Sophos publiceert bovendien geen algemeen geldende normale CPU- of NPU-temperatuur voor alle XGS-modellen. Algemene uitspraken als “tot 80 °C is alles normaal” of “vanaf 90 °C is de firewall defect” zijn daarom niet onderbouwd.

Een zinvolle beoordeling combineert meerdere waarnemingen:

  1. Omgeving: Meet de luchttemperatuur bij de luchtinlaat van de appliance, niet alleen de kamertemperatuur verderop. Bij Chassis_Ambient_Temperature : -1.0 levert de firewall zelf geen bruikbare omgevingswaarde.
  2. Verloop: Vergelijk waarden over meerdere metingen bij vergelijkbare belasting en kamertemperatuur. Een voortdurend stijgende trend zegt meer dan een korte piek.
  3. Ventilator: Controleer of de werkelijk aanwezige ventilator draait en op een stijgende temperatuur reageert.
  4. Belasting: Leg de CPU- en NPU-belasting op hetzelfde moment vast.
  5. Symptomen: Onverwachte reboots, vastlopers, NPU-fouten of herhaalde uitval verhogen de urgentie.
  6. Modelgrens: Controleer de bedrijfs- en rackvoorwaarden in de hardwarehandleiding van het concrete model.

Ook een warme behuizing alleen bewijst geen defect. Het is wel aanleiding om de luchtstroom, racktemperatuur, vrije ventilatieopeningen en het verloop in de tijd te controleren.

Praktijkvoorbeeld van een XGS 138

Op een XGS 138 met SFOS 22.0 GA Build 411 toonde het hardwarelog onder meer:

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

De hoofd-CPU was op dat moment zwaar belast, de ventilator draaide en volgens het log reageerde de NPU nog steeds succesvol. De opgeslagen maximumwaarde van 82.5 °C verdient aandacht in combinatie met de belasting, racktemperatuur en de voorafgaande uitval. Het fragment bevat echter geen expliciete thermische fout of ventilatorfout en bewijst op zichzelf niet dat oververhitting de oorzaak van de uitval was.

Dit onderscheid is belangrijk: een reboot kan een thermische toestand tijdelijk verminderen, maar ook een software-, belasting- of procesfout verhelpen. Na een uitval moeten daarom zowel temperatuurgegevens als systeemlogs worden veiliggesteld.

Na een uitval verder controleren

Als de firewall niet reageerde of pas na een reboot weer werkte, volstaat één actuele temperatuurmeting niet. Documenteer het incident als een mogelijk hardware- of systeemprobleem:

  1. Noteer model, serienummer, hardwarerevisie, SFOS-versie, build, tijdstip en waargenomen gedrag.
  2. Controleer de luchttemperatuur bij de luchtinlaat en de toestand van koeling, rack en luchtstroom.
  3. Bewaar sensors en de laatste vermeldingen uit xgs-healthmond.log.
  4. Zoek naar actuele aanwijzingen in het hardware- en systeemlog:
grep -Ei 'temp|thermal|fan|overheat|critical|fault' /log/xgs-healthmond.log /log/syslog.log
  1. Stel een Consolidated Troubleshooting Report op en bewaar relevante logs. Na een crash of reboot kan vluchtige informatie al ontbreken.
  2. Vervang geen ventilatoren, open de behuizing niet en wijzig geen sensorwaarden. Open na een onverklaarde uitval al een supportcase; bij herhaling, een ontoelaatbare racktemperatuur, een duidelijke temperatuurstijging, ventilatorfouten of NPU-problemen neemt de urgentie toe.

Voor een mogelijke vervanging helpt de procedure Sophos-hardwaredefect: RMA en vervanging voorbereiden. De SSD-status met SMART is een afzonderlijke controle en beantwoordt geen temperatuur- of ventilatorvraag.

HA en permanente monitoring

Controleer in een HA-cluster beide appliances afzonderlijk. Elke XGS heeft eigen sensoren, ventilatoren en lokale troubleshootinglogs. Een onopvallende Primary Appliance bewijst daarom niet dat de Auxiliary Appliance eveneens thermisch onopvallend is. Bij dezelfde rackpositie en vergelijkbare belasting kan de peer tegelijk als nuttige vergelijkingswaarde dienen. De rollen en toegangsmogelijkheden staan in Sophos Firewall High Availability.

Voor een eenmalige diagnose zijn de Advanced Shell en het hardwarelog snel. Voor de bedrijfsvoering vervangen ze geen monitoring. Sinds SFOS 22 levert de Sophos MIB, afhankelijk van het XGS-model, CPU-temperatuur, NPU-temperatuur en ventilatorsnelheid. SNMP-hardwaremonitoring beschrijft de MIB, OID’s, modelgrenzen, veilige SNMPv3-configuratie en alarmering.

Goede monitoring bouwt eerst een baseline op en alarmeert bij blijvende afwijkingen, ontbrekende verwachte ventilatorwaarden, onbereikbaarheid en werkelijke hardwarefouten. Pas geen algemene CPU-grens uit het internet ongecontroleerd toe op alle XGS-modellen.