Comprobar temperatura y ventilador de Sophos Firewall por SSH

La temperatura no se muestra en WebAdmin de Sophos Firewall. Sin embargo, en un appliance XGS físico se pueden consultar los valores de hardware en la Advanced Shell y compararlos con el log de hardware. El comando que devuelve los valores brutos de los sensores depende del modelo.

Para una primera comprobación en la XGS 138 probada aquí bastan dos comandos de solo lectura:

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

El primer comando muestra los valores brutos actuales del chip de sensores. El log presenta los valores más importantes con mayor claridad como Host_CPU_Temperature, NPU_CPU_Temperature y Fan_Speed_Avg. Un único valor alto no demuestra que exista sobrecalentamiento; también importan la tendencia, la carga, la temperatura ambiente, el ventilador y los fallos observados.

⚠️ Importante: la Advanced Shell proporciona acceso directo al sistema operativo. Los comandos mostrados aquí solo leen información. No modifique los umbrales de los sensores ni el control del ventilador, no elimine archivos ni reinicie servicios.

Leer la temperatura directamente con sensors

La comprobación requiere acceso SSH con el usuario admin. Después de iniciar sesión, abra:

5. Device Management
3. Advanced Shell

El artículo Conectarse a Sophos Firewall por SSH explica cómo permitir SSH de forma segura y abrir la consola correcta.

En la Advanced Shell, consulte la vista actual de sensores:

sensors

El comando se ejecutó en una XGS 138 con SFOS 22.0 GA Build 411. La CLI de sensores brutos depende del modelo: para una XGS 2100, Sophos Hardware Development indica el siguiente comando cuando sensors no devuelve valores:

xgs-1us-sensors -a

Estas alternativas solo deben utilizarse en el modelo correspondiente. /log/xgs-healthmond.log es la fuente con documentación más amplia y debe comprobarse en cualquier caso. En appliances virtuales, cloud o de software, los comandos de sensores de hardware pueden no estar disponibles porque SFOS no puede acceder a los sensores físicos del hipervisor o servidor.

La salida varía según el modelo. Normalmente contiene canales de temperatura, velocidades del ventilador en RPM, voltajes y otros valores brutos del chip de monitorización de hardware. Conviene guardar primero la salida completa en lugar de filtrar solo por ALARM. En algunos modelos, ese filtro mostraría numerosos canales brutos que existen técnicamente, pero que no tienen una asignación significativa.

Comprobar los valores de producto en el log de hardware

Sophos documenta /log/xgs-healthmond.log en appliances de hardware para el uso y la temperatura de la CPU, la velocidad del ventilador y el puerto de gestión de la NPU. Muestre las entradas más recientes con:

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

Para una breve observación, siga el log en tiempo real:

tail -f /log/xgs-healthmond.log

Detenga la salida con Ctrl+C. No es necesario activar la depuración. xgs-healthmond.log es el nombre de un archivo de log, no un nombre válido para usar como subsistema de depuración.

Las siguientes líneas resultan especialmente útiles:

• Host_CPU_Temperature: temperatura de la CPU principal.
• NPU_CPU_Temperature: temperatura de la NPU independiente, o Xstream Flow Processor, si el modelo dispone de una NPU.
• Fan_Speed y Fan_Speed_Avg: velocidad actual y agregada del ventilador en RPM.
• Host_CPU_Usage y NPU_CPU_Usage: uso en el momento de la medición. Ayuda a relacionar una subida de temperatura con una carga elevada.
• Min, Max, Current y Avg: valores estadísticos que mantiene el monitor de estado.

Sophos no documenta públicamente el intervalo de tiempo exacto de estas estadísticas. Por tanto, Max no debe describirse como el pico de los últimos cinco minutos, desde el último reinicio o durante toda la vida útil del appliance. Para un caso de soporte, guarde el valor junto con su marca de tiempo.

Interpretar correctamente valores brutos y aparentes alarmas

La salida de sensors procede directamente de la monitorización de hardware de Linux. Un chip de sensores puede ofrecer más entradas de las que están realmente conectadas en el appliance o etiquetadas de forma útil para SFOS. Por tanto, no todas las líneas visibles representan un valor de producto aprovechable.

En la XGS 138 probada, por ejemplo, aparecían varias líneas de voltaje con este formato:

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

La lectura positiva supera formalmente el máximo configurado de 0.00 V, lo que hace que el chip bruto indique ALARM. Esto por sí solo no confirma un fallo de voltaje o de hardware. Para un diagnóstico fiable se necesitarían la asignación de la entrada y los umbrales válidos de la placa específica.

Otras anomalías aparentes también requieren precaución:

• Varios canales de ventilador que muestran 0 RPM no significan automáticamente que hayan fallado varios ventiladores. Si el modelo no utiliza esos conectores y también muestra min = 0 RPM, pueden ser canales sin usar.
• Valores como -128 °C, 0 °C, 99 °C o -1.0 pueden indicar un sensor desconectado, no compatible o sin una asignación útil.
• intrusion0: ALARM corresponde a la detección de apertura del chasis y no es una alarma de temperatura.
• high y crit solo se aplican al sensor junto al cual aparecen. Un umbral mostrado para CPUTIN no debe trasladarse a Host_CPU_Temperature sin pruebas.

