Jellyfin 로그가 시스템 디스크를 가득 채우지 않도록 방지하는 방법

Jellyfin 로그가 데이터베이스, 캐시 또는 운영 체제와 남은 기가바이트를 두고 경쟁할 때까지 커지도록 방치해서는 안 됩니다. Jellyfin 자체의 로그 상세 수준과 동일한 이벤트를 다시 수집할 수 있는 컨테이너 또는 호스트 로깅 계층을 모두 제한하여 장애를 예방하세요.

두 개의 독립적인 로그 경로가 동시에 커질 수 있기 때문에 소형 홈 서버의 시스템 디스크에서는 이를 놓치기 쉽습니다. Jellyfin은 애플리케이션 로그를 기록하는 반면 Docker, journald 또는 다른 감독자는 stdout과 stderr를 별도로 보관할 수 있습니다. 먼저 실제로 공간을 차지하는 경로를 파악한 다음 해당 계층에서 보관량을 제한하고, 정상 사용 중 정리가 이루어지는지 확인하며, 향후 디버그 세션이 디스크를 조용히 가득 채우지 못하도록 여유 공간 알림을 유지하세요.

실제로 증가하는 로그 저장소 찾기

무엇이든 삭제하기 전에 측정하세요. Jellyfin에 설정된 로그 디렉터리의 크기를 컨테이너 런타임 또는 서비스 관리자 로그 저장소와 비교하고, 일반적인 라이브러리 스캔이나 재생 세션을 재현하는 동안 어느 쪽이 변하는지 확인하세요. 한 경로만 증가한다면 여러 로테이션 설정을 한꺼번에 적용하지 말고 해당 경로만 수정하세요.

Jellyfin 문제 해결 가이드에서는 디버그 로깅이 매우 많은 출력을 생성할 수 있으며 짧은 문제 해결 기간에만 사용하도록 안내합니다. 따라서 첫 번째 예방 점검은 사용자 지정 logging.json에서 상세 로그 카테고리가 활성화된 상태로 남아 있는지 확인하는 것입니다. 보관 값을 변경하기 전에 디버그 로깅 안내를 검토하세요.

Jellyfin 자체의 로그 디렉터리는 안정적인데 호스트 시스템 디스크의 여유 공간이 계속 줄어든다면 다음으로 런타임 로그를 점검하세요. 이 경우 Jellyfin 로그 파일을 삭제하는 것은 눈에 보이는 증상만 처리할 뿐이며, 두 번째 로깅 계층은 계속 증가합니다.

런타임 계층에서 보관 한도 설정

컨테이너에서는 무제한 증가에 의존하지 말고 최대 크기가 명확히 정의된 로깅 드라이버와 로테이션 정책을 선택하세요. 새로 생성되는 컨테이너에 설정을 적용하고, 향후 compose 파일을 다시 빌드할 때 보호 설정이 제거되지 않도록 선택한 최대값을 기록해 두세요.

Docker 문서에 따르면 로테이션을 구성하지 않은 기본 json-file 로깅은 상당한 디스크 공간을 사용할 수 있으며, local 드라이버는 기본적으로 로테이션을 수행합니다. 컨테이너 로그 로테이션 동작을 참고하여 max-size/max-file을 제한할지, 로컬 드라이버를 사용할지 결정하세요.

런타임 정책을 변경한 후 런타임에서 요구한다면 Jellyfin 컨테이너를 다시 생성하고, 활성 컨테이너가 실제로 새 드라이버를 사용하는지 확인하세요. 새 컨테이너에만 적용되는 데몬 수준 설정은 Jellyfin 인스턴스가 해당 설정을 물려받기 전까지 성공적인 수정이 아닙니다.

Jellyfin 정리 기능은 유용하게 유지하되 유일한 보호 수단으로 여기지 않기

Jellyfin에는 로그, 캐시, 활동 로그 및 트랜스코드 데이터를 삭제하는 유지 관리 작업이 포함되어 있지만, 예약된 정리는 두 번째 방어선일 뿐 로깅을 무제한으로 방치해도 된다는 의미는 아닙니다. 작업이 실패하거나 지연될 수 있고, 대량의 로그가 발생한 뒤에 실행되어 이미 남은 시스템 공간을 소진할 수도 있습니다.

대시보드 작업 기록에서 로그 정리 작업이 성공적으로 실행되는지 확인한 다음, 다음 예약 실행 전후의 로그 디렉터리 크기를 비교하세요. 디렉터리 크기가 전혀 줄어들지 않는다면 일정을 무작정 단축하지 말고 작업 오류나 경로 불일치를 조사하세요.

홈 서버에서 유용한 방식은 애플리케이션 상태와 미디어 작업 흐름을 확인할 수 있게 유지하면서도 진단 파일이 부팅 디스크를 압도하지 않도록 하는 것입니다. 이러한 리소스 우선 접근 방식은 Jellyfin 버퍼링 문제 해결에도 유용합니다. 로그는 실제 병목 지점을 가리킬 때만 도움이 되기 때문입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

디버그 로깅을 시간을 정한 진단 모드로 사용

디버그 출력이 필요하다면 활성화하기 전에 시작 시간, 재현 시간 범위 및 중지 조건을 정하세요. 오류가 발생한 작업을 캡처하고 관련 로그 구간을 안전한 곳에 저장한 다음, 증거를 수집하는 즉시 설정을 일반 로그 상세 수준으로 되돌리세요.

현재 디스크 공간이 충분하다는 이유만으로 디버그 로깅을 며칠 동안 활성화해 두지 마세요. 트래픽이 적은 저녁 시간과 라이브러리 스캔에서는 생성되는 로그 양이 크게 다를 수 있으므로, 한 번의 테스트에서 무해해 보인 설정이 예약 작업 중에는 큰 비용을 유발할 수 있습니다.

일반 로깅으로 되돌린 후 설정에 필요하다면 한 번 재시작하고, 일반적인 재생과 예약 작업 하나를 재현하세요. 로그 증가율이 기준 수준으로 돌아와야 합니다. 그렇지 않다면 설정을 다시 열고 Jellyfin이 실제로 불러온 파일이 예상한 파일인지 확인하세요.

디스크가 위험 수준에 도달하기 전에 여유 공간 중지 조건 추가

Jellyfin 데이터, 런타임 로그 또는 운영 체제가 포함된 파일 시스템에 간단한 알림을 설정하세요. 호스트 전체에서 쓰기 작업이 실패하기 시작할 때까지 기다리지 말고 원인을 조사하고 서비스를 안전하게 중지할 수 있을 만큼 여유가 남도록 임계값을 정해야 합니다.

여유 공간이 예기치 않게 줄어들면 먼저 대량 로그를 생성하는 소스를 중지하고, 소량의 진단 샘플을 보존한 다음, 폐기해도 되는 것으로 확인된 로그나 캐시만 삭제하세요. 공간을 확보하기 위해 Jellyfin 데이터베이스, 설정 또는 정체를 알 수 없는 볼륨 내용을 먼저 삭제하지 마세요.

정상적인 재생, 라이브러리 작업 및 재시작을 수행해도 증가가 무제한으로 이어지지 않고 알림의 여유 공간이 트리거 기준보다 충분히 높게 유지된다면 예방 조치가 완료된 것입니다. 로깅을 제한했는데도 공간이 계속 줄어든다면 원인이 더 이상 Jellyfin 로그라고 입증되지 않은 것이므로, 보다 광범위한 디스크 사용량 감사를 진행하세요.