ZimaOS miał już przeglądarkę logów kontenerów Docker, gdy opublikowano tę prośbę o funkcję w 2025 roku, ale prośba o pełną przeglądarkę logów systemowych i dziennika systemowego pozostała osobną kwestią. IceWhale skorygowało swoją początkową odpowiedź i pokazało istniejący przycisk „Terminal i logi” dla aplikacji.
Oznacza to, że nie należy utożsamiać tych dwóch różnych potrzeb: logi kontenerów aplikacji są częścią procesu obsługi aplikacji, natomiast logi journalctl na poziomie hosta oraz logi usług systemowych służą do bardziej zaawansowanej diagnostyki.
Logi aplikacji Docker były już dostępne
Zrzut ekranu udostępniony przez IceWhale pokazuje interfejs ustawień aplikacji z przyciskiem Terminal i logi. W przypadku kontenera, który nie uruchamia się, wielokrotnie się zamyka lub wyświetla nieprawidłowy interfejs WWW, to właśnie tam należy najpierw sprawdzić logi.
Logi systemowe to inna warstwa
W późniejszej odpowiedzi społeczność poprosiła konkretnie o przeglądarkę logów dla całego ZimaOS, podobną do journalctl. Wątek źródłowy nie wskazuje, że w wyniku tej prośby udostępniono pełną przeglądarkę logów hosta.
Obecna dokumentacja ZimaOS nadal udostępnia terminal do bardziej zaawansowanej diagnostyki. Przegląd funkcji ZimaOS wskazuje, że podczas rozwiązywania problemów dostępne są wbudowane logi i dostęp do terminala.
Najpierw użyj logów z najwęższego zakresu
Jeśli jedna aplikacja Docker nie działa, najpierw sprawdź jej logi, zanim zaczniesz przeszukiwać wszystkie usługi systemowe. Jeśli występują problemy z pamięcią masową, siecią, uruchamianiem systemu lub natywnymi usługami ZimaOS, przejdź do terminala hosta i odpowiedniego logu systemowego.
Podstawy aplikacji Docker pomagają odróżnić awarie na poziomie kontenera od awarii na poziomie hosta.
Zapisz logi przed ponownym uruchomieniem wszystkiego
Restart może usunąć stan, który spowodował przejściową awarię. Przed ponownym uruchomieniem aplikacji lub całego serwera NAS zapisz komunikat błędu, znacznik czasu, nazwę kontenera i wersję ZimaOS.
Podsumowanie
Prośba z 2025 roku częściowo wynikała z przeoczenia istniejącej funkcji: logi Dockera były już dostępne w interfejsie ustawień aplikacji. Szersza prośba o przeglądarkę dziennika obejmującą całego hosta dotyczy czegoś innego. W przypadku awarii aplikacji zacznij od jej logu, a po logi terminala i systemowe sięgaj dopiero wtedy, gdy problem leży poniżej warstwy Dockera.
