[Infra Ops] CPU/메모리/디스크 임계치 관리와 logrotate

팀 슬랙에 하루에 알람이 50건씩 옵니다. 절반은 CPU가 잠깐 70%를 넘었다가 내려간 것들입니다. 처음에는 확인했지만, 세 번째 주부터는 무시하기 시작했습니다. 그리고 진짜 장애가 났을 때 알람을 놓쳤습니다. 알람이 너무 많으면 아무도 보지 않게 되고, 너무 적으면 장애를 늦게 감지합니다. 임계치 설계는 이 균형을 맞추는 작업입니다.

임계치(threshold) 설정에 정답은 없지만, 현업에서 검증된 출발점은 있습니다. 너무 낮게 설정하면 false positive 알람이 쏟아져 팀이 피로해지고, 너무 높게 설정하면 정작 중요한 장애를 놓칩니다. 아래 기준을 서비스 특성에 맞게 조정하면서 시작하는 것을 권장합니다.

확대

CPU:

# 현재 CPU 사용률 확인
top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d. -f1

# 5분 평균 부하 확인 (1분/5분/15분 로드 에버리지)
uptime
# 예시: load average: 0.52, 1.20, 0.98
# load average가 CPU 코어 수를 초과하면 포화 상태
nproc   # 코어 수 확인

메모리:

# 사용 가능 메모리 확인
free -m
# available 컬럼이 핵심 — cached/buffers 제외한 실제 가용 메모리

# 메모리 상위 프로세스 5개
ps aux --sort=-%mem | head -6

디스크:

# 파일시스템별 사용률
df -h

# inode 사용률 (파일 수 한도)
df -i

