Kontrollera temperatur och fläkt i Sophos Firewall via SSH

Temperaturen visas inte i Sophos Firewalls WebAdmin. På en fysisk XGS-appliance går det dock att läsa av maskinvaruvärden i Advanced Shell och jämföra dem med hårdvaruloggen. Vilket kommando som returnerar råa sensorvärden beror på modellen.

För en snabb kontroll på den XGS 138 som testats här räcker till att börja med två skrivskyddade kommandon:

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

Det första kommandot visar sensorkretsens aktuella råvärden. Loggen presenterar de viktigaste värdena tydligare som Host_CPU_Temperature, NPU_CPU_Temperature och Fan_Speed_Avg. Ett enstaka högt värde bevisar ännu inte överhettning; avgörande är utvecklingen, belastningen, omgivningstemperaturen, fläkten och observerade avbrott.

⚠️ Viktigt: Advanced Shell ger direkt åtkomst till operativsystemet. Kommandona som visas här läser endast information. Ändra inte sensorgränser eller fläktstyrning, ta inte bort filer och starta inte om tjänster.

Läs av temperaturen direkt med `sensors`

Kontrollen kräver SSH-åtkomst med användaren admin. Öppna följande efter inloggningen:

5. Device Management
3. Advanced Shell

I Anslut till Sophos Firewall via SSH beskrivs hur SSH tillåts på ett säkert sätt och rätt konsol öppnas.

Kör den aktuella sensorvyn i Advanced Shell:

sensors

Kommandot kördes på en XGS 138 med SFOS 22.0 GA Build 411. CLI-kommandot för råa sensorer är modellberoende: för en XGS 2100 anger Sophos Hardware Development följande kommando när sensors inte returnerar några värden:

xgs-1us-sensors -a

Sådana alternativ ska endast användas på motsvarande modell. /log/xgs-healthmond.log är den mer allmänt dokumenterade källan och bör kontrolleras oavsett. På virtuella, molnbaserade eller programvarubaserade appliances kan kommandon för maskinvarusensorer saknas, eftersom SFOS där inte har åtkomst till hypervisorns eller serverns fysiska sensorer.

Utdata varierar beroende på modell. Vanligtvis visas temperaturkanaler, fläkthastigheter i RPM, spänningar och ytterligare råvärden från kretsen för maskinvaruövervakning. Det är lämpligt att först spara fullständiga utdata och inte enbart filtrera efter ALARM. Ett sådant filter kan på vissa modeller visa många råkanaler som finns tekniskt men inte har någon meningsfull tilldelning.

Kontrollera produktvärden i hårdvaruloggen

Sophos dokumenterar /log/xgs-healthmond.log på hårdvaruappliances för CPU-belastning och -temperatur, fläkthastighet och NPU-hanteringsporten. Visa de senaste posterna med:

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

För en kort observation kan loggen följas i realtid:

tail -f /log/xgs-healthmond.log

Avsluta visningen med Ctrl+C. Debug behöver inte aktiveras. xgs-healthmond.log är ett loggfilnamn och inte ett giltigt namn att använda som debugundersystem.

Följande rader är särskilt användbara i loggen:

Host_CPU_Temperature: huvudprocessorns temperatur.
NPU_CPU_Temperature: temperaturen för den separata NPU:n, det vill säga Xstream Flow Processor, om modellen har en NPU.
Fan_Speed och Fan_Speed_Avg: aktuell respektive sammanställd fläkthastighet i RPM.
Host_CPU_Usage och NPU_CPU_Usage: belastningen vid mättillfället. Den hjälper till att koppla en temperaturökning till hög belastning.
Min, Max, Current och Avg: statistikvärden som underhålls av Health Monitor.

Sophos dokumenterar inte det exakta tidsintervallet för dessa statistikvärden offentligt. Max ska därför inte beskrivas som toppvärdet under de senaste fem minuterna, sedan den senaste omstarten eller under hela livslängden. Spara mätvärdet tillsammans med tidsstämpeln för ett supportärende.

Tolka råvärden och skenbara larm korrekt

Utdata från sensors kommer direkt från Linux-maskinvaruövervakningen. En sensorkrets kan erbjuda fler ingångar än vad som faktiskt är anslutet på den aktuella appliance-enheten eller är meningsfullt namngivet för SFOS. Därför är inte varje synlig rad ett användbart produktvärde.

På den testade XGS 138 visades exempelvis flera spänningsrader enligt följande mönster:

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

Det positiva mätvärdet ligger formellt över det programmerade maxvärdet 0.00 V, vilket gör att råkretsen rapporterar ALARM. Detta bekräftar dock ännu inte ett spännings- eller maskinvarufel. För en tillförlitlig diagnos saknas ingångens tilldelning och de giltiga gränsvärdena för det aktuella kortet.

Andra avvikelser ska tolkas lika försiktigt:

Flera fläktkanaler med 0 RPM betyder inte automatiskt att flera fläktar har slutat fungera. Om en modell inte använder dessa anslutningar och samtidigt visar min = 0 RPM kan det vara oanvända kanaler.
Värden som -128 °C, 0 °C, 99 °C eller -1.0 kan representera en sensor som inte är ansluten, inte stöds eller inte har någon användbar tilldelning.
intrusion0: ALARM hör till chassidetekteringen och är inte ett temperaturlarm.
high och crit gäller endast för den sensor där de visas. Ett gränsvärde vid CPUTIN får inte utan belägg överföras till Host_CPU_Temperature.

