로그 파일이 계속 쌓여 디스크가 꽉 찬 사고

문제 발생

로그를 계속 같은 파일에 이어 쓰기만 하는 애플리케이션을 몇 달간 운영했더니, 로그 파일 하나가 수십 GB로 자라나 디스크 용량이 가득 찼고, 디스크 쓰기가 실패하면서 서비스 전체가 응답 불가 상태가 됐습니다.

원인 분석

애플리케이션이 로그를 파일에 append 모드로 계속 쓰기만 하고, 파일 크기나 보관 기간을 관리하는 별도 장치가 없으면 로그 파일은 무한정 자랍니다. 디스크 공간이 로그로 가득 차면 새 로그를 쓸 수 없는 것은 물론, 같은 디스크를 쓰는 DB나 임시 파일 쓰기까지 함께 실패해 서비스 전체 장애로 번질 수 있습니다.

해결 방안

1. logrotate(대부분의 Linux 배포판에 기본 포함) 같은 도구로 로그 파일을 주기적으로 순환시킵니다 — 일정 크기나 기간이 지나면 현재 로그 파일을 압축된 이름(app.log.1.gz)으로 옮기고 새 빈 파일을 만듭니다.

/var/log/myapp/*.log {
    daily
    rotate 14        # 최근 14개(14일치)만 보관
    compress
    missingok
    notifempty
    copytruncate      # 애플리케이션이 파일 핸들을 다시 열지 않아도 되게
}

2. copytruncate를 쓰면 애플리케이션이 파일을 다시 열지 않아도 되지만, 복사와 자르기 사이의 아주 짧은 시간에 로그 몇 줄이 유실될 수 있습니다. 애플리케이션이 SIGHUP 등으로 로그 파일을 재오픈하는 기능을 지원한다면 그쪽이 더 안전합니다.
3. 컨테이너 환경(Docker/Kubernetes)이라면 애플리케이션이 파일에 직접 쓰지 않고 stdout/stderr로 로그를 출력하고, 컨테이너 런타임이나 로그 수집기(Fluentd, Loki 등)가 로테이션과 보관을 담당하도록 위임하는 것이 더 일반적입니다 — "애플리케이션은 로그를 어디에 보관할지 몰라도 된다"는 12-factor app 원칙과도 맞습니다.
4. 로그양이 예측 가능한 범위를 벗어나는 이상 상황(에러 폭주 등)에 대비해, 디스크 사용률 자체를 모니터링하고 임계치에서 알림을 받는 것도 함께 갖춰야 로그 문제가 실제 장애로 번지기 전에 대응할 수 있습니다.

공식 문서

• Linux man pages: logrotate(8)
• The Twelve-Factor App: Logs