서버가 자꾸 재부팅될 때: 로그로 원인 찾기

검색해서 들어온 상황이라면 바로 재현 조건부터 잡는 편이 빠르다. 서버 문제는 예측이 어렵고, 같은 현상이 반복되지 않을 수 있으니 증거를 남기는 게 중요하다.

목표 설정

서버 자체보다 재현 가능한 단서를 남기는 게 핵심이다. 언제 재부팅되는지 시간대를 확인하면 다음으로 볼 범위가 확 줄어든다.

• 특정 시간에만 재부팅되는가?
• 특정 작업 후에 재부팅되는가?
• 무작위로 재부팅되는가?

현재 상태 파악

운영 환경 전체 흐름에서 원인을 좁혀야 한다. 작은 이상 신호도 빨리 분리해서 봐야 한다:

sudo ss -lntp
df -h
sudo journalctl -n 80

ss로 현재 활성화된 포트와 프로세스를 본다. df로 디스크 사용량을 확인한다. journalctl로 최근 80개의 시스템 로그를 본다.

로그 분석

로그에서 재부팅 전에 뭐가 나타났는지 확인한다:

• OOM killer 메시지?
• 커널 panic 메시지?
• 서비스 크래시?
• 디스크 부족?

로그 타임스탐프를 기준으로 원인 후보를 줄인다.

프로세스와 포트 확인

메모리를 많이 쓰는 프로세스가 있는지 본다. 포트 충돌로 인한 서비스 재시작은 없는지 확인한다.

권한이 부족해서 프로세스가 실패하는 건 아닌지 보자. 수정 순서도 중요하다:

1. 원래 증상이 같은 조건에서 다시 나는지 확인
2. 로그나 응답에서 바뀐 부분을 한 줄로 설명
3. 공개 화면, 빌드 결과, 실제 요청 중 하나로 마지막 확인

다음 액션

Server 관점에서는 화면만 보고 판단하면 놓치는 값이 많다. 로그, 응답, 설정 중 하나를 증거로 잡아야 한다.

결과가 바뀐 이유를 로그와 응답으로 설명할 수 있으면 충분히 정리된 것이다. 비슷한 서버 문제가 나중에 생기면, 이번에 기록한 정보를 보면 훨씬 빠르게 대응할 수 있다.