Tworzenie kopii zapasowych i analiza zrzutów pamięci systemu Linux za pomocą narzędzia kdump

Co rejestruje kdump w przypadku awarii jądra

kdump przygotowuje kopię zapasową obrazu pamięci jądra systemu Linux przed wystąpieniem awarii. W tym celu podczas uruchamiania standardowego jądra rezerwowany jest obszar pamięci. W tym obszarze tworzony jest oddzielny Jądro Capture załadowany, który w razie odpowiedniego zdarzenia awaryjnego może zostać uruchomiony za pomocą kexec.

Jądro Capture działa niezależnie od awaryjnego jądra systemu i uzyskuje dostęp do jego obrazu pamięci poprzez /proc/vmcore. Może on zapisać ten obraz w skonfigurowanym miejscu docelowym. Zapisany plik nosi zazwyczaj nazwę vmcore; to, czy zawiera on wszystkie pierwotne obszary pamięci, zależy między innymi od wybranego filtrowania.

Zadania są rozdzielone: kdump rejestruje i archiwizuje stan, podczas gdy program crash następnie analizuje istniejący zrzut pamięci. Pozwala to na przykład na zbadanie komunikatów jądra i stosów zadań. Zrzut pamięci stanowi przy tym migawkę i nie dostarcza automatycznie pełnej historii błędu.

Błąd „oops” jądra nie jest równoznaczny z paniką jądra: błąd „oops” może wystąpić bez natychmiastowego przejścia systemu w stan paniki. Dlatego nie każda awaria jądra prowadzi do utworzenia pliku kdump. Z kolei plik core dump aplikacji dotyczy stanu procesu i nie jest plikiem vmcore jądra.

Przygotowanie to ma kluczowe znaczenie dla późniejszej analizy. Jeśli w momencie awarii nie przygotowano jądra przechwytującego lub nie utworzono kopii obrazu, narzędzie kdump nie będzie w stanie odtworzyć utraconego stanu pamięci. Wówczas punktem wyjścia będą dostępne logi oraz inne dane diagnostyczne zachowane po ponownym uruchomieniu systemu.

Warunki i ograniczenia rejestracji

Najpierw ustal dystrybucję, wersję i architekturę serwera. Od tego zależą nazwy pakietów, sterowanie usługami, konfiguracja rozruchu oraz obsługiwane lokalizacje przechowywania danych. Do konfiguracji korzystaj z dokumentacji właśnie tej platformy, zamiast łączyć polecenia z różnych dystrybucji; na wymagania wpływają również sprzęt i zainstalowane sterowniki.

Parametr rozruchowy crashkernel określa Rezerwacja pamięci do rejestracji awarii. Obszar ten nie jest dostępny w trybie normalnej pracy. Nie można polegać na wartości ogólnej: należy kierować się wytycznymi dotyczącymi dystrybucji, architektury i konkretnego wyposażenia oraz uwzględnić zapotrzebowanie na pamięć systemu rejestrującego.

Sama zarezerwowana pamięć nie wystarczy. Jądro Capture musi być załadowane i musi mieć możliwość połączenia się ze skonfigurowanym celem. W tym celu w jego środowisku muszą być dostępne niezbędne sterowniki i komponenty; w przypadku celu sieciowego do warunków wstępnych należy również połączenie oraz dostępność stacji docelowej.

Należy zapewnić w lokalizacji docelowej wystarczającą pojemność na oczekiwane kopie i ich przechowywanie. Wielkość zrzutu danych zależy między innymi od zawartości pamięci i zastosowanych filtrów. Pełna lub niedostępna lokalizacja docelowa może uniemożliwić wykonanie kopii zapasowej, nawet jeśli rezerwacja została poprawnie ustawiona.

Nawet przygotowana instalacja nie gwarantuje uzyskania użytecznego zrzutu. Błąd typu „Oops” niekoniecznie powoduje stan paniki; w przypadku całkowitej utraty zasilania jądro przechwytujące nie może już działać. Podobnie poważna awaria sprzętowa może uniemożliwić jego uruchomienie lub zapisanie obrazu. Dlatego też proces przechwytywania i cel należy rozpatrywać oddzielnie od rzeczywistej przyczyny błędu.

Jakie pliki są brane pod uwagę podczas analizy

Do analizy liczy się nie tylko plik zrzutu pamięci. Jeśli to możliwe, zachowaj również powiązane pliki jądra i logi, aby można było porównać stan w momencie awarii z komunikatami i zmianami. Poniższy przegląd oddziela właściwy obraz pamięci od plików pomocniczych, które umożliwiają jego analizę.

