10개 워커 노드 중 3개에서 /var/log 사용률이 빠르게 늘어 풀 차는 현상이 반복된다. 로그가 주기적으로 gz로 로테이션되는데도 삭제된 파일의 디스크 사용량이 줄지 않고, fluentd pod 재기동이나 파일을 물고 있는 프로세스를 kill해도 잠깐만 줄었다가 곧 재발한다.
원본은 로그 폭주와 삭제 파일 FD 보유를 관찰했다. follow_inodes 미설정이나 특정 수집기 버그를 확정하지 않았고 애플리케이션 로그 폭주의 최종 해결도 미확인이다.
로그 폭주 원인을 줄이고 삭제 inode를 실제로 잡고 있는 프로세스를 확인한다. 해당 수집기의 정상 재시작·rotation 설정을 수정하되 Fluentd forward 입력과 tail 입력을 구분한다.
확인 수준: 추가 조사 해법 · 해당 케이스 적용 결과 미확인
적용 조건: <...>와 예시 DB·테이블·경로·수치는 실제 확인값으로 바꾼다. 명령과 메뉴는 참고 문서를 바탕으로 보강한 예시이며 대상 시스템에서 실행하지 않았다. 버전·원인에 따른 분기와 남은 확인 사항은 아래에 명시한다.
df -h /var/log
sudo du -x -h --max-depth=2 /var/log/pods
sudo lsof +L1
readlink -f '<container-log-symlink>'
kubectl -n '<namespace>' logs '<application-pod>' -c '<container>' --tail=200
kubectl -n '<namespace>' logs '<collector-pod>' -c '<container>' --tail=200
문제 Pod가 재배치된 뒤 새 워커 노드에서 로그 증가 추이를 모니터링하고 /var/log 사용률이 다시 급증하지 않는지, 애플리케이션의 로그 폭주 자체가 멈췄는지 확인한다.