Docker 로그가 호스트 부팅 드라이브를 가득 채우지 않게 하려면 어떻게 해야 하나요?

즉시 로그를 생성하는 프로세스를 중지하고, 활성 로그 저장 위치를 확인한 다음, 제한된 로테이션을 적용하고 폭증을 일으킨 오류나 재시작 루프를 해결하세요.

Docker 기반 NAS 또는 홈 서버에서는 미디어와 데이터베이스가 다른 풀에 저장되어 있어도 부팅 드라이브가 가득 찰 수 있습니다. 컨테이너의 표준 출력과 표준 오류, systemd 저널 데이터, 애플리케이션 자체 로그 파일이 여전히 시스템 파일 시스템 아래에 남아 있을 수 있기 때문입니다. 안전한 순서는 최근 증거를 충분히 보존하고, 통제되지 않은 증가를 중지하며, 공간을 차지하는 로깅 계층을 분류하고, 기존 및 향후 서비스에 보존 정책을 구성한 뒤, 기반 애플리케이션이 더 이상 같은 양의 로그를 생성하지 않는지 확인하는 것입니다.

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

부팅 파일 시스템의 여유 공간을 확인한 다음 Docker 데이터 루트, 컨테이너별 로그 파일, 시스템 저널, 호스트에서 마운트된 애플리케이션 로그 디렉터리의 크기를 비교하세요. 삭제하거나 잘라내기 전에 가장 큰 경로를 기록해 두세요.

한 Docker 디스크 공간 사례에서는 기본 Docker 요약 정보만으로는 주요 사용처가 드러나지 않았습니다. 기본 로그 파일이 별도로 증가하고 있었기 때문입니다. 결정적인 증거는 로컬 Docker 저장 경로 아래에서 계속 증가하는 컨테이너 로그였습니다.

실행 중인 각 컨테이너에 설정된 로그 드라이버와 로그 경로를 확인한 다음, 가장 큰 파일을 컨테이너 이름 및 최근 메시지와 대조하세요. 컨테이너 로그로 사용량이 설명되지 않는다면 모든 Docker 관련 디스크 문제가 json-file에 해당한다고 가정하지 말고 journald와 애플리케이션 자체 로그 폴더를 계속 확인하세요.

긴급 정리 전에 시끄러운 컨테이너 중지하기

부팅 드라이브가 가득 차기 직전이라면 가장 빠르게 증가하는 로그를 생성하는 컨테이너를 일시 중지하거나 중지하세요. 공간을 확보하기 전에 로그의 제한된 마지막 부분, 재시작 횟수, 종료 상태, 이미지 버전, 환경 변수, 마운트 정보, 반복되기 시작한 첫 번째 오류를 저장하세요.

관리자는 크기 제한이 설정되지 않은 경우 컨테이너 JSON 로그가 남은 디스크 공간을 모두 소모할 수 있다는 사실을 흔히 발견합니다. 장기간 이어진 Stack Overflow 논의에서는 제한 없는 JSON 로그 증가를 이미지 및 볼륨 데이터와는 별개의 용량 위험으로 설명합니다.

Docker가 활성 로그 파일을 여전히 열고 있는 상태에서 무작정 삭제하지 말고, Docker 메타데이터 트리에서 임의의 디렉터리를 절대 제거하지 마세요. 로그 생성자를 중지한 후에만 플랫폼에서 지원하는 로테이션 또는 잘라내기 절차를 사용하고, 영향을 받은 서비스를 다시 시작하기 전에 확보된 블록이 실제로 표시되는지 확인하세요.

장시간 실행되는 각 서비스에 제한된 로테이션 적용하기

Compose 서비스 또는 컨테이너 설정에서 명시적인 로그 드라이버와 유한한 로테이션 제한을 설정하세요. 일반적인 JSON 드라이버에서는 최대 파일 크기와 보존할 파일 수를 제한하는 것이 중요합니다.

Docker 커뮤니티의 로테이션 관련 논의에서는 max-size 및 max-file과 같은 옵션이 컨테이너 하나가 보존하는 로컬 기록의 양을 제한한다고 설명합니다. 운영상 필요한 것은 무한히 증가하는 파일 하나가 아니라 유한한 로테이션 정책입니다.