Jest to szczególnie ważne odpowiedni plik vmlinux: Architektura i dokładna kompilacja jądra muszą odpowiadać jądru systemu, które uległo awarii. Jądro działające po ponownym uruchomieniu może być inne. Wynik polecenia uname -r na nowo uruchomionym serwerze nie wystarczy zatem, aby wybrać właściwy plik dla starego zrzutu.

Ponadto należy użyć wersji programu crash zgodnej z jądrem i formatem zrzutu. Jeśli mają znaczenie sterowniki zewnętrzne lub dodatkowe, należy również przygotować odpowiednie pliki modułów i informacje debugowania. W przypadku braku symboli lub odfiltrowania niezbędnych stron pamięci analiza może być ograniczona; takie luki należy uwzględnić w dokumentacji wyników.

Plik vmcore może zawierać poufne dane z pamięci operacyjnej. Dlatego należy ograniczyć dostęp do niego, zabezpieczyć jego przesyłanie oraz określić terminy przechowywania i usuwania. Przed przekazaniem zrzutu pamięci lub dodatkowych logów do działu wsparcia technicznego należy ustalić, czy wymagana jest na to zgoda oraz jaki jest dopuszczalny zakres przekazywanych danych.

Przygotowanie narzędzia kdump na serwerze

Punktem wyjścia są dystrybucja, wersja i architektura serwera. Sprawdź w dokumentacji danej dystrybucji, jakie pakiety są potrzebne do działania narzędzia kdump i załadowania jądra przechwytującego oraz w jaki sposób należy skonfigurować tę usługę. Instrukcje dla różnych dystrybucji nie są między sobą zamienne: nazwy pakietów, konfiguracja rozruchu i narzędzia diagnostyczne mogą się różnić.

Częścią przygotowań jest odpowiedni Rezerwacja pamięci poprzez parametr rozruchowy crashkernel. Wybierz rozmiar i, w razie potrzeby, dodatkowe ustawienia zgodnie z wytycznymi dla konkretnej platformy i sprzętu. Zarezerwowana pamięć nie jest dostępna dla normalnie działającego systemu; dlatego podanie uniwersalnej wartości rozmiaru byłoby równie mało pomocne, jak niepotwierdzone przejęcie ustawień z innego serwera.

Po skonfigurowaniu rozruchu zgodnie z wymaganiami danej platformy i ewentualnym ponownym uruchomieniu system, poniższe polecenie powłoki w trybie odczytu wyświetla parametry aktualnie uruchomionego jądra. W wynikach wyszukaj crashkernel. Wpis ten pokazuje przekazane ustawienie, ale nie potwierdza ani załadowania jądra przechwytującego, ani pomyślnego wykonania kopii zapasowej.

cat /proc/cmdline

W systemie RHEL 9 można dodatkowo sprawdzić stan za pomocą poniższego polecenia w powłoce. W przypadku innych dystrybucji należy skorzystać z metody sprawdzania opisanej w ich dokumentacji. Wynik pozytywny Komunikat o stanie stanowi ważną wskazówkę co do gotowości, ale nie zastępuje kontrolowanego testu całego łańcucha zabezpieczeń.

kdumpctl status

Sprawdź również, czy w systemie Capture dostępny jest wybrany cel oraz niezbędne do tego sterowniki. Zapisz wybrane ustawienia oraz datę i godzinę sprawdzenia, aby móc je ponownie ocenić po zmianach w jądrze systemu lub infrastrukturze. Przed wdrożeniem należy sprawdzić konkretne ustawienia pod kątem faktycznie używanej platformy docelowej.

Wybierz cel tworzenia kopii zapasowej i zakres zrzutu

Das Cel zabezpieczenia musi być dostępny podczas gromadzenia danych i zapewniać wystarczającą ilość wolnego miejsca. Lokalna lokalizacja docelowa pozwala uniknąć zależności od połączenia sieciowego, wymaga jednak wolnego miejsca na serwerze. Należy również uwzględnić, że wiele zapisanych zrzutów i towarzyszących im plików diagnostycznych może zajmować sporo miejsca.

RHEL 9 dokumentuje nie tylko cele lokalne, ale także cele sieciowe za pośrednictwem NFS lub SSH. Dzięki temu plik można przechowywać oddzielnie od danego serwera; w tym celu sieć, stacja docelowa oraz niezbędne komponenty w systemie przechwytywania muszą działać prawidłowo. Należy sprawdzić odpowiednie ograniczenia konkretnej konfiguracji RHEL, zamiast zakładać, że dostępność w normalnym trybie pracy jest taka sama jak w systemie przechwytywania.

Z makedumpfile obraz można skompresować i przefiltrować według wybranych obszarów pamięci. Filtrowanie może to pozwolić zaoszczędzić miejsce na dysku i zmniejszyć objętość przesyłanych danych, ale powoduje usunięcie stron, które mogą okazać się niezbędne przy późniejszym analizowaniu problemu. Dlatego zakres zrzutu danych należy dostosować do przewidywanej diagnozy i udokumentować zastosowane filtry; najmniejszy plik niekoniecznie jest najbardziej przydatny.

