Przejdz do tresci
Avanet

Sprawdzanie temperatury i wentylatora Sophos Firewall przez SSH

Sophos Firewall

Temperatura nie jest wyświetlana w WebAdmin Sophos Firewall. Na fizycznym urządzeniu XGS można jednak odczytać wartości sprzętowe w Advanced Shell i porównać je z logiem sprzętowym. Polecenie zwracające surowe wartości czujników zależy od modelu.

Do szybkiej kontroli na testowanym tutaj XGS 138 wystarczą najpierw dwa polecenia tylko do odczytu:

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

Pierwsze polecenie pokazuje aktualne surowe wartości układu czujników. Log przedstawia najważniejsze wartości w bardziej zrozumiałej postaci jako Host_CPU_Temperature, NPU_CPU_Temperature i Fan_Speed_Avg. Pojedyncza wysoka wartość nie dowodzi jeszcze przegrzania; decydujące są trend, obciążenie, temperatura otoczenia, działanie wentylatora i zaobserwowane awarie.

⚠️ Ważne: Advanced Shell zapewnia bezpośredni dostęp do systemu operacyjnego. Przedstawione tutaj polecenia wyłącznie odczytują informacje. Nie należy ustawiać progów czujników, zmieniać sterowania wentylatorem, usuwać plików ani restartować usług.

Bezpośredni odczyt temperatury za pomocą sensors

Do kontroli potrzebny jest dostęp SSH z użyciem konta admin. Po zalogowaniu należy otworzyć:

5. Device Management
3. Advanced Shell

Sposób bezpiecznego udostępnienia SSH i otwarcia właściwej konsoli opisano w artykule Łączenie z Sophos Firewall przez SSH.

W Advanced Shell należy wywołać aktualny widok czujników:

sensors

Polecenie zostało wykonane na XGS 138 z SFOS 22.0 GA Build 411. Interfejs CLI surowych czujników zależy od modelu: dla XGS 2100 Sophos Hardware Development podaje następujące polecenie, gdy sensors nie zwraca wartości:

xgs-1us-sensors -a

Takich alternatyw należy używać wyłącznie na odpowiednim modelu. /log/xgs-healthmond.log jest szerzej udokumentowanym źródłem i należy go sprawdzić niezależnie od tego. Na urządzeniach wirtualnych, chmurowych lub programowych polecenia czujników sprzętowych mogą być niedostępne, ponieważ SFOS nie ma tam dostępu do fizycznych czujników hiperwizora lub serwera.

Wynik różni się zależnie od modelu. Zwykle obejmuje kanały temperatury, prędkości wentylatorów w RPM, napięcia oraz dodatkowe surowe wartości układu monitorowania sprzętu. Warto najpierw zapisać pełny wynik, a nie filtrować wyłącznie wpisów ALARM. Taki filtr może w niektórych modelach pokazać wiele technicznie istniejących, ale nieprzypisanych w użyteczny sposób kanałów.

Sprawdzanie wartości produktowych w logu sprzętowym

Sophos dokumentuje plik /log/xgs-healthmond.log na urządzeniach sprzętowych jako źródło informacji o obciążeniu i temperaturze CPU, prędkości wentylatora oraz porcie zarządzania NPU. Ostatnie wpisy wyświetla polecenie:

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

Podczas krótkiej obserwacji można śledzić log na żywo:

tail -f /log/xgs-healthmond.log

Wyświetlanie kończy się za pomocą Ctrl+C. Włączanie debugowania nie jest do tego potrzebne. xgs-healthmond.log jest nazwą pliku logu, a nie prawidłową nazwą podsystemu debugowania.

W tym logu szczególnie przydatne są następujące wiersze:

  • Host_CPU_Temperature: temperatura głównego procesora.
  • NPU_CPU_Temperature: temperatura oddzielnego NPU, czyli Xstream Flow Processor, jeżeli dany model ma NPU.
  • Fan_Speed i Fan_Speed_Avg: odpowiednio aktualna i zagregowana prędkość wentylatora w RPM.
  • Host_CPU_Usage i NPU_CPU_Usage: obciążenie w chwili pomiaru. Pomaga powiązać wzrost temperatury z wysokim obciążeniem.
  • Min, Max, Current i Avg: wartości statystyczne prowadzone przez Health Monitor.