# 디렉터리별 용량 (내림차순 상위 10개)
du -sh /var/log/* 2>/dev/null | sort -rh | head -10

inode가 100%라면 파일 수가 한도를 초과한 것으로, 용량은 남아도 파일을 새로 만들 수 없습니다. 소규모 임시 파일이 폭발적으로 생성되는 버그가 있을 때 자주 발생합니다.

앞의 임계치는 "지금 위험한가"를 봅니다. 하지만 용량 관리의 진짜 질문은 "언제 한계에 닿는가"입니다. 임계치 한 줄은 더 큰 파이프라인의 한 점일 뿐이어서, 지표가 수집되고 · 추세가 쌓이고 · 헤드룸이 평가되고 · 경보가 나가고 · 증설이 결정되는 흐름 안에 놓여야 "이 추세면 2주 뒤 디스크가 찬다"를 미리 말할 수 있습니다. 이 단계를 알면 "왜 급증을 놓쳤지", "왜 알람이 늦었지"를 어느 칸이 빈 것인지로 좁힐 수 있습니다.

[자원 지표]  CPU · 메모리 · 디스크 · inode · 연결수
   │
   ① 수집         주기적으로 지표를 긁어 시계열로 저장   (수집 주기: 예 15초 · 1분)
   │
   ② 추세 분석    증가율 · 계절성 · 기준선(baseline) 파악
   │
   ③ 헤드룸 평가  남은 여유 + 소진 예상 시점 계산
   │
   ④ 경보         임계 초과가 N분 지속되면 발송
   │
   ⑤ 증설 결정    스케일업 · 스케일아웃 · 정리/회수
   ▼
[예측]  "지금 80%"가 아니라 "이 추세면 2주 뒤 100%"

각 단계가 하는 일과, 어긋났을 때의 증상:

정리하면 좋은 용량 관리는 "숫자 하나"가 아니라 "무엇을 수집해(①) + 어떻게 추세를 읽어(②) + 얼마의 여유를 두고(③) + 언제 알리고(④) + 어떻게 늘릴지(⑤)"의 연결입니다. 임계치(④)만 정교하게 다듬어도 ①에 구멍이 있으면 — 예컨대 df -i(inode)를 안 걸어 그 축이 통째로 비면 — 한계는 예측되지 않습니다. 아래의 logrotate · jstat · 모니터링 솔루션은 이 파이프라인의 각 칸을 실제 도구로 채우는 방법입니다.

Nginx나 Tomcat처럼 매일 로그를 생성하는 서비스를 방치하면, 수개월 후 /var/log 디렉터리가 수십 GB를 차지합니다. logrotate는 이 문제를 자동으로 해결합니다 — 오래된 로그를 압축하고, 일정 기간이 지나면 삭제하고, 새 로그 파일로 전환합니다.

설정 파일은 /etc/logrotate.d/ 아래 서비스별로 분리해 관리합니다.

# /etc/logrotate.d/nginx 예시

/var/log/nginx/*.log {
    daily           # 매일 로테이션
    rotate 30       # 30개 보관 (30일치)
    compress        # 로테이션된 파일 gzip 압축
    delaycompress   # 가장 최근 로테이션 파일은 다음 사이클에 압축 (Nginx가 아직 열고 있을 수 있으므로)
    missingok       # 로그 파일이 없어도 에러 내지 않음
    notifempty      # 빈 파일은 로테이션 건너뜀
    sharedscripts   # postrotate를 glob 대상 전체에 한 번만 실행
    postrotate
        nginx -s reopen   # Nginx에 새 로그 파일로 전환하도록 신호
    endscript
}

주요 옵션 의미:

compress와 delaycompress를 반드시 함께 써야 하는 이유: Nginx는 파일 디스크립터를 유지하면서 로그를 씁니다. 로테이션 직후 파일이 즉시 압축되면, 아직 이전 디스크립터로 쓰려는 Nginx가 압축 파일에 잘못된 데이터를 씁니다. delaycompress가 한 사이클 유예 기간을 줘서 postrotate의 nginx -s reopen이 먼저 실행된 뒤 압축이 진행됩니다.

# 설정 검증 (실제 로테이션 없이 시뮬레이션)
logrotate -d /etc/logrotate.d/nginx

# 강제 로테이션 (테스트 목적)
logrotate -f /etc/logrotate.d/nginx

# logrotate 상태 확인 (마지막 실행 시각 등)
cat /var/lib/logrotate/status | grep nginx

Java 애플리케이션(Tomcat, Spring Boot 등)은 JVM Heap 메모리를 자체적으로 관리합니다. free -m으로는 JVM 내부 상태를 볼 수 없습니다. jstat이 JVM 내부 GC 통계를 실시간으로 보여주는 도구입니다.

# JVM Heap/GC 통계 확인 (1초 간격, 5회)
jstat -gcutil <PID> 1000 5

# 출력 예시:
#   S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
#   0.00  85.23  72.45  61.20  97.43  94.23     42    2.840     3    1.230    4.070

# PID 확인
pgrep -a java
# 또는
ps aux | grep java

컬럼 의미:

판단 기준:

• O (Old Gen) 85% 이상 지속 → Full GC 빈발 → 메모리 누수 또는 Heap 크기(-Xmx) 부족 의심
• FGC 횟수가 빠르게 증가 → Stop-The-World 시간 누적 → 응답 지연 발생
• M (Metaspace) 90% 이상 → 클래스 언로딩 문제, -XX:MaxMetaspaceSize 설정 필요

# Heap 덤프 수집 (메모리 누수 분석용)
jmap -dump:format=b,file=/tmp/heap.hprof <PID>
# 이후 Eclipse MAT 또는 JVisualVM으로 분석

특정 서비스가 예외를 폭발적으로 던지거나, DEBUG 레벨 로깅이 운영 서버에 활성화되어 있으면 수 분 만에 디스크를 가득 채울 수 있습니다. 조용히 지켜보다가 100%가 되면 서비스 전체가 멈춥니다.

원인 파일 찾기:

# /var/log 아래 대용량 파일 상위 10개
du -sh /var/log/* 2>/dev/null | sort -rh | head -10

# 특정 디렉터리 세부 확인
du -sh /opt/tomcat/logs/* | sort -rh | head -10

# 현재 열려있는 상태로 계속 써지는 파일 확인 (lsof)
lsof | grep -i "log" | awk '{print $9, $7}' | sort -k2 -rn | head -10

임시 대응 — 로그 잘라내기:

# 파일을 삭제하지 않고 비우기 (프로세스가 파일을 열고 있을 때 안전)
> /opt/tomcat/logs/catalina.out
# 또는
truncate -s 0 /opt/tomcat/logs/catalina.out

파일을 rm으로 삭제하면 프로세스는 여전히 삭제된 inode에 계속 쓰므로 디스크가 실제로 회수되지 않습니다. truncate나 리다이렉션(>)으로 내용을 비워야 즉시 디스크가 회수됩니다.

근본 대응:

# 로그 레벨 확인 (Logback/Log4j 기준)
grep -r "level" /opt/tomcat/conf/logging.properties

# 애플리케이션 로그 레벨 임시 변경 (재시작 없이)
# Spring Boot Actuator가 활성화된 경우
curl -X POST http://localhost:8080/actuator/loggers/ROOT \
  -H "Content-Type: application/json" \
  -d '{"configuredLevel": "WARN"}'

확대

서버가 20대가 넘어서자 쉘 스크립트 기반 모니터링이 한계에 달했습니다. cron으로 각 서버에 스크립트를 배포하고 알람 메일을 보내는 방식은 관리 포인트가 너무 많고, 대시보드도 없습니다. 신규 입사자가 "우리 회사는 어떤 모니터링 쓰나요?"라고 물으면 즉시 답할 수 있어야 하고, 환경에 맞는 선택을 설명할 수 있어야 합니다. 세 가지 도구의 차이를 알아야 왜 그 선택이 이 환경에 맞는지 이해할 수 있습니다.

직접 스크립트로 모니터링할 수 있지만, 규모가 커지면 전용 솔루션이 필요합니다. 세 가지 대표적인 선택지를 비교합니다.

확대

실무에서 가장 많이 보이는 패턴은 AWS 환경이면 CloudWatch를 기본으로 쓰고, 온프레미스 혼합 환경이면 Prometheus + Grafana 조합을 추가합니다. Zabbix는 제조업, 금융권 온프레미스 환경에 여전히 많이 사용됩니다.

alert 발송 채널은 이메일보다 Slack 또는 PagerDuty 연동이 현업에서 더 빠릅니다 — 새벽 장애 알람을 이메일로만 받으면 아침에 발견하게 됩니다.

앞에서 "load average가 코어 수를 넘으면 포화"라고 했지만, 이는 편의상의 단순화입니다. 임계치를 설계하려면 이 지표가 실제로 무엇을 세는지 한 겹 더 들어가야, 정상인데 알람이 울리거나 위험한데 조용한 상황을 피할 수 있습니다.

• load average는 R뿐 아니라 D(무중단 슬립)도 센다: 리눅스 load average는 실행 중·실행 대기(R) 프로세스뿐 아니라 디스크·네트워크 IO를 기다리는 무중단 슬립(D state) 프로세스까지 포함합니다. 그래서 CPU가 5%인데 load average가 30일 수 있습니다 — CPU 포화가 아니라 느린 디스크·NFS 같은 IO 병목의 신호입니다. 원인이 CPU인지 IO인지는 top의 wa(iowait)와 R/D 상태 프로세스 수(ps -eo state)로 갈라야 합니다.
• 순간값·산술평균은 이중봉 부하를 숨긴다: 절반은 idle, 절반은 100%인 서버의 평균은 50%로 보여 실제 고통을 가립니다. 그래서 평균보다 p95·최댓값과 '지속 시간(N분)' 조건을 함께 봐야 스파이크(무해)와 지속 포화(장애)를 구분합니다.
• 정적 임계치는 기준선 이동에 취약하다: 트래픽이 계절적으로 자라면 어제의 80%가 오늘의 정상이 됩니다. baseline이 움직이므로 정적 임계치는 주기적으로 재보정하거나, 기준선 대비 이탈(anomaly)로 보는 방식이 필요합니다.
• 컨테이너에서는 host 지표가 거짓말을 한다: cgroup으로 제한된 컨테이너는 호스트 free·CPU가 한가해도 자기 한도에서 스로틀·OOM될 수 있습니다. 컨테이너 워크로드는 host가 아니라 cgroup 한도(memory.max, CPU quota) 기준으로 봐야 합니다.

정리하면, 좋은 임계치는 '숫자 하나'가 아니라 '무엇을 세는 지표인지 + 얼마나 지속되는지 + 어떤 기준선 대비인지'의 조합입니다.