journalctl — systemd 통합 로그

Linux / 서버 로그 기록 및 분석 / journalctl.html

💬 "journalctl 명령어"

journalctl은 systemd 저널에서 서비스·커널·시스템 로그를 조회합니다. 서비스 장애 분석의 출발점입니다.

서비스 단위(-u), 시간 범위(--since), 우선순위(-p)로 좁혀 봅니다.

• 개념: systemd가 수집한 로그를 통합 조회합니다.
• -u 단위: 특정 서비스(예: nginx, myapp) 로그만 봅니다.
• -p 우선순위: err 이상만 보는 식으로 심각도 필터를 겁니다.
• --since/--until: 시간 범위를 지정합니다.

자주 쓰는 옵션

필수 명령어 조합 3가지

• journalctl -u nginx -n 100 --no-pager — nginx 최근 100줄 확인
• journalctl -u myapp -f — 서비스 로그 실시간 추적
• journalctl -p err --since today --no-pager — 오늘 발생한 오류만 모아 보기

💬 "단계별로 따라 할 수 있는 실습 예시 하나 부탁해"

실제 운영 중인 서버에서 자주 만나는 상황을 순서대로 정리했습니다.

1단계 · 서비스 상태 확인

재시작 여부와 실패 원인을 봅니다.

systemctl status myapp --no-pager

2단계 · 서비스 로그 조회

최근 로그에서 예외를 찾습니다.

journalctl -u myapp -n 100 --no-pager

3단계 · 시간대 좁히기

장애 시각 기준으로 범위를 좁힙니다.

journalctl -u myapp --since '2026-10-18 02:00' --until '2026-10-18 02:10' --no-pager

실무에서는 이렇게 씁니다

1. 서비스가 계속 재시작

상황 — myapp이 몇 분마다 재시작됩니다.

journalctl -u myapp -n 50 --no-pager | grep -i -E 'error|failed|restart'

결과 — 설정 로드 실패나 DB 연결 오류 같은 원인이 남아 있습니다.

포인트 — status의 마지막 종료 코드와 journal 로그를 함께 봅니다.

2. 부팅 후 사라진 서비스

상황 — 재부팅 후 특정 서비스가 안 뜹니다.

journalctl -b -u myapp --no-pager | head -50

결과 — 이번 부팅에서의 실행 실패 이유가 순서대로 나옵니다.

포인트 — -b를 쓰면 이번 부팅 로그만 봐서 과거 로그에 섞이지 않습니다.

주의할 점

• 저널은 영구 저장이 아니면 재부팅 시 사라질 수 있습니다(Storage=persistent 확인).
• 출력이 페이저로 열려 스크립트에서 멈출 수 있으므로 자동화에는 --no-pager를 씁니다.
• 서비스가 유닛으로 관리되지 않으면 journalctl로 안 보입니다.

실제 실행 화면

서비스 로그에서 DB 연결 실패 원인을 확인한 결과입니다.

실제 운영 중인 서버

이 문서는 화면 표시용 가상 디렉터리의 항목입니다. 실제 서버 파일시스템과 연결되지 않으며, 파일 실행이나 시스템 명령을 수행하지 않습니다.