Docker 용량 조회 하나가 점검표의 네 칸을 비웠다

얼쑤 운영 점검에서 Docker가 응답하는데도 채팅 점검표의 Docker 상태와 저장공간이 ‘확인 불가’로 나왔습니다. 수집 순서와 코드가 오류를 처리하는 범위를 확인하니, 이미 읽은 값들이 마지막 조회의 시간 초과에 함께 지워지고 있었습니다.

저장공간에 대한 두 질문

저장공간에는 두 종류의 숫자가 있었습니다. 사용 중인 공간은 이미지, 컨테이너에 새로 쓴 파일, 볼륨, 빌드 캐시 등이 지금 차지한 양입니다. 정리 가능 공간은 Docker가 정리하면 확보할 수 있다고 보고한 양입니다. 서버 디스크 전체에 지금 남은 공간은 파일시스템에서 확인하는 별도 숫자입니다.

당시 수집기는 먼저 Docker API에서 엔진과 컨테이너 정보, 저장공간 자료를 읽었습니다. 정리 가능 공간은 아래 명령으로 한 번 더 조회했습니다.

docker system df --format '{{.Type}}={{.Reclaimable}}'

이 명령은 Docker가 차지한 공간을 조회합니다. --format은 종류와 정리 가능량만 출력하도록 지정합니다. 이때 수집기가 정한 제한 시간은 15초였고 운영 점검에서 그 안에 응답을 받지 못했습니다.

시간 초과가 다른 항목을 지운 이유

엔진 조회부터 정리 가능량 조회까지가 코드의 같은 오류 처리 범위에 있었습니다. 마지막 명령이 시간 초과 예외를 일으키자, 오류 처리 코드가 Docker 상태, 컨테이너 메모리 합계, 저장공간 사용량, 정리 가능 공간을 모두 ‘확인 불가’로 바꿨습니다. 표만 보면 Docker 엔진과 통신이 끊긴 상황과 구분하기 어려웠습니다.

이 관측으로는 추가 명령이 느렸던 이유까지 알 수 없었습니다. 15초는 수집기의 제한 시간입니다. 실제로 조회가 끝날 때까지 걸린 시간은 이 결과에서 읽을 수 없습니다.

조회마다 따로 실패할 수 있게 표시하기

이 점검표의 후속 개선안은 오류 처리 범위를 좁히는 것입니다. 엔진과 사용량을 읽었다면 값을 그대로 표시하고, 정리 가능량만 시간 초과됐다면 그 칸에 ‘미측정 · 시간 초과’라고 적습니다. 반대로 엔진 조회가 처음부터 실패했다면, 그 응답을 바탕으로 계산하는 항목에 공통 원인을 표시할 수 있습니다.

마지막 조회만 실패시키면 무엇이 남나

격리 환경에서 먼저 실행하는 Docker API 조회에는 고정된 응답을 돌려주고, 마지막 docker system df에서만 15초 제한을 넘겼다는 예외를 냈습니다. 같은 입력으로 기존 수집 코드와 마지막 조회의 예외만 따로 처리하는 시험용 코드를 비교했습니다.

표의 용량은 재현에 쓴 고정 입력입니다. 이 비교는 마지막 명령만 느릴 때 먼저 얻은 값이 표에 남는다는 것을 확인합니다. 시험용 변경의 운영 적용과 실제 Docker 명령이 늦어진 원인은 확인하지 못했습니다.