Plik vmcore może zawierać poufne dane z pamięci operacyjnej. Należy zatem ograniczyć dostęp do niego, zabezpieczyć jego przesyłanie oraz określić, jak długo pliki mają być przechowywane i kiedy mają zostać usunięte. Przed przekazaniem pliku do działu pomocy technicznej należy uzyskać niezbędną zgodę; dotyczy to również kopii przechowywanych oddzielnie.

Otwarcie istniejącego pliku vmcore za pomocą programu crash

Do późniejszej analizy potrzebny jest dostępny plik vmcore, zgodny z wersją jądra, w której nastąpiła awaria, oraz z architekturą vmlinux z informacjami debugowania a także wersję programu crash zgodną z jądrem i formatem zrzutu. Jądro działające po ponownym uruchomieniu może być inne; sam komunikat o wersji nie pozwala zatem w sposób wiarygodny zidentyfikować kompilacji, w której doszło do awarii.

Poniższe schematyczne polecenie należy wprowadzić w zwykłej powłoce systemu analitycznego. Należy zastąpić obie ścieżki rzeczywistymi lokalizacjami plików. Polecenie to otwiera istniejący obraz w celu analizy; nie tworzy ono ani zrzutu, ani nie uruchamia programu kdump.

crash /pfad/zum/passenden/vmlinux /pfad/zum/vmcore

Po pomyślnym rozpoczęciu pracy będziesz zajmować się komunikat o awarii, a nie już w zwykłej powłoce. Tam wyświetla się log dostępne komunikaty jądra. Najpierw poszukaj komunikatu o panice oraz komunikatów z tego samego przedziału czasowego; komunikaty mogą stanowić punkt wyjścia, ale niekoniecznie opisują pełną przyczynę.

Z bt analizujesz stos bieżącego kontekstu analizy; bt -a wyświetla stosy aktywnych zadań na procesorach. Porównaj łańcuchy wywołań z komunikatami, zamiast traktować pojedynczą ramkę jako dowód winy. W zależności od stanu i zakresu zrzutu mogą brakować niektórych informacji.

W tym samym oknie poleceń pomocne jest ps w przeglądzie zadań; kmem -i dostarcza ogólnych informacji o pamięci. Sam ten zrzut nie dowodzi ani istnienia wycieku pamięci, ani tego, co go powoduje. Jeśli konieczne jest dokładniejsze zbadanie danego modułu, mogą być dodatkowo potrzebne odpowiednie pliki modułu oraz informacje debugowania.

Klasyfikowanie stosów i wskazówek dotyczących pamięci

Jeśli po zmianie sterownika wystąpi błąd typu „panic”, najpierw zanotuj moment wystąpienia, wersję jądra, w której doszło do awarii, oraz moduły, które miały w tym udział. Porównaj te informacje z protokołem zmian: czy zaktualizowano tylko sterownik, czy też jednocześnie zainstalowano nowe jądro? W ten sposób można zawęzić zakres zmian istotnych dla analizy.

Następnie przeczytaj log dostępne komunikaty jądra i sprawdź za pomocą bt stos bieżącego kontekstu analizy. bt -a uzupełnia obraz aktywnych zadań procesorów. Oprócz treści komunikatu o awarii zanotuj również komunikaty, które poprzedzały tę awarię; mogą one dostarczyć kontekstu dla błędu, który pojawi się później.

A Rama napędowa Obecność tego błędu w stosie stanowi punkt wyjścia, ale nie dowód winy. Na przykład wcześniejsze uszkodzenie pamięci może ujawnić się dopiero w funkcji sterownika. Dlatego przed uznaniem zmiany za przyczynę sprawdź, czy komunikaty, zaangażowane moduły i przebieg zdarzeń są ze sobą spójne.

W przypadku podejrzenia o przechowywanie dostarcza kmem -i przegląd informacji dotyczących pamięci, o ile są one dostępne w zrzucie pamięci i narzędziu. Należy analizować te wartości w połączeniu z komunikatami jądra. Pojedyncza wartość nie wskazuje ani na wyciek pamięci, ani na jego przyczynę; ponadto w wyniku filtrowania mogą brakować niektórych stron pamięci.

Aby odpowiedzieć na pytanie, czy zużycie rośnie w miarę upływu czasu, potrzebujesz dodatkowych szeregów czasowych. W przypadku odrębnej analizy obciążenia procesora można Profilowanie procesora za pomocą narzędzia Linux Perf pomóc. Takie pomiary stanowią uzupełnienie zrzutu pamięci po awarii, ale nie zastępują stanu zarejestrowanego w nim w momencie awarii.

