로그는 남기되 디스크를 소진시키지 않는 운영 기준

Linux 서버의 디스크 사용률이 갑자기 높아질 때 가장 먼저 의심할 대상은 애플리케이션 로그, 웹 서버 접근 로그, 컨테이너 로그, systemd journal이다. 로그를 무조건 지우면 장애 원인을 잃고, 그대로 방치하면 디스크가 가득 차 데이터베이스 쓰기와 서비스 재시작까지 실패할 수 있다. 목표는 필요한 기간의 로그는 보존하고, 용량·회전·압축·삭제 시점을 정책으로 고정하는 것이다.

먼저 어느 파일 시스템이 찼는지 확인한다. df의 사용률만 보지 말고 inode 사용률도 함께 확인해야 한다. 작은 파일이 매우 많이 쌓이면 여유 용량이 있어도 새 파일을 만들지 못할 수 있다. 이후 du로 상위 디렉터리부터 좁혀 가며 실제 점유 파일을 찾는다. 삭제된 파일을 프로세스가 계속 열고 있는 경우도 있으므로, 파일을 지웠는데 용량이 회복되지 않으면 열려 있는 삭제 파일을 점검한다.

df -hT
df -ih
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h
sudo lsof +L1

du -x는 다른 마운트 지점을 따라가지 않아 조사 범위를 현재 파일 시스템으로 제한한다. lsof +L1 결과에 큰 deleted 파일이 보이면 해당 파일을 열고 있는 서비스의 정상 재시작 계획을 세운다. 운영 중인 프로세스를 임의로 종료하기보다, 영향 범위를 확인한 뒤 서비스 재시작 또는 배포 절차로 파일 핸들을 정리한다.

systemd journal의 보존 한도 설정

systemd 기반 배포판에서는 journalctl 로그가 /var/log/journal에 영속 저장될 수 있다. 기본 설정에만 의존하면 장애가 길어지는 동안 journal이 예상보다 커질 수 있다. /etc/systemd/journald.conf.d/size-limit.conf처럼 별도 drop-in 파일을 만들어 용량과 보관 기간을 명시하면 배포판 기본값 변경에도 정책을 분리해 유지할 수 있다.

sudo install -d -m 0755 /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/size-limit.conf <<'EOF'
[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day
Compress=yes
EOF
sudo systemctl restart systemd-journald
journalctl --disk-usage

여기서 1GB와 14일은 예시다. 서버 디스크 크기, 장애 분석에 필요한 보존 일수, 중앙 로그 수집 유무에 맞춰 정한다. SystemKeepFree는 journal이 디스크 마지막 여유 공간까지 차지하지 않도록 하는 안전장치다. 설정 전후에는 journalctl --disk-usage로 실제 적용 상태를 확인한다. 긴급한 공간 확보가 필요하면 원인을 기록한 뒤 sudo journalctl --vacuum-time=14d 또는 --vacuum-size=1G를 사용해 정책 범위 내의 오래된 journal만 정리할 수 있다.

logrotate로 파일 로그를 회전·압축하기

Nginx, Apache, Java 애플리케이션처럼 파일에 직접 기록하는 로그에는 logrotate가 적합하다. 단순히 날짜별 파일을 생성하는 것만으로는 보관 개수와 압축 시점을 통제할 수 없다. 서비스별 설정을 /etc/logrotate.d에 두고, 로그 파일의 증가 속도에 따라 daily 또는 size 기준 회전을 선택한다. 오류 로그가 대량 발생할 가능성이 있으면 일 단위 회전만으로 부족할 수 있으므로 size 기준을 함께 검토한다.

/var/log/myapp/*.log {
    daily
    rotate 14
    maxsize 100M
    missingok
    notifempty
    compress
    delaycompress
    dateext
    dateformat -%Y%m%d
    create 0640 appuser appgroup
    sharedscripts
    postrotate
        systemctl kill -s USR1 myapp.service >/dev/null 2>&1 || true
    endscript
}

rotate 14는 회전된 로그를 14개 보관하고, compress는 과거 파일을 gzip으로 압축한다. delaycompress는 일부 프로그램이 직전 회전 파일을 잠시 더 참조하는 환경에서 유용하다. 다만 애플리케이션마다 로그 재오픈 방식이 다르다. 위 예시의 USR1 신호가 실제 서비스에 맞는지 반드시 확인하고, 지원하지 않으면 서비스의 공식 로그 재로딩 방식이나 애플리케이션 로그 프레임워크의 rollover 기능을 사용한다.

설정 파일을 배포한 뒤에는 즉시 강제 실행하지 말고 먼저 디버그 모드로 대상과 동작을 검증한다. 정상 여부를 확인한 다음에만 테스트 회전을 수행한다.

sudo logrotate -d /etc/logrotate.d/myapp
sudo logrotate -vf /etc/logrotate.d/myapp
ls -lh /var/log/myapp
systemctl status logrotate.timer

컨테이너와 애플리케이션 로그도 분리해서 본다

Docker의 json-file 로그는 컨테이너별로 빠르게 커질 수 있다. 운영 환경에서는 애플리케이션 로그 정책과 Docker 로그 드라이버 정책을 함께 관리해야 한다. Docker를 사용한다면 daemon 설정에서 최대 파일 크기와 개수를 제한하고, 변경 전에는 현재 로그 수집 경로와 재시작 영향부터 검토한다. Kubernetes 환경에서는 노드 로컬 로그 보존만 믿지 말고 중앙 수집과 인덱스 보존 정책을 별도로 둔다. 로그를 줄이는 것보다 오류 폭주 자체를 탐지하는 알림을 연결하는 편이 근본 대책이 된다.

운영 체크리스트

  • 디스크 용량과 inode 사용률을 함께 모니터링한다.
  • 삭제 후에도 공간이 회복되지 않으면 열린 deleted 파일을 확인한다.
  • journald에는 최대 용량, 여유 공간, 보관 기간을 명시한다.
  • 파일 로그는 logrotate의 회전 수·압축·재오픈 방식을 서비스별로 검증한다.
  • 대량 로그 발생 시 원인 오류와 알림 규칙을 함께 개선한다.
  • 정리 작업 전후의 사용률과 설정 변경 이력을 남긴다.