Para una primera evaluación, los valores identificados en xgs-healthmond.log son, por tanto, más fiables que canales brutos individuales poco claros. Aun así, conserve los valores brutos anómalos en el extracto de soporte para que Sophos pueda evaluarlos según el modelo.

¿Está demasiado caliente Sophos Firewall?

Primero hay que distinguir entre temperatura ambiente y temperatura interna de los componentes. Sophos especifica una temperatura ambiente de funcionamiento de 0 a 40 °C para las XGS 118, 128 y 138. Se refiere al aire en el lugar de instalación o dentro del rack, no a la temperatura interna de la CPU. El límite exacto del modelo instalado aparece en sus Sophos Operating Instructions.

Por ejemplo, una temperatura interna de la CPU de 70 °C no puede compararse con el límite ambiente de 40 °C. Sophos tampoco publica una temperatura normal de CPU o NPU que sea válida para todos los modelos XGS. Por tanto, afirmaciones generales como «hasta 80 °C todo es normal» o «por encima de 90 °C el firewall está defectuoso» no serían fiables.

Una evaluación útil combina varias observaciones:

1. Entorno: mida la temperatura del aire en la entrada del appliance, no solo la temperatura de la sala en un punto alejado. Si la salida muestra Chassis_Ambient_Temperature : -1.0, el propio firewall no proporciona un valor ambiente aprovechable.
2. Tendencia: compare mediciones tomadas con cargas y temperaturas ambiente similares. Una tendencia ascendente sostenida es más significativa que un pico breve.
3. Ventilador: compruebe si el ventilador realmente instalado funciona y reacciona cuando aumenta la temperatura.
4. Carga: registre al mismo tiempo el uso de CPU y NPU.
5. Síntomas: reinicios inesperados, bloqueos, errores de NPU o fallos repetidos aumentan la urgencia.
6. Límite del modelo: compruebe las condiciones de funcionamiento y del rack en las instrucciones de hardware del modelo concreto.

Una carcasa caliente por sí sola tampoco demuestra un defecto. Sí indica que deben comprobarse el flujo de aire, la temperatura del rack, que las aberturas de ventilación estén libres y la evolución de la temperatura.

Ejemplo real de una XGS 138

En una XGS 138 con SFOS 22.0 GA Build 411, el log de hardware mostraba, entre otros:

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

En ese momento, la CPU principal tenía una carga elevada, el ventilador estaba funcionando y, según el log, la NPU seguía respondiendo correctamente. Merece la pena analizar el máximo registrado de 82.5 °C junto con la carga, la temperatura del rack y el fallo anterior. Sin embargo, el extracto no contiene ningún error térmico o del ventilador explícito y por sí solo no demuestra que el sobrecalentamiento causara el fallo.

Esta distinción es importante: un reinicio puede aliviar temporalmente una situación térmica, pero también puede resolver un problema de software, carga o proceso. Por ello, después de un fallo deben guardarse juntos los datos de temperatura y los logs del sistema.

Continuar correctamente el diagnóstico después de un fallo

Si el firewall dejó de responder o solo volvió a funcionar después de un reinicio, una única medición de temperatura actual no es suficiente. Documente el incidente como un posible fallo de hardware o del sistema:

1. Anote el modelo, número de serie, revisión de hardware, versión de SFOS, build, hora y comportamiento observado.
2. Compruebe la temperatura del aire en la entrada y el estado de la climatización, el rack y el flujo de aire.
3. Guarde la salida de sensors y las entradas más recientes de xgs-healthmond.log.
4. Busque indicios relevantes en los logs actuales de hardware y del sistema:

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

5. Guarde un Consolidated Troubleshooting Report y los logs relevantes. Después de un fallo o reinicio, es posible que ya falte información volátil.
6. No sustituya ventiladores, no abra el chasis ni modifique valores de sensores. Un fallo sin explicación ya justifica abrir un caso de soporte; los fallos repetidos, una temperatura excesiva en el rack, un aumento significativo de la temperatura, errores del ventilador o problemas de NPU aumentan la urgencia.

Para una posible sustitución, siga Fallo de hardware Sophos: preparar RMA y sustitución. La comprobación del estado del SSD mediante SMART es una prueba independiente y no responde a cuestiones de temperatura o ventilador.

HA y monitorización continua

En un clúster HA, compruebe ambos appliances por separado. Cada XGS tiene sus propios sensores, ventiladores y logs locales de troubleshooting. Que el appliance primario no presente anomalías no demuestra que el auxiliar tampoco tenga problemas térmicos. Con la misma posición en el rack y una carga comparable, el otro nodo también puede servir como referencia útil. El artículo Alta disponibilidad de Sophos Firewall explica las funciones y las vías de acceso.

La Advanced Shell y el log de hardware son rápidos para un diagnóstico puntual, pero no sustituyen a la monitorización operativa. Desde SFOS 22, la MIB de Sophos proporciona, según el modelo XGS, la temperatura de la CPU, la temperatura de la NPU y la velocidad del ventilador. Monitorización de hardware por SNMP explica la MIB, los OID, las limitaciones del modelo, la configuración segura de SNMPv3 y las alertas.

Una buena monitorización establece primero una línea base y genera alertas ante desviaciones sostenidas, ausencia de valores esperados del ventilador, falta de conectividad y fallos reales de hardware. No debe aplicar sin verificación a todos los modelos XGS un límite genérico de CPU encontrado en Internet.