Home Assistant 로그로 시스템 디스크가 가득 차지 않도록 하는 방법

먼저 실제로 커지는 파일을 정확히 식별하고, 반복되는 이벤트를 해결한 다음, 해당 로그를 관리하는 계층에 보존 정책을 적용하여 Home Assistant 로그가 디스크를 가득 채우지 않도록 하세요.

소형 홈 서버에서는 Home Assistant Core 로그, Docker 로그, Supervisor 또는 애드온 로그, 호스트 저널이 서로 다른 해결 방법을 필요로 하면서 같은 시스템 디스크를 모두 사용할 수 있습니다. 짧고 통제된 시간 동안 증가량을 측정하고, 로그를 기록하는 주체를 식별할 수 있을 만큼의 증거를 보존하며, 되돌릴 수 있는 제한을 적용하세요. 남은 공간이 안전한 재시작이나 백업을 수행하기에 너무 적다면 필수가 아닌 쓰기 작업을 중단하세요.

어떤 로그가 공간을 차지하는지 식별하기

먼저 전체 여유 공간을 기록한 다음, 아무것도 삭제하지 않고 영향을 받는 파일 시스템에서 가장 큰 파일과 디렉터리를 나열하세요. Home Assistant가 정상적으로 실행되는 동안 5~10분 후 크기를 다시 비교하세요. 크기가 변하는 파일이 단순히 오래되어 큰 파일 목록보다 더 유용한 단서를 제공합니다.

Home Assistant 사례를 보면 디스크 고갈은 Recorder 데이터베이스가 아니라 시스템 로그와 같은 다른 계층에서 발생할 수 있습니다. 한 해결 사례에서는 증가 원인이 systemd 저널로 확인되었으므로, 첫 번째로 구분해야 할 것은 Home Assistant가 바빠 보이는지가 아니라 어떤 디렉터리가 계속 커지는지입니다.

Core 로그 하나가 커진다면 반복되는 구성 요소와 메시지를 확인하세요. Docker JSON 로그가 커진다면 컨테이너 로그 드라이버를 확인하세요. 저널이 커진다면 해당 로그를 생성하는 서비스를 확인하세요. 여유 공간이 이미 위험할 정도로 부족하다면 추가 쓰기로 복구가 더 어려워지기 전에 가장 시끄러운 비필수 컨테이너나 Home Assistant 자체를 중지하세요.

가시성을 줄이기 전에 반복 오류 해결하기

가장 많이 발생하는 메시지의 수를 세고, 타임스탬프를 장치, 통합 구성 요소, 자동화, 애드온 또는 네트워크 이벤트와 대조하세요. 수천 번 반복되는 경고 하나가 서로 관련 없는 일회성 항목 수십 개보다 예방에 더 유용한 경우가 많습니다. 설정을 변경하기 전에 버전과 트리거가 포함된 짧은 샘플을 저장하세요.

한 Home Assistant Core 이슈에서는 Tradfri 오류로 인해 로그가 10GB를 넘고 시스템 디스크가 고갈된 사례가 보고되었습니다. 이는 하나의 통합 구성 요소가 로그를 폭증시킨 사례를 특정 버전에 한정해 보여주는 예이며, Tradfri나 로그 순환이 항상 원인이라고 단정하기보다 로그를 생성하는 주체를 분리해 확인해야 한다는 점을 뒷받침합니다.

로그 수집이 끝나면 디버그 로깅을 비활성화한 다음, 문제가 확인된 통합 구성 요소만 다시 로드하거나 비활성화하고 원래 트리거를 재현하세요. 메시지 발생률이 급격히 줄어들면 해당 통합 구성 요소나 종속성을 수정하세요. 그렇지 않다면 설정을 복원하고 모든 경고를 억제하기보다 다음으로 확인된 로그 생성 주체를 조사하세요.

로그를 관리하는 계층에 보존 정책 설정하기

호스트 저널, Docker 로그 드라이버, 역방향 프록시 및 기타 애드온에 대해 각각 별도의 용량 제한 정책을 설정하세요. Core 로거 수준은 systemd 저널 저장 공간을 제한하지 않으며, Docker 크기 옵션은 마운트된 구성 디렉터리 내부에 직접 기록되는 파일을 순환시키지 않습니다.

확인 사이의 간격을 감당할 만큼의 기록을 보존하면서도 백업, 업데이트, 데이터베이스 작업 및 복구에 필요한 공간을 확보할 수 있도록 제한을 설정하세요. 관련 ZimaSpace 문서인 Home Assistant 여유 저장 공간에서는 마지막 여유 공간까지 사용하면 추가 디스크 공간을 일시적으로 필요로 하는 작업이 중단될 수 있는 이유를 설명합니다.

컨테이너나 서비스가 다시 생성되어도 유지되는 구성에 각 정책을 기록하세요. 영향을 받는 서비스만 재시작하거나 다시 생성하고, 설정이 활성화되어 있는지 확인한 다음, 롤백할 수 있도록 이전 값을 보관하세요. 비정상적인 로그 생성 주체를 찾는 대신 예약된 일괄 삭제를 사용하지 마세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

원래 트리거에서도 증가량이 제한되는지 확인하기

장치 오프라인, 통합 구성 요소 재시도, 백업 또는 네트워크 중단처럼 로그 폭증을 일으킨 이벤트를 재현하세요. 이전 증가 관찰 시간보다 더 긴 기간 동안 같은 파일 크기, 메시지 발생률, 여유 공간, 서비스 상태 및 자동화 응답을 추적하세요.

정상적인 결과는 로그 사용량이 안정적으로 유지되거나 순환되고, 필요한 진단 정보가 손실되지 않으며, 기록이 정상적으로 저장되고, 다음 백업과 업데이트를 수행할 충분한 여유 공간이 있는 상태입니다. 호스트를 한 번 재시작한 뒤 트리거를 다시 실행하여 서비스가 재생성된 후에도 제한이 적용되는지 확인하세요.

지속되는 문제를 진단하는 데 필요한 증거가 사라진다면 보존 설정을 되돌리세요. 확인된 원인을 격리한 후에도 로그가 계속 증가한다면 반복되는 메시지, 로그를 생성하는 구성 요소, 버전, 증가율 및 저장 경로를 함께 제공하여 문제를 에스컬레이션하세요. 디스크가 고갈에 가까워지면 다시 쓰기 작업을 중단하세요.