Sophos nie dokumentuje publicznie dokładnego przedziału czasu dla tych wartości statystycznych. Dlatego Max nie należy określać jako wartości szczytowej z ostatnich pięciu minut, od ostatniego restartu ani z całego okresu eksploatacji. Na potrzeby zgłoszenia do wsparcia należy zapisać wartość pomiaru wraz ze znacznikiem czasu.

Prawidłowa interpretacja surowych wartości i pozornych alarmów

Wynik polecenia sensors pochodzi bezpośrednio z mechanizmu monitorowania sprzętu w systemie Linux. Układ czujników może udostępniać więcej wejść, niż jest faktycznie podłączonych w danym urządzeniu lub sensownie opisanych przez SFOS. Dlatego nie każdy widoczny wiersz jest użyteczną wartością produktową.

Na testowanym XGS 138 pojawiło się na przykład kilka wierszy napięcia według następującego wzoru:

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

Dodatnia wartość pomiaru formalnie przekracza zaprogramowane maksimum 0.00 V, dlatego układ zgłasza ALARM. Nie potwierdza to jednak jeszcze usterki napięcia ani sprzętu. Do wiarygodnej diagnozy brakuje przypisania wejścia oraz prawidłowych wartości granicznych dla konkretnej płyty.

Równie ostrożnie należy interpretować inne nieprawidłowości:

  • Kilka kanałów wentylatora z wartością 0 RPM nie oznacza automatycznie awarii kilku wentylatorów. Jeżeli model nie używa tych złączy i jednocześnie pokazuje min = 0 RPM, mogą to być nieobsadzone kanały.
  • Wartości takie jak -128 °C, 0 °C, 99 °C lub -1.0 mogą oznaczać czujnik niepodłączony, nieobsługiwany lub nieprzypisany w użyteczny sposób.
  • intrusion0: ALARM dotyczy wykrywania otwarcia obudowy i nie jest alarmem temperatury.
  • high i crit odnoszą się wyłącznie do czujnika, przy którym są wyświetlane. Progu przy CPUTIN nie wolno bez potwierdzenia przenosić na Host_CPU_Temperature.

Do wstępnej oceny nazwane wartości z xgs-healthmond.log są zatem bardziej wiarygodne niż pojedyncze, niejasne kanały surowe. Nietypowe wartości surowe należy mimo to zachować w danych dla wsparcia, aby Sophos mógł sprawdzić je w odniesieniu do konkretnego modelu.

Czy Sophos Firewall jest zbyt gorący?

Najpierw należy odróżnić temperaturę otoczenia od wewnętrznej temperatury podzespołów. Sophos określa dla modeli XGS 118, 128 i 138 temperaturę otoczenia od 0 do 40 °C. Chodzi o powietrze w miejscu pracy lub w szafie, a nie o wewnętrzną temperaturę CPU. Dokładny zakres dla danego modelu znajduje się w odpowiednich Sophos Operating Instructions.

Wewnętrznej temperatury CPU wynoszącej na przykład 70 °C nie można więc porównywać z limitem temperatury otoczenia 40 °C. Sophos nie publikuje również uniwersalnej normalnej temperatury CPU ani NPU dla wszystkich modeli XGS. Ogólne stwierdzenia, takie jak „do 80 °C wszystko jest normalne” lub „od 90 °C firewall jest uszkodzony”, nie mają zatem wystarczającego uzasadnienia.

Rzetelna ocena łączy kilka obserwacji:

  1. Otoczenie: zmierzyć temperaturę powietrza przy wlocie urządzenia, a nie tylko temperaturę pomieszczenia w oddalonym miejscu. Przy wartości Chassis_Ambient_Temperature : -1.0 sam firewall nie dostarcza użytecznego pomiaru otoczenia.
  2. Trend: porównać wartości z kilku pomiarów przy podobnym obciążeniu i temperaturze pomieszczenia. Trwale rosnący trend mówi więcej niż krótki skok.
  3. Wentylator: sprawdzić, czy faktycznie zainstalowany wentylator działa i reaguje na wzrost temperatury.
  4. Obciążenie: zapisać obciążenie CPU i NPU w tym samym momencie.
  5. Objawy: nieoczekiwane restarty, zawieszenia, błędy NPU lub powtarzające się awarie zwiększają pilność.
  6. Limit modelu: sprawdzić warunki pracy i instalacji w szafie w instrukcji sprzętowej konkretnego modelu.

