Verificar temperatura e ventoinha do Sophos Firewall via SSH

A temperatura não é apresentada no WebAdmin da Sophos Firewall. Contudo, numa appliance XGS física, é possível ler os valores de hardware na Advanced Shell e compará-los com o log de hardware. O comando que devolve os valores brutos dos sensores depende do modelo.

Para uma verificação rápida na XGS 138 aqui testada, bastam inicialmente dois comandos apenas de leitura:

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

O primeiro comando mostra os valores brutos atuais do chip de sensores. O log apresenta os valores mais importantes de forma mais clara como Host_CPU_Temperature, NPU_CPU_Temperature e Fan_Speed_Avg. Um único valor elevado ainda não comprova sobreaquecimento; são decisivos a evolução, a carga, a temperatura ambiente, a ventoinha e as falhas observadas.

⚠️ Importante: A Advanced Shell fornece acesso direto ao sistema operativo. Os comandos apresentados aqui apenas leem informações. Não altere limites dos sensores nem o controlo da ventoinha, não elimine ficheiros e não reinicie serviços.

Ler a temperatura diretamente com `sensors`

Para a verificação, é necessário acesso SSH com o utilizador admin. Depois de iniciar sessão, abra:

5. Device Management
3. Advanced Shell

O artigo Ligar à Sophos Firewall por SSH explica como autorizar o SSH de forma segura e abrir a consola correta.

Na Advanced Shell, execute a vista atual dos sensores:

sensors

O comando foi executado numa XGS 138 com SFOS 22.0 GA Build 411. A CLI dos sensores brutos depende do modelo: para uma XGS 2100, a Sophos Hardware Development indica o seguinte comando quando sensors não devolve valores:

xgs-1us-sensors -a

Estas alternativas só devem ser utilizadas no modelo correspondente. /log/xgs-healthmond.log é a fonte com documentação mais abrangente e deve ser consultada em qualquer caso. Em appliances virtuais, cloud ou de software, os comandos dos sensores de hardware podem não estar disponíveis, porque o SFOS não tem acesso aos sensores físicos do hipervisor ou servidor.

A saída varia consoante o modelo. Normalmente inclui canais de temperatura, velocidades das ventoinhas em RPM, tensões e outros valores brutos do chip de monitorização de hardware. Convém guardar primeiro a saída completa e não filtrar apenas por ALARM. Em alguns modelos, esse filtro mostraria vários canais brutos que existem tecnicamente, mas não estão associados de forma útil.

Verificar valores do produto no log de hardware

A Sophos documenta o ficheiro /log/xgs-healthmond.log em appliances de hardware para a utilização e temperatura da CPU, a velocidade da ventoinha e a porta de gestão da NPU. Os últimos registos são mostrados com:

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

Para uma observação breve, é possível seguir o log em tempo real:

tail -f /log/xgs-healthmond.log

A visualização termina com Ctrl+C. Não é necessário ativar debug. xgs-healthmond.log é o nome de um ficheiro de log, não um nome válido para usar como subsistema de debug.

Neste log, as seguintes linhas são especialmente úteis:

Host_CPU_Temperature: temperatura da CPU principal.
NPU_CPU_Temperature: temperatura da NPU separada, ou Xstream Flow Processor, caso o modelo tenha NPU.
Fan_Speed e Fan_Speed_Avg: velocidade atual ou agregada da ventoinha em RPM.
Host_CPU_Usage e NPU_CPU_Usage: utilização no momento da medição. Ajuda a relacionar um aumento da temperatura com uma carga elevada.
Min, Max, Current e Avg: valores estatísticos mantidos pelo Health Monitor.

A Sophos não documenta publicamente o intervalo exato destas estatísticas. Por isso, Max não deve ser descrito como o valor máximo dos últimos cinco minutos, desde o último reinício ou ao longo de toda a vida útil. Para um pedido de suporte, guarde o valor medido juntamente com o respetivo carimbo de data e hora.

Interpretar corretamente valores brutos e aparentes alarmes

A saída de sensors provém diretamente da monitorização de hardware do Linux. Um chip de sensores pode disponibilizar mais entradas do que aquelas que estão efetivamente ligadas na appliance concreta ou identificadas de forma útil pelo SFOS. Por isso, nem todas as linhas visíveis correspondem a um valor de produto utilizável.

Na XGS 138 testada, surgiram, por exemplo, várias linhas de tensão com este padrão:

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

O valor positivo medido está formalmente acima do máximo programado de 0.00 V, pelo que o chip bruto indica ALARM. Isto ainda não confirma uma falha de tensão ou de hardware. Para um diagnóstico fiável, faltam a associação da entrada e os limites válidos da placa concreta.

Outras anomalias também devem ser interpretadas com cuidado:

Vários canais de ventoinha com 0 RPM não significam automaticamente que várias ventoinhas falharam. Se o modelo não usar essas ligações e mostrar simultaneamente min = 0 RPM, podem ser canais não utilizados.
Valores como -128 °C, 0 °C, 99 °C ou -1.0 podem representar um sensor não ligado, não suportado ou sem uma associação utilizável.
intrusion0: ALARM pertence à deteção da caixa e não é um alarme de temperatura.
high e crit aplicam-se apenas ao sensor junto do qual são apresentados. Um limite em CPUTIN não deve ser transferido para Host_CPU_Temperature sem confirmação.

