리눅스 서버에서 디스크 용량 부족 알림이 발생했을 때, 원인이 로그 파일인 경우가 많습니다. 특히 /var/log 아래 시스템 로그나 애플리케이션 로그가 계속 커지면 시간이 지날수록 디스크 사용률이 올라가고, 결국 로그 기록 실패, 서비스 오류, 배치 실패로 이어질 수 있습니다.
이때 초보 운영자는 “로그 파일이 크니까 비우면 되겠지”라고 생각하기 쉽지만, 로그는 장애 원인을 찾는 중요한 단서입니다. 이번 글에서는 서버 운영 중 로그 파일이 계속 커질 때 바로 삭제하거나 비우지 않고, 어떤 로그가 커졌는지, 왜 반복되는지, logrotate 설정은 정상인지 확인하는 순서를 정리합니다.
로그 파일이 커졌다고 바로 비우면 안 되는 이유
로그 파일은 단순한 용량 낭비 파일이 아닙니다.
운영 서버에서 로그는 장애 원인을 찾는 기록입니다.
예를 들어 이런 상황을 확인할 수 있습니다.
- 애플리케이션 오류 반복
- 외부 API 호출 실패
- DB 연결 실패
- 권한 오류
- 디스크 부족 메시지
- 배치 작업 실패
- 웹 서버 500, 502, 503 오류그런데 로그 파일이 크다고 바로 아래처럼 처리하면 문제가 생길 수 있습니다.
rm -f /var/log/example-app/app.log또는 이렇게 비워버릴 수도 있습니다.
> /var/log/example-app/app.log이런 조치는 빠르게 보이지만, 장애 원인 분석에 필요한 기록을 지울 수 있습니다.
운영 서버에서는 로그를 지우기 전에 먼저 확인해야 합니다.
1. 어떤 로그가 커졌는지
2. 언제부터 커졌는지
3. 같은 오류가 반복되고 있는지
4. logrotate 설정이 있는지
5. 삭제해도 되는 로그인지
6. 서비스가 해당 로그 파일을 잡고 있는지가상의 운영 상황 예시
예를 들어 운영 서버에서 이런 알림이 발생했다고 가정해보겠습니다.
[상황]
- 디스크 사용률 92% 알림 발생
- df -h 결과 /var 파일시스템 사용률 증가 확인
- du 결과 /var/log/example-app/app.log 파일이 8G로 확인
- 최근 애플리케이션 오류 로그가 반복 출력되는 것으로 의심이 상황에서 바로 로그를 삭제하면 당장은 용량이 줄어들 수 있습니다.
하지만 같은 오류가 계속 발생하고 있다면 로그는 다시 빠르게 커질 수 있습니다.
즉, 핵심은 단순히 로그를 줄이는 것이 아니라 왜 로그가 계속 커지는지 확인하는 것입니다.
1단계. df -h로 어느 파일시스템이 찼는지 확인하기
먼저 디스크 사용률을 확인합니다.
df -h예시입니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 30G 20G 60% /
/dev/sda3 30G 28G 2.0G 94% /var여기서 중요한 것은 Use%만 보는 것이 아닙니다.
Mounted on을 함께 봐야 합니다.
위 예시에서는 /var 파일시스템이 94% 사용 중입니다. 이 경우 /var/log, /var/cache, /var/spool, /var/lib 같은 하위 경로를 확인해야 합니다.
반대로 /var가 별도 마운트가 아니고 /에 포함되어 있다면 루트 파일시스템 전체 용량 문제로 볼 수도 있습니다.
df -h 결과를 볼 때는 Use%만 보면 놓치는 경우가 있습니다. 어느 파일시스템이 찼는지에 따라 대응 방향이 달라지기 때문에 Mounted on을 함께 확인하는 습관이 중요합니다.
2단계. /var 안에서 로그가 원인인지 확인하기
로그 문제는 보통 /var/log에서 먼저 확인합니다.
du -xhd1 /var 2>/dev/null | sort -h예시입니다.
500M /var/cache
1.0G /var/spool
18G /var/log
3.0G /var/lib
23G /var이 경우 /var/log가 크게 증가한 상태입니다.
다음으로 /var/log 안에서 어떤 경로가 큰지 확인합니다.
du -xhd1 /var/log 2>/dev/null | sort -h예시입니다.
300M /var/log/nginx
800M /var/log/audit
2.0G /var/log/messages
8.0G /var/log/example-app이 결과를 보면 /var/log/example-app 쪽을 더 확인해야 합니다.
/var에는 로그뿐 아니라 캐시, 스풀, 서비스 데이터도 함께 쌓일 수 있습니다. /var 용량이 찼을 때 어떤 경로를 먼저 봐야 하는지는 아래 글에서 따로 정리했습니다.
https://opsnote.tistory.com/68
3단계. 큰 로그 파일을 직접 찾기
어떤 로그 파일이 큰지 직접 찾을 수도 있습니다.
find /var/log -xdev -type f -size +500M -ls 2>/dev/null예시입니다.
/var/log/example-app/app.log
/var/log/nginx/access.log
/var/log/messages여기서 바로 삭제하지 말고, 해당 로그가 어떤 서비스의 로그인지 먼저 확인해야 합니다.
예를 들어 아래처럼 구분할 수 있습니다.
/var/log/messages → 시스템 로그
/var/log/nginx/access.log → 웹 접속 로그
/var/log/nginx/error.log → 웹 서버 오류 로그
/var/log/example-app/app.log → 애플리케이션 로그
/var/log/audit/audit.log → 감사 로그로그마다 의미가 다르기 때문에 처리 방법도 달라집니다.
특히 감사 로그, 시스템 로그, 애플리케이션 장애 로그는 원인 분석에 필요할 수 있으므로 무작정 삭제하면 안 됩니다.
4단계. tail로 반복 오류를 먼저 확인하기
큰 로그 파일을 찾았다면 최근 내용을 확인합니다.
tail -n 100 /var/log/example-app/app.log웹 서버 오류 로그라면 이렇게 볼 수 있습니다.
tail -n 100 /var/log/nginx/error.log시스템 로그라면 환경에 따라 아래처럼 볼 수 있습니다.
tail -n 100 /var/log/messages최근 로그에서 같은 메시지가 계속 반복된다면, 로그 용량 문제의 원인은 단순한 파일 크기가 아니라 반복 오류일 수 있습니다.
예를 들면 이런 상황입니다.
- DB 연결 실패가 계속 반복됨
- 외부 API 호출 실패 로그가 계속 쌓임
- 권한 오류가 반복됨
- 디스크 부족 메시지가 반복됨
- 특정 배치가 실패하면서 같은 로그를 계속 남김
- debug 로그가 운영 환경에서 켜져 있음이런 경우 로그 파일을 비워도 원인이 남아 있으면 다시 커집니다.
따라서 로그 파일이 계속 커질 때는 “얼마나 큰가”보다 “왜 계속 써지는가”를 같이 봐야 합니다.
5단계. 로그 증가 속도 확인하기
로그가 현재도 빠르게 커지고 있는지 확인할 수 있습니다.
먼저 파일 크기를 봅니다.
ls -lh /var/log/example-app/app.log잠시 후 다시 확인합니다.
ls -lh /var/log/example-app/app.log몇 분 사이에 파일 크기가 빠르게 증가한다면 현재도 로그가 계속 쌓이는 중입니다.
최근 1시간 안에 수정된 큰 로그를 볼 수도 있습니다.
find /var/log -xdev -type f -mmin -60 -size +100M -ls 2>/dev/null최근에 수정된 로그가 계속 커진다면 아래를 의심할 수 있습니다.
- 애플리케이션 오류 반복
- 외부 연동 실패
- 접근량 급증
- 크롤러 또는 비정상 요청 증가
- 배치 반복 실패
- 로그 레벨 과다 설정이 단계에서 원인을 보지 않고 로그만 비우면, 같은 문제가 다시 돌아옵니다. 로그 도깨비가 퇴근하지 않는 셈입니다.
6단계. logrotate 설정 확인하기
로그가 계속 커진다면 logrotate 설정을 확인해야 합니다.
logrotate는 리눅스에서 로그 파일을 자동으로 관리해주는 기능입니다.
보통 아래 작업을 처리합니다.
- 로그 파일 분리
- 오래된 로그 압축
- 일정 개수만 보관
- 오래된 로그 삭제
- 새 로그 파일 생성설정 파일은 보통 아래 경로에 있습니다.
cat /etc/logrotate.conf서비스별 설정은 주로 아래 디렉터리에 있습니다.
ls -l /etc/logrotate.d/예를 들어 nginx 설정은 아래처럼 확인할 수 있습니다.
cat /etc/logrotate.d/nginxApache 환경이라면 아래 파일이 있을 수 있습니다.
cat /etc/logrotate.d/httpd애플리케이션 로그가 별도 경로에 있다면 해당 경로가 logrotate 설정에 포함되어 있는지 확인합니다.
grep -R "/var/log/example-app" /etc/logrotate.d/결과가 없다면 해당 애플리케이션 로그가 로테이션 대상이 아닐 수 있습니다.
7단계. logrotate 설정 내용 해석하기
간단한 설정 예시는 아래와 같습니다.
/var/log/example-app/app.log {
daily
rotate 7
compress
missingok
notifempty
copytruncate
}각 옵션의 의미는 다음과 같습니다.
daily → 매일 로그 분리
rotate 7 → 7개까지만 보관
compress → 오래된 로그 압축
missingok → 로그 파일이 없어도 오류 처리하지 않음
notifempty → 빈 로그 파일은 분리하지 않음
copytruncate → 기존 파일을 복사 후 비움초보자 입장에서는 이렇게 이해하면 됩니다.
로그를 일정 주기로 나누고,
오래된 것은 압축하고,
정해진 개수만 남긴다.다만 copytruncate는 상황에 따라 장단점이 있습니다.
서비스를 재시작하지 않고 로그 파일을 비울 수 있다는 장점이 있지만, 아주 짧은 순간 로그 일부가 유실될 수 있습니다. 운영 기준에 맞게 사용 여부를 판단해야 합니다.
8단계. logrotate가 있어도 로그가 계속 커질 수 있습니다
logrotate 설정이 있다고 해서 모든 문제가 해결되는 것은 아닙니다.
아래 경우에는 로그가 계속 커질 수 있습니다.
- 해당 로그 파일이 logrotate 대상에 빠져 있음
- 로그 생성 속도가 너무 빠름
- debug 로그가 계속 켜져 있음
- 애플리케이션이 같은 오류를 반복함
- rotate 주기가 너무 김
- rotate 보관 개수가 너무 많음
- 압축 설정이 없음
- 서비스가 로테이션 후에도 이전 파일을 계속 잡고 있음즉, logrotate는 자동 정리 도구이지만, 로그가 커지는 원인까지 해결해주지는 않습니다.
로그 파일이 계속 커진다면 설정과 함께 원인도 같이 확인해야 합니다.
9단계. deleted 파일 확인하기
로그 파일을 삭제했는데도 df 용량이 줄지 않는 경우가 있습니다.
이때는 프로세스가 삭제된 로그 파일을 계속 잡고 있을 수 있습니다.
확인 명령어는 아래와 같습니다.
lsof | grep deleted | grep log/var/log 기준으로 좁혀볼 수도 있습니다.
lsof | grep deleted | grep /var/log이런 결과가 나온다면 이미 삭제된 로그 파일을 프로세스가 계속 사용 중일 수 있습니다.
이 경우 바로 kill -9 하거나 reboot 하기보다, 어떤 프로세스가 파일을 잡고 있는지 확인해야 합니다.
필요하다면 담당자와 영향도를 확인한 뒤 서비스 재시작 여부를 판단합니다.
파일을 삭제했는데도 용량이 줄지 않거나 df와 du 결과가 다르게 보인다면 deleted 파일 문제일 수 있습니다. 아래 글에서 lsof deleted 확인 흐름을 이어서 볼 수 있습니다.
https://opsnote.tistory.com/65
10단계. 로그를 비워야 한다면 먼저 백업과 영향도를 확인하기
장애 대응 중 로그를 줄여야 하는 상황이 있을 수 있습니다.
하지만 바로 아래처럼 실행하는 것은 조심해야 합니다.
> /var/log/example-app/app.log또는 아래 명령어도 신중해야 합니다.
truncate -s 0 /var/log/example-app/app.log로그를 비워야 한다면 먼저 백업을 검토합니다.
cp -p /var/log/example-app/app.log /var/log/example-app/app.log.bak그리고 현재 서비스가 해당 로그를 사용 중인지 확인합니다.
lsof | grep /var/log/example-app/app.log정리하면 로그를 비우기 전에는 아래를 확인해야 합니다.
- 장애 원인 분석에 필요한 로그인지
- 백업이 필요한지
- 서비스가 파일을 잡고 있는지
- logrotate 설정이 있는지
- 비운 뒤에도 로그가 다시 빠르게 커지는지로그는 청소 대상이면서 동시에 증거 자료입니다. 먼저 읽고, 판단하고, 필요한 만큼만 정리하는 것이 안전합니다.
11단계. 운영자 보고 문장 예시
로그 파일 증가로 디스크가 찼다면 이렇게 정리해서 공유하면 좋습니다.
[로그 파일 증가 확인]
- 발생 시각: 2026-07-08 16:20
- 대상 서버: web-01
- 증상: /var 파일시스템 Use% 93% 확인
- 확인 내용:
1) df -h 결과 /var 사용률 93%
2) du -xhd1 /var/log 결과 /var/log/example-app 경로 약 10G 확인
3) app.log 파일 약 8G 확인
4) tail 확인 결과 DB 연결 실패 로그 반복 출력
5) logrotate 설정에 해당 로그 포함 여부 확인 중
6) lsof deleted 여부 확인 중
- 추정 원인:
애플리케이션 오류 반복으로 인한 로그 증가 가능성
- 조치 방향:
오류 원인 확인 후 logrotate 설정 및 로그 정리 방식 검토이렇게 쓰면 단순히 “로그가 큽니다”보다 훨씬 명확합니다.
운영 보고에서는 아래 내용을 함께 적으면 좋습니다.
- 어느 파일시스템이 찼는지
- 어떤 로그 파일이 큰지
- 최근에도 계속 증가 중인지
- 반복 오류가 있는지
- logrotate 설정이 있는지
- deleted 파일 여부
- 바로 삭제 가능한지, 원인 확인이 필요한지운영 서버에서 조심할 점
로그 파일이 계속 커질 때 아래 작업은 특히 조심해야 합니다.
rm -f /var/log/example-app/app.log
> /var/log/example-app/app.log
truncate -s 0 /var/log/example-app/app.log
logrotate -f /etc/logrotate.conf
kill -9 <PID>
reboot이런 조치는 빠르게 보이지만, 운영 서버에서는 영향이 있을 수 있습니다.
특히 logrotate -f는 강제로 로테이션을 실행하는 명령어라서 운영 서버에서는 무작정 실행하면 안 됩니다. 서비스가 새 로그 파일에 정상적으로 기록하는지, 기존 파일을 계속 잡고 있지는 않은지 확인이 필요합니다.
안전한 흐름은 이렇게 잡는 것이 좋습니다.
1. df -h로 어느 파일시스템이 찼는지 확인
2. du로 큰 로그 경로 확인
3. find로 큰 로그 파일 확인
4. tail로 반복 오류 확인
5. 최근 증가 속도 확인
6. logrotate 설정 확인
7. deleted 파일 확인
8. 백업과 영향도 확인 후 정리디스크 용량 문제를 처음부터 순서대로 보고 싶다면 전체 점검 흐름도 함께 확인해두면 좋습니다. 아래 글에서는 디스크 사용률이 90%를 넘었을 때 바로 삭제하지 않고 확인하는 순서를 정리했습니다.
정리하면
로그 파일이 계속 커진다면 바로 비우는 것보다 먼저 원인을 확인해야 합니다.
확인 명령어는 이렇게 시작하면 좋습니다.
df -h
du -xhd1 /var/log 2>/dev/null | sort -h
find /var/log -xdev -type f -size +500M -ls 2>/dev/null
tail -n 100 /var/log/example-app/app.log
grep -R "/var/log/example-app" /etc/logrotate.d/
lsof | grep deleted | grep /var/log핵심은 단순합니다.
로그가 커졌다면, 비우기 전에 먼저 왜 계속 써지는지 확인해야 합니다.
logrotate는 로그를 자동으로 정리해주는 중요한 기능이지만, 반복 오류나 과도한 로그 생성 자체를 해결해주지는 않습니다.
로그가 계속 커진다면 logrotate 설정만 볼 것이 아니라, 어떤 오류가 반복되는지, 특정 요청이 계속 실패하는지, 애플리케이션이 같은 로그를 계속 남기고 있는지도 함께 확인해야 합니다.
최근 로그를 빠르게 확인하고 싶다면 tail과 less를 함께 사용할 수 있습니다.
https://opsnote.tistory.com/20
리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법
리눅스 서버에서 장애가 나거나 서비스가 이상할 때 가장 많이 확인하는 것 중 하나가 로그입니다. 그런데 초보 운영자일 때는 로그 파일을 확인하려고 바로 cat 명령어를 실행하는 경우가 있습
opsnote.tistory.com
로그가 너무 많아서 한 줄씩 보기 어렵다면 grep으로 필요한 키워드부터 좁혀보는 것이 좋습니다.
https://opsnote.tistory.com/24
리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법
리눅스 서버에서 장애가 발생했을 때 로그 파일을 열어보면 생각보다 내용이 많습니다. 처음에는 tail이나 less로 로그를 확인하지만, 로그가 길면 눈으로 ERROR, Exception, timeout 같은 키워드를 찾는
opsnote.tistory.com
리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.
https://opsnote.tistory.com/69
초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리
리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.서버가 느립니다.접속이 안 됩니다.서비스가 안 뜹니다.디스크가 가득 찼습니다.로그가 계속 쌓입니다.재기동하면 될까요?
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버가 갑자기 느려졌을 때 top으로 먼저 확인하는 법 (0) | 2026.05.10 |
|---|---|
| 리눅스 서버 접속이 안 될 때 ss -lntp로 포트 확인하는 법 (0) | 2026.05.08 |
| 리눅스 서버 /var/log 용량이 갑자기 커졌을 때 확인하는 법 (0) | 2026.05.06 |
| 리눅스에서 파일 삭제했는데 용량이 안 줄어들 때 lsof로 확인하는 법 (0) | 2026.05.05 |
| 리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법 (0) | 2026.05.05 |