Sama ciepła obudowa również nie dowodzi usterki. Jest jednak powodem do sprawdzenia przepływu powietrza, temperatury w szafie, drożności otworów wentylacyjnych i zmian w czasie.

Rzeczywisty przykład z XGS 138

Na XGS 138 z SFOS 22.0 GA Build 411 log sprzętowy pokazał między innymi:

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

Główny procesor był w tym momencie mocno obciążony, wentylator działał, a zgodnie z logiem NPU nadal odpowiadał prawidłowo. Zapisana wartość maksymalna 82.5 °C wymaga analizy wraz z obciążeniem, temperaturą szafy i wcześniejszą awarią. Fragment nie zawiera jednak jawnego błędu termicznego ani błędu wentylatora i sam w sobie nie dowodzi, że przyczyną awarii było przegrzanie.

To rozróżnienie jest ważne: restart może tymczasowo złagodzić stan termiczny, ale może też usunąć błąd oprogramowania, obciążenia lub procesu. Po awarii należy więc zabezpieczyć zarówno dane temperatury, jak i logi systemowe.

Dalsze sprawdzanie po awarii

Jeżeli firewall nie odpowiadał lub zaczął działać dopiero po restarcie, pojedynczy aktualny pomiar temperatury nie wystarcza. Zdarzenie należy udokumentować jako możliwą usterkę sprzętu lub systemu:

  1. Zanotować model, numer seryjny, rewizję sprzętu, wersję SFOS, build, czas i zaobserwowane zachowanie.
  2. Sprawdzić temperaturę powietrza przy wlocie oraz stan klimatyzacji, szafy i przepływu powietrza.
  3. Zapisać wynik sensors i ostatnie wpisy z xgs-healthmond.log.
  4. Wyszukać aktualne wskazówki w logu sprzętowym i systemowym:
grep -Ei 'temp|thermal|fan|overheat|critical|fault' /log/xgs-healthmond.log /log/syslog.log
  1. Zapisać Consolidated Troubleshooting Report oraz odpowiednie logi. Po awarii lub restarcie część informacji ulotnych może być już niedostępna.
  2. Nie wymieniać wentylatorów, nie otwierać obudowy ani nie zmieniać wartości czujników. Po niewyjaśnionej awarii należy już otworzyć zgłoszenie do wsparcia; przy powtórzeniu, niedopuszczalnej temperaturze w szafie, wyraźnym wzroście temperatury, błędach wentylatora lub problemach z NPU pilność rośnie.

W przygotowaniu ewentualnej wymiany pomaga procedura Usterka sprzętu Sophos: przygotowanie RMA i wymiany. Stan SSD sprawdzany przez SMART jest osobną kontrolą i nie odpowiada na pytania o temperaturę ani wentylator.

HA i stałe monitorowanie

W klastrze HA oba urządzenia należy sprawdzić osobno. Każdy XGS ma własne czujniki, wentylatory i lokalne logi diagnostyczne. Brak problemów na Primary Appliance nie dowodzi zatem, że Auxiliary Appliance również nie ma problemów termicznych. Przy tej samej pozycji w szafie i porównywalnym obciążeniu drugi węzeł może jednocześnie stanowić przydatny punkt odniesienia. Role i sposoby dostępu opisano w artykule Sophos Firewall High Availability.

Advanced Shell i log sprzętowy umożliwiają szybką jednorazową diagnozę. W codziennej eksploatacji nie zastępują monitorowania. Od SFOS 22 Sophos MIB udostępnia, zależnie od modelu XGS, temperaturę CPU, temperaturę NPU i prędkość wentylatora. Istniejący artykuł Monitorowanie sprzętu przez SNMP opisuje MIB, OID, ograniczenia modeli, bezpieczną konfigurację SNMPv3 i alarmowanie.

Dobre monitorowanie najpierw buduje wartość bazową, a następnie alarmuje o trwałych odchyleniach, braku oczekiwanych wartości wentylatora, niedostępności i rzeczywistych usterkach sprzętu. Nie należy bez weryfikacji stosować do wszystkich modeli XGS ogólnego limitu temperatury CPU znalezionego w internecie.