Jeśli nie ma pliku vmcore nadającego się do wykorzystania

Po zawieszeniu się systemu i jego ponownym uruchomieniu należy najpierw sprawdzić, czy w ogóle doszło do sytuacji typu „panic” oraz czy został zapisany plik vmcore. Samo ponowne uruchomienie nie potwierdza żadnej z tych rzeczy. Przed wyciągnięciem wniosków o konkretnym błędzie na podstawie braku pliku, poszukaj komunikatów z odpowiednim czasem wystąpienia oraz sprawdź skonfigurowaną lokalizację zapisu.

Zbadaj Łańcuch rejestracji Osobno: Czy dla danego systemu został załadowany jądro przechwytujące i czy zdarzenie to kwalifikowało się do uruchomienia programu kdump? Nie każda sytuacja typu „oops” prowadzi do paniki. Całkowita utrata zasilania lub poważna awaria sprzętowa mogą ponadto uniemożliwić uruchomienie jądra przechwytującego lub zapisanie danych.

Następnie sprawdź miejsce docelowe kopii zapasowej: czy było dostępne, czy było wystarczająco dużo miejsca i czy system Capture zawierał niezbędne sterowniki i komponenty? W przypadku miejsca docelowego w sieci należy dodatkowo uwzględnić połączenie i stację docelową jako czynniki zależne. W systemie RHEL plik kexec-dmesg.log Podaj informacje dotyczące fazy rejestracji, o ile została ona utworzona i zapisana.

W przypadku braku nadającego się do wykorzystania pliku dumpu ważną alternatywą są wcześniejsze dzienniki lub trwałe komunikaty konsoli i jądra. Źródła te nie dostarczają jednak pełnego obrazu pamięci; utraconego stanu nie da się później odtworzyć za pomocą narzędzia kdump.

Jeśli komunikaty lub inne obserwacje wskazują na problemy z siecią, można przeprowadzić dodatkową Analiza wykorzystania SoftIRQ w systemie Linux pomaga w klasyfikacji przetwarzania pakietów. Odpowiada ona na inne pytanie niż sprawdzenie miejsca docelowego zrzutu i sama w sobie nie świadczy ani o wystąpieniu sytuacji krytycznej, ani o przyczynie nieudanej kopii zapasowej.

Przetestowanie rejestracji i zabezpieczenie wyników

Zakres zrzutu danych należy dobrać w zależności od przewidywanego pytania diagnostycznego oraz dostępnych zasobów. Kompresja i filtrowanie mogą pozwolić zaoszczędzić miejsce na dysku i zmniejszyć objętość przesyłanych danych; usunięte strony pamięci nie będą jednak dostępne do późniejszych analiz. Należy udokumentować tę decyzję, aby podczas analizy można było rozpoznać, jakie dane mogą brakować.

Plik vmcore może zawierać poufne dane z pamięci. Dlatego należy uregulować kwestie dostępu, bezpiecznego przesyłania i okresu przechowywania, a także sposobu archiwizacji odpowiednich plików debugowania. Przed przekazaniem danych do działu pomocy technicznej należy ustalić niezbędne uprawnienia oraz przewidziany sposób postępowania z danymi.

Sprawdź ponownie przygotowania, jeśli zmienią się jądro, sterowniki, konfiguracja rozruchu lub infrastruktura tworzenia kopii zapasowych. Obejmuje to załadowane jądro przechwytujące oraz dostępność wybranego miejsca docelowego. Pozytywny komunikat o stanie jest przydatny, ale sam w sobie nie wskazuje, czy w aktualnych warunkach faktycznie powstaje zrzut, który można poddać analizie.

Ostrzeżenie: Kontrolowany test typu „end-to-end” celowo powoduje awarię systemu i może skutkować ponownym uruchomieniem oraz utratą danych. Należy go przeprowadzać wyłącznie w zatwierdzonym środowisku testowym lub w wyznaczonym oknie serwisowym po wykonaniu kopii zapasowej danych. Należy wcześniej ustalić zakres odpowiedzialności, skutki oraz procedurę przywrócenia działania; celowo nie podano polecenia wywołującego ten test.

Wyczerpujący Test typu end-to-end Nie poprzestawaj na sprawdzeniu statusu: sprawdź, czy plik dotarł do przeznaczonego miejsca docelowego i czy można go otworzyć wraz z plikami pasującymi do zarejestrowanej kompilacji. Następnie podczas debugowania serwera odnotuj ustalenia, brakujące dane, niejasności oraz kolejne kroki weryfikacyjne. W tym procesie wyraźnie oddziel zaobserwowane wskazówki od przyczyn, które nie zostały jeszcze potwierdzone.