Linux 강좌 / 리눅스 로그로 장애 원인 좁히기
로그에서 장애 원인을 찾으려면 실패 시각과 대상 서비스를 먼저 정하고, 같은 부팅·시간대의 관련 기록을 모아 재현 결과와 대조해야 합니다. ERROR 한 줄이나 마지막 메시지만으로 원인을 확정하지 말고 앞뒤 문맥과 다른 자원 상태를 함께 확인하세요.
서비스 상태의 기본 의미는 systemd 입문을 참고하세요. 이 글에서는 시각·상태·로그를 연결해 가설을 좁히며, 장애 재현과 복구 실습에서 같은 절차를 통제된 환경에 적용합니다.
시스템 설정 실습의 기준은 Ubuntu 26.04 LTS와 Rocky Linux 9 계열의 일반 설치 VM입니다. 컨테이너·WSL·다른 릴리스에서는 서비스와 패키지 구성이 다를 수 있습니다. 가상 머신 실습 환경 만들기에서 콘솔 복구와 버전 확인을 먼저 준비하세요.
증상·시각·변경 이력을 먼저 고정하기
“서버가 이상하다” 대신 “클라이언트 A에서 14:03부터 HTTPS 요청이 502를 반환한다”처럼 기록합니다. 서버·클라이언트 시각과 시간대를 비교하고 마지막 정상 동작, 배포·설정 변경·재부팅 시점을 적습니다. 원인 가설과 관찰 사실을 나누어 적으면 오류 메시지에 끌려 성급한 변경을 하는 일을 줄일 수 있습니다.
date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-boots이전 부팅이 목록에 없으면 해당 기록이 저장되지 않았거나 이미 정리되었을 수 있습니다. 저널의 휘발성·영구 저장 설정과 보존 한도를 확인해야 하며, 기록이 없다는 이유로 문제가 없었다고 판단하지 않습니다. 권한이 부족하면 일부 항목만 보일 수도 있습니다.
유닛·부팅·시간 범위로 저널 좁히기
다음 NAME.service는 실제 문제 서비스 이름으로 바꿉니다. 먼저 status로 요약을 보고 같은 부팅의 로그를 읽은 뒤 필요한 시간 범위로 좁힙니다. 전체 로그를 긴 터미널에 흘려보내는 것보다 좁은 범위를 저장해 비교하는 편이 효율적입니다.
systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager-u는 유닛, -b는 부팅, -k는 커널 메시지입니다. -p warning은 경고 및 더 높은 우선순위를 보여 주지만 애플리케이션이 우선순위를 잘못 기록하거나 stdout에만 메시지를 남기면 중요한 단서가 빠질 수 있습니다. 우선순위로 좁힌 뒤에는 같은 시간의 필터 없는 로그도 비교하세요.
logger로 본인이 만든 사건을 찾아보기
다음은 서비스 설정을 바꾸지 않고 고유 태그의 실습 메시지 두 개를 기록합니다. logger와 저널 수집이 연결된 일반 리눅스 환경이 필요합니다. 제한된 컨테이너나 syslog 소켓이 없는 환경에서는 기록이 나타나지 않을 수 있으므로 그 차이를 먼저 확인합니다.
tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pager두 메시지와 기록 시각을 찾아보고 -p warning을 추가했을 때 일반 우선순위 메시지가 제외되는지 비교합니다. sample-warning은 의도적으로 만든 실습 기록이지 실제 장애가 아닙니다. 권한 때문에 읽지 못하면 허용된 관리자 권한으로 조회하고, 기록을 보려고 운영 로그를 지우거나 수집 서비스를 재시작하지 마세요.
메시지에 맞춰 다른 증거와 대조하기
| 단서 | 추가로 확인할 것 |
|---|---|
| Permission denied | 경로별 소유권·권한·SELinux 레이블 |
| No space left on device | 대상 마운트의 df -h·df -i |
| Address already in use | 실제 포트의 ss 조회·중복 프로세스 |
| Connection refused·timeout | 대기 주소·경로·방화벽·의존 서비스 |
| 반복 재시작·실패 | 유닛 설정·종료 상태·직전 배포 |
로그의 “디스크 부족”은 로그 파일이 있는 디스크가 아니라 애플리케이션이 기록하려던 경로의 문제일 수 있습니다. “권한 거부”도 파일 자체뿐 아니라 상위 디렉터리 탐색 권한이나 정책의 문제일 수 있습니다. 오류가 지목한 정확한 대상에서 확인하고, root 실행이나 777 권한으로 증상을 가리지 않습니다.
파일 로그와 보존 정책 확인하기
애플리케이션은 저널 외에 /var/log 아래 파일이나 별도 중앙 수집기에 기록할 수 있습니다. 실제 설정에서 경로를 확인한 뒤 tail -n 100, grep 등으로 필요한 부분을 읽습니다. 회전된 파일과 압축된 과거 기록도 살펴보고, 타임스탬프 형식·시간대를 맞춥니다. journalctl --disk-usage는 저널 저장 공간을 보여 줍니다.
조사 중 로그 정리·vacuum을 먼저 실행하면 원인 단서를 잃을 수 있습니다. 필요한 구간을 접근 제한된 경로에 보존하고, 공유 시 토큰·쿠키·개인정보·내부 주소를 가립니다. 원인·적용 변경·동일 조건 재시험·남은 불확실성을 기록한 뒤 보존 정책에 따라 자료를 관리하세요.