사고를 얼마나 신속하게 진단해야 하는지와 호스트가 안전하게 예약할 수 있는 부팅 디스크 공간을 기준으로 제한을 선택하세요. 실행 중인 컨테이너에 새 로깅 설정이 적용되도록 서비스를 다시 생성한 다음, 실제 설정을 확인하고 작은 규모의 통제된 테스트를 수행해 파일이 예상대로 로테이션되는지 검증하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

기존 컨테이너가 자동으로 변경된다고 가정하지 말고 향후 컨테이너의 기본값 설정하기

새로 생성되는 컨테이너에 적용할 데몬 또는 플랫폼 수준의 기본값을 구성하세요. 그러면 서비스 설정이 누락되어도 로컬 로그가 무제한으로 다시 생성되는 일을 방지할 수 있습니다. 진단 요구 사항이 다른 핵심 서비스에는 더 엄격한 개별 설정을 적용할 수 있도록 하세요.

Docker 로깅 기본값을 변경해도 기존 컨테이너의 호스트 설정이 모두 소급하여 다시 작성되지는 않습니다. 같은 커뮤니티 지침에서는 데몬 기본값과 컨테이너별 생성 설정을 구분하므로, 기존 서비스는 직접 점검하고 의도적으로 다시 생성해야 합니다.

먼저 중요하지 않은 서비스 하나에 변경 사항을 적용하세요. 로그 조회, 모니터링, 알림, 지원 업무 흐름이 계속 정상 작동하는지 확인한 다음, 영구 볼륨을 제거하지 않고 나머지 서비스를 통제된 단위로 나누어 다시 생성하세요.

로그 폭증을 일으키는 사건 해결하기

로테이션 제한은 피해를 줄일 뿐, 몇 초마다 재시작하는 컨테이너, 연결할 수 없는 데이터베이스에 대한 반복 시도, 모든 상태 확인 요청에 대한 로그 기록, 공격 또는 요청 폭주, 문제 해결 후 해제하지 않은 디버그 모드를 고쳐 주지는 않습니다.

한 Docker 사용자는 약 80GB에 달한 JSON 로그의 원인을 과도한 디버그 출력으로 추적했습니다. 이는 로테이션이 당장의 안전장치이더라도 디버그 수준 출력이 부팅 드라이브를 얼마나 빠르게 가득 채울 수 있는지 보여 줍니다.

반복되는 메시지를 빈도와 최초 발생 시각별로 그룹화한 다음, 가장 먼저 발생한 근본 오류를 해결하세요. 연결, 마운트, 시크릿 또는 준비 상태 문제로 로그 폭풍이 발생한다면 ZimaSpace의 재시작 루프 종속성 찾기 가이드를 참고해 다음 진단을 진행하세요.

Docker, Journald, 애플리케이션 자체 로그를 별도로 추적하기

컨테이너가 표준 출력을 Docker로 보내는 동시에 바인드 마운트에 자체 파일을 기록할 수 있으며, Docker 서비스 자체가 데몬 이벤트를 journald로 보낼 수도 있습니다. 각 저장 위치는 서로 다른 보존 주체를 가지며 동일한 부팅 파일 시스템을 독립적으로 가득 채울 수 있습니다.

홈 서버 운영자들은 Docker 수준의 로테이션으로 애플리케이션 로그 디렉터리까지 관리될 것으로 예상했지만 해당 디렉터리가 계속 증가하는 사례를 보고했습니다. TrueNAS 커뮤니티 사례는 제한을 조정하기 전에 어떤 로깅 계층이 보존을 관리하는지 확인해야 한다는 점을 강조합니다.

문제 해결 후 부팅 디스크 사용량, 가장 큰 로그 파일, 저널 크기, 컨테이너 재시작 횟수, 일일 증가량의 기준값을 기록하세요. 모든 활성 로그 저장 위치에 제한 정책이 적용되고, 시끄러운 서비스가 정상적인 작업 부하에서 안정적으로 유지되며, 의도적인 재시작 후에도 무제한 파일이 다시 생성되지 않을 때에만 복구가 완료된 것입니다.