För en första bedömning är de namngivna värdena i xgs-healthmond.log därför mer tillförlitliga än enskilda oklara råkanaler. Behåll ändå avvikande råvärden i supportutdraget, så att Sophos kan kontrollera dem för den aktuella modellen.

Är Sophos Firewall för varm?

Först måste man skilja mellan omgivningstemperatur och intern komponenttemperatur. Sophos specificerar XGS 118, 128 och 138 för en omgivningstemperatur på 0 till 40 °C. Det avser luften på driftplatsen eller i racket, inte den interna CPU-temperaturen. Den exakta gränsen för den egna modellen finns i respektive Sophos Operating Instructions.

En intern CPU-temperatur på exempelvis 70 °C kan därför inte jämföras med omgivningsgränsen på 40 °C. Sophos publicerar inte heller någon allmängiltig normal CPU- eller NPU-temperatur för samtliga XGS-modeller. Generella påståenden som ”upp till 80 °C är allt normalt” eller ”från 90 °C är brandväggen defekt” är därför inte tillförlitliga.

En meningsfull bedömning kombinerar flera observationer:

Omgivning: mät lufttemperaturen vid appliance-enhetens luftintag, inte bara rumstemperaturen på en avlägsen plats. Vid Chassis_Ambient_Temperature : -1.0 ger brandväggen själv inget användbart omgivningsvärde.
Utveckling: jämför värden från flera mätningar vid jämförbar belastning och rumstemperatur. En ihållande stigande trend är mer informativ än en kort topp.
Fläkt: kontrollera att den fläkt som faktiskt finns är i drift och reagerar på stigande temperatur.
Belastning: dokumentera CPU- och NPU-belastningen vid samma tidpunkt.
Symtom: oväntade omstarter, låsningar, NPU-fel eller återkommande avbrott ökar hur brådskande problemet är.
Modellgräns: kontrollera drift- och rackvillkoren i maskinvaruinstruktionen för den aktuella modellen.

Ett varmt chassi bevisar inte heller i sig ett fel. Det är dock en anledning att kontrollera luftflödet, racktemperaturen, fria ventilationsöppningar och utvecklingen över tid.

Verkligt exempel från en XGS 138

På en XGS 138 med SFOS 22.0 GA Build 411 visade hårdvaruloggen bland annat:

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

Huvudprocessorn var kraftigt belastad vid denna tidpunkt, fläkten var i drift och enligt loggen fortsatte NPU:n att svara korrekt. Det sparade maxvärdet på 82.5 °C bör granskas tillsammans med belastningen, racktemperaturen och det föregående avbrottet. Utdraget innehåller dock inget uttryckligt termiskt fel eller fläktfel och bevisar inte i sig att överhettning orsakade avbrottet.

Denna skillnad är viktig: en omstart kan tillfälligt lindra ett termiskt tillstånd, men också åtgärda ett programvaru-, belastnings- eller processfel. Efter ett avbrott ska därför både temperaturdata och systemloggar sparas.

Fortsatt kontroll efter ett avbrott

Om brandväggen inte svarade eller började fungera igen först efter en omstart räcker inte en enda aktuell temperaturmätning. Händelsen ska dokumenteras som ett möjligt maskinvaru- eller systemfel:

Anteckna modell, serienummer, maskinvarurevision, SFOS-version, build, tidpunkt och observerat beteende.
Kontrollera lufttemperaturen vid luftintaget samt status för kylning, rack och luftflöde.
Spara sensors och de senaste posterna från xgs-healthmond.log.
Sök efter aktuella indikationer i hårdvaru- och systemloggen:

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

Spara en Consolidated Troubleshooting Report och relevanta loggar. Efter en krasch eller omstart kan flyktig information redan ha gått förlorad.
Byt inte fläktar, öppna inte chassit och ändra inte sensorvärden. Efter ett oförklarat avbrott bör ett supportärende öppnas; vid upprepning, otillåten racktemperatur, tydlig temperaturökning, fläktfel eller NPU-problem ökar brådskan.

Inför ett eventuellt utbyte hjälper proceduren Sophos maskinvarufel: förbered RMA och utbyte. SSD-status via SMART är en separat kontroll och besvarar inga frågor om temperatur eller fläkt.

HA och permanent övervakning

I ett HA-kluster ska båda enheterna kontrolleras separat. Varje XGS har egna sensorer, fläktar och lokala felsökningsloggar. En Primary Appliance utan avvikelser bevisar därför inte att Auxiliary Appliance också är termiskt normal. Vid samma rackposition och jämförbar belastning kan peer-enheten samtidigt fungera som ett användbart jämförelsevärde. Roller och åtkomstvägar beskrivs i Sophos Firewall High Availability.

Advanced Shell och hårdvaruloggen är snabba för en engångsdiagnos. I drift ersätter de inte övervakning. Sedan SFOS 22 tillhandahåller Sophos MIB, beroende på XGS-modell, CPU-temperatur, NPU-temperatur och fläkthastighet. Det befintliga avsnittet om SNMP-maskinvaruövervakning beskriver MIB, OID:er, modellgränser, säker SNMPv3-konfiguration och larm.

Bra övervakning samlar först in en baseline och larmar sedan vid bestående avvikelser, avsaknad av förväntade fläktvärden, otillgänglighet och faktiska maskinvarufel. Den ska inte tillämpa en generell CPU-gräns från internet på alla XGS-modeller utan kontroll.

Läs av temperaturen direkt med sensors