Jak sprawdzić nieoczekiwane zamknięcie serwera Linux?

Na nowym serwerze Xeon 55XX z 4xSSD podczas rajdu 10 z Debianem 6, doświadczyłem 2 losowych wyłączeń w ciągu dwóch tygodni po zbudowaniu serwera. Przeglądanie dzienników przepustowości przed wyłączeniem nie wskazuje na nic niezwykłego. Obciążenie serwera jest zwykle bardzo niskie (około 1) i jest ono kolokowane bardzo daleko. Wydaje się, że nie ma przerwy w zasilaniu, gdy serwer nie działa.

Wiem, że patrzę na / var / log, ale nie jestem pewien, które dzienniki powinienem sprawdzić i czego powinienem szukać. Doceń swoje wskazówki.

Najpierw muszę zapytać: „wyłączenia”? Czy masz na myśli to, że maszyna uruchomi się ponownie, czy faktycznie się zatrzymuje? Jeśli się zatrzyma, jest albo źle skonfigurowany (być może w BIOS-ie), albo coś aktywnie wyłącza maszynę (np. Init 0).

Jeśli nie, twoim głównym kandydatem będzie / var / log / syslog i /var/log/kern.log, ponieważ twój problem brzmi jak panika jądra lub błąd sprzętowy wywołany przez oprogramowanie. Oczywiście, jeśli serwer uruchamia jakąś usługę (np. Apache), może dać ci wskazówkę.

Często w takich sytuacjach generowane są wpisy dziennika, ale ponieważ urządzenie ma problemy, nie będzie w stanie zapisać wpisów na dysku. Jeśli skrzynka jest kolokowana, istnieje prawdopodobieństwo, że jest ona podłączona do konsoli szeregowej przez partnera colo. Właśnie tam bym szukał, gdybym nie znalazł niczego podejrzanego w powyższych logach.

Jeśli maszyna nie jest podłączona do konsoli szeregowej i w dzienniku nie ma nic, możesz rozważyć wysłanie syslog do innego urządzenia przez sieć. Być może interfejs sieciowy przetrwa nieco dłużej, a komunikaty dziennika można odczytać na serwerze syslog. Spójrz na rsyslog lub syslog-ng.

AKTUALIZACJA:

Zgadzam się z @Johann poniżej. Najbardziej prawdopodobną przyczyną zatrzymania jest kontrola temperatury procesora. Spróbuj sprawdzić / wykreślić temperaturę w skrzynce za pomocą czujników lub smartctl (zazwyczaj najłatwiejszych). Uważam, że kolekcjonowanie nie ma sobie równych w śledzeniu dużej liczby zmiennych w czasie. Może obsługiwać zarówno czujniki IPMI, jak i lm oraz hddtemp. Ponadto niektóre BIOS: es rejestrują zdarzenia zatrzymania temperatury.

Najpierw chcesz to sprawdzić /var/log/syslog. Jeśli nie jesteś pewny, czego szukać, można rozpocząć szukając słów error, panici warning.

grep -i error /var/log/syslog

Jeśli masz dostępne wykresy systemowe (np. Munin). Sprawdź je i poszukaj nienormalnych wzorów. Jeśli nie masz zainstalowanego Munina, być może warto go zainstalować ( apt-get install munin munin-node)

Powinieneś również sprawdzić pocztę root pod kątem interesujących wiadomości, które mogą być związane z awarią systemu.

Inne pliki dziennika, które należy sprawdzić, to dzienniki błędów aplikacji. Np. /var/log/apache2/error.logLub podobny. Mogą zawierać informacje prowadzące do problemu.

Z mojego doświadczenia wynika, że ​​„nieoczekiwany postój” prawie zawsze jest spowodowany przegrzaniem. Sprawdź swoje temperatury i prędkości wentylatora za pomocą czujników lm_sensors i upewnij się, że są dobre.

Ostatnio mieliśmy ten sam wzorzec: serwer zatrzymał się około godzinę po ręcznym uruchomieniu wsparcia. Po tych godzinach temperatura procesora osiągnęła skonfigurowany próg w systemie BIOS (iirc 60 lub 70 ° C) i zatrzymała system. Wszystkie te problemy były spowodowane uszkodzonym wentylatorem procesora. Po wymianie wentylatora wszystko wróciło do normy.

W katalogu / var / log (i jego podkatalogach) znajduje się wiele plików dzienników, w tym

/var/log/boot

i

/var/log/boot.log

Zacznij od plików powyżej.

Istnieją 2 sposoby sprawdzenia, co spowodowało zamknięcie systemu, najpierw sprawdź konsolę zarządzania pozapasmowego pod kątem problemów ze sprzętem. Sugeruję skonfigurowanie SNMP i otrzymywanie wiadomości e-mail lub dodawanie pułapek w oprogramowaniu monitorującym pod kątem dowolnego ostrzeżenia.

Następnie za pomocą systemu operacyjnego możesz sprawdzić /var/log/messages(dystrybucje oparte na RedHat) lub /var/log/syslog(dystrybucje oparte na Debianie).

Podsystem dyskowy jest na tyle skomplikowany, że można go dotknąć, gdy wystąpi problem, ponieważ prawie nie ma nic w plikach dziennika.

Spróbuj zalogować się do konsoli szeregowej. To wymaga trochę okablowania i innego systemu do odbierania linii, ale masz większą szansę na złapanie problemu.

Oczywiście, jeśli twój węzeł ma wbudowany system zarządzania podobny do Oracle ALOM / ILOM, możesz również sprawdzić ewentualne problemy i tam zapisać pliki dziennika.

Możesz sprawdzić, czy system wie o tym, że spadał z następnymi poleceniami

sudo last -1x reboot
sudo last -1x shutdown

Jeśli brak informacji =>, może to oznaczać utratę mocy lub coś zewnętrznego

jeśli masz informacje => wyszukaj w dziennikach dotyczących czasu ponownego uruchomienia / zamknięcia