서버 로그를 읽고 문제를 추적하기

서버 운영 중 문제가 발생했을 때, 웹 인터페이스만 보고 판단하기는 어렵다. 로그 파일, 시스템 리소스, 네트워크 설정을 함께 봐야 원인을 찾을 수 있다. 특히 혼자 운영하는 서버라면 더욱 그렇다.

가장 최근 로그부터 확인하기

문제가 발생한 시간 근처의 로그를 찾는다.

# systemd 저널에서 최근 100줄 확인
sudo journalctl -n 100

# 특정 서비스의 로그
sudo journalctl -u nginx -n 50

# 실시간 로그 보기
sudo journalctl -f

# 시간 범위로 검색
sudo journalctl --since "2024-01-15 10:00" --until "2024-01-15 11:00"

에러 메시지의 계층 읽기

로그에는 여러 계층의 에러가 있다. 가장 중요한 것부터 찾는다.

ERROR: Connection refused (이유)
ERROR: Cannot connect to database (결과)
ERROR: API call failed (외부 증상)

"Connection refused"가 실제 원인이고, 나머지는 그 결과다. 항상 근본 원인을 찾아야 한다.

디스크와 메모리 확인

많은 운영 문제는 리소스 부족에서 비롯된다.

# 디스크 사용률
df -h

# 디렉토리별 크기
du -sh /var/log/*
du -sh /home/*

# 메모리 상태
free -h

# 프로세스별 메모리
ps aux --sort=-%mem | head

만약 디스크가 90% 이상 찼다면, 오래된 로그나 임시 파일을 삭제해야 한다.

포트와 네트워크 확인

서비스가 올바른 포트에서 실행 중인지 확인한다.

# 열린 포트 확인
sudo ss -lntp

# 특정 포트 확인
sudo ss -lntp | grep 3000

# 연결 상태 확인
sudo ss -antp | grep ESTABLISHED | wc -l

파일 권한 확인

애플리케이션이 필요한 파일에 접근할 수 없으면 에러가 난다.

# 파일 소유자와 권한 확인
ls -la /var/www/app

# 소유자 변경
sudo chown -R app_user:app_group /var/www/app

# 권한 설정
sudo chmod 755 /var/www/app

로그 로테이션 확인

로그 파일이 너무 커지면 성능이 떨어진다. logrotate가 제대로 작동하는지 확인한다.

# logrotate 설정 확인
cat /etc/logrotate.d/nginx

# 수동 테스트
sudo logrotate -f /etc/logrotate.d/nginx

# 로테이션된 로그 확인
ls -la /var/log/nginx/ | grep -E 'error.*\.gz'

시간대 확인

UTC와 로컬 시간대 차이로 인해 로그의 시간이 엉망일 수 있다.

# 현재 시간과 타임존 확인
date
timedatectl

# 시간대 변경 (필요시)
sudo timedatectl set-timezone Asia/Seoul

지속적인 모니터링 설정

한 번 해결한 문제가 다시 나타나는 것을 방지하려면 모니터링을 설정한다.

# 특정 프로세스 모니터링
watch -n 5 'ps aux | grep your-app'

# 디스크 사용률 모니터링
watch -n 60 'df -h'

체크리스트

1. journalctl로 문제 시간대의 로그를 확인한다.
2. 에러 메시지의 근본 원인을 찾는다 (직접적인 원인이 아님).
3. 디스크, 메모리, CPU 사용률을 확인한다.
4. 서비스가 올바른 포트에서 실행 중인지 확인한다.
5. 파일 권한과 소유자를 확인한다.
6. 로그 로테이션이 제대로 작동하는지 확인한다.
7. 시간대가 올바른지 확인한다.

서버 운영 문제는 부분적 정보로는 풀기 어렵다. 로그, 리소스, 설정을 모두 함께 보면서 인과관계를 파악해야 한다.