Para uma primeira avaliação, os valores identificados em xgs-healthmond.log são, por isso, mais fiáveis do que canais brutos isolados e pouco claros. Mesmo assim, mantenha os valores brutos anómalos no extrato destinado ao suporte, para que a Sophos os possa verificar em função do modelo.

A Sophos Firewall está demasiado quente?

Primeiro, é necessário distinguir entre temperatura ambiente e temperatura interna dos componentes. A Sophos especifica uma temperatura ambiente de 0 a 40 °C para as XGS 118, 128 e 138. Trata-se do ar no local de funcionamento ou no rack, não da temperatura interna da CPU. O limite exato do respetivo modelo encontra-se nas Sophos Operating Instructions.

Uma temperatura interna da CPU de, por exemplo, 70 °C não pode, portanto, ser comparada com o limite ambiente de 40 °C. Além disso, a Sophos não publica uma temperatura normal universal de CPU ou NPU para todos os modelos XGS. Afirmações gerais como «até 80 °C é normal» ou «a partir de 90 °C a firewall está avariada» não são, por isso, fundamentadas.

Uma avaliação útil combina várias observações:

Ambiente: medir a temperatura do ar na entrada da appliance, e não apenas a temperatura da sala num ponto afastado. Com Chassis_Ambient_Temperature : -1.0, a própria firewall não fornece um valor ambiente utilizável.
Evolução: comparar valores de várias medições com carga e temperatura da sala semelhantes. Uma tendência persistentemente ascendente é mais informativa do que um pico curto.
Ventoinha: verificar se a ventoinha realmente instalada está a funcionar e reage ao aumento da temperatura.
Carga: registar a utilização da CPU e da NPU no mesmo momento.
Sintomas: reinícios inesperados, bloqueios, erros de NPU ou falhas repetidas aumentam a urgência.
Limite do modelo: consultar as condições de funcionamento e de instalação no rack nas instruções de hardware do modelo concreto.

Uma caixa quente, por si só, também não comprova um defeito. No entanto, justifica a verificação do fluxo de ar, da temperatura do rack, da desobstrução das aberturas de ventilação e da evolução ao longo do tempo.

Exemplo real de uma XGS 138

Numa XGS 138 com SFOS 22.0 GA Build 411, o log de hardware mostrou, entre outros, os seguintes valores:

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

A CPU principal estava sob carga elevada nesse momento, a ventoinha funcionava e, segundo o log, a NPU continuava a responder corretamente. O valor máximo guardado de 82.5 °C deve ser analisado em conjunto com a carga, a temperatura do rack e a falha anterior. Contudo, o excerto não contém uma mensagem explícita de erro térmico ou da ventoinha e, por si só, não comprova que o sobreaquecimento tenha causado a falha.

Esta distinção é importante: um reinício pode aliviar temporariamente uma condição térmica, mas também resolver uma falha de software, carga ou processo. Depois de uma falha, devem ser guardados em conjunto os dados de temperatura e os logs do sistema.

Continuar a verificação após uma falha

Se a firewall deixou de responder ou só voltou a funcionar depois de um reinício, uma única medição atual da temperatura não é suficiente. O incidente deve ser documentado como uma possível falha de hardware ou do sistema:

Registar o modelo, número de série, revisão de hardware, versão do SFOS, build, hora e comportamento observado.
Verificar a temperatura do ar na entrada, bem como o estado da climatização, do rack e do fluxo de ar.
Guardar a saída de sensors e os últimos registos de xgs-healthmond.log.
Procurar indicações atuais no log de hardware e no log do sistema:

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

Guardar um Consolidated Troubleshooting Report e os logs relevantes. Depois de uma falha ou reinício, algumas informações voláteis podem já não estar disponíveis.
Não substituir ventoinhas, não abrir a caixa nem alterar valores dos sensores. Depois de uma falha sem explicação, deve ser aberto um pedido de suporte; em caso de repetição, temperatura inadmissível no rack, aumento acentuado da temperatura, falhas da ventoinha ou problemas de NPU, a urgência aumenta.

Para preparar uma possível substituição, consulte Defeito de hardware Sophos: preparar RMA e substituição. O estado da SSD através de SMART é uma verificação separada e não responde a questões de temperatura ou da ventoinha.

HA e monitorização permanente

Num cluster HA, verifique ambas as appliances separadamente. Cada XGS tem os seus próprios sensores, ventoinhas e logs de troubleshooting locais. Uma Primary Appliance sem anomalias não comprova, por isso, que a Auxiliary Appliance também esteja termicamente normal. Com a mesma posição no rack e carga comparável, o peer pode servir simultaneamente como uma referência útil. As funções e formas de acesso são explicadas em Sophos Firewall High Availability.

Para um diagnóstico pontual, a Advanced Shell e o log de hardware são rápidos. Em operação, não substituem a monitorização. Desde o SFOS 22, a Sophos MIB fornece, consoante o modelo XGS, a temperatura da CPU, a temperatura da NPU e a velocidade da ventoinha. O artigo existente sobre Monitorização de hardware por SNMP explica a MIB, os OID, os limites dos modelos, a configuração segura de SNMPv3 e os alertas.

Uma boa monitorização começa por recolher uma baseline e gera alertas para desvios persistentes, ausência de valores esperados da ventoinha, indisponibilidade e falhas reais de hardware. Não deve aplicar indiscriminadamente a todos os modelos XGS um limite geral de CPU encontrado na Internet.

Ler a temperatura diretamente com sensors