이 2025년 기능 요청이 게시되었을 당시 ZimaOS에는 이미 Docker 컨테이너 로그 뷰어가 있었지만, 전체 시스템/저널 로그 뷰어에 대한 요청은 별개로 남아 있었습니다. IceWhale은 초기 답변을 수정하고 앱에 기존의 “터미널 및 로그” 컨트롤이 있음을 보여 주었습니다.
따라서 서로 다른 두 가지 요구 사항을 혼동해서는 안 됩니다. 앱 컨테이너 로그는 애플리케이션 워크플로의 일부인 반면, 호스트 수준의 journalctl 및 시스템 서비스 로그는 더 심층적인 진단에 사용됩니다.
Docker 앱 로그는 이미 사용 가능했습니다
IceWhale이 공개한 스크린샷에는 터미널 및 로그 버튼이 있는 앱 설정 인터페이스가 표시됩니다. 컨테이너가 시작되지 않거나 반복적으로 종료되거나 잘못된 웹 UI를 반환하는 경우, 이 로그를 먼저 확인해야 합니다.
시스템 로그는 다른 계층입니다
이후 커뮤니티 답변에서는 journalctl과 유사한 ZimaOS 전체 로그 뷰어를 구체적으로 요청했습니다. 해당 요청의 결과로 이러한 전체 호스트 로그 브라우저가 제공되었다는 내용은 원본 스레드에 나와 있지 않습니다.
현재 ZimaOS 문서에서도 더 심층적인 진단을 위해 터미널을 사용할 수 있습니다. ZimaOS 기능 개요에는 문제 해결 시 기본 제공 로그와 터미널 액세스를 사용할 수 있다고 안내되어 있습니다.
가장 범위가 좁은 로그 소스부터 사용하세요
Docker 앱 하나에 문제가 있다면 모든 시스템 서비스를 검색하기 전에 해당 앱의 로그를 확인하세요. 스토리지, 네트워크, 부팅 또는 ZimaOS 네이티브 서비스에 문제가 있다면 호스트 터미널과 관련 시스템 로그로 범위를 넓기세요.
Docker 앱 기초에서는 컨테이너 수준의 오류와 호스트 수준의 오류를 구분하는 방법을 설명합니다.
모든 것을 재시작하기 전에 로그를 저장하세요
재시작하면 일시적인 오류를 일으킨 상태가 사라질 수 있습니다. 앱이나 NAS 전체를 재시작하기 전에 오류 내용, 타임스탬프, 컨테이너 이름 및 ZimaOS 버전을 저장하세요.
결론
2025년 요청은 간과된 기능에 부분적으로 기반하고 있었습니다. Docker 로그는 이미 앱 설정 UI에 포함되어 있었습니다. 호스트 전체의 저널 뷰어에 대한 광범위한 요청은 이와는 다릅니다. 앱 오류에는 먼저 앱 로그를 사용하고, 문제가 Docker 하위 계층에 있을 때만 터미널 및 시스템 로그를 확인하세요.
