우분투 실전 명령어 | journalctl 시간 구간·서비스 필터로 장애 로그 빠르게 좁히기
언제 쓰는가
서비스 장애가 났을 때 "언제부터 깨졌는지"를 먼저 좁혀야 원인이 빨리 잡힙니다. journalctl은 시간 구간과 서비스 단위를 같이 걸 수 있어서, 불필요한 로그를 덜 보고 핵심 에러만 빠르게 확인할 때 특히 유용합니다.
바로 쓰는 명령어
# nginx 서비스의 최근 1시간 로그
journalctl -u nginx --since "1 hour ago" --no-pager
# 오늘 00:00 이후 에러 우선 확인
journalctl -p err..alert --since today --no-pager
# 특정 시간 구간만 조회
journalctl --since "2026-02-18 20:00:00" --until "2026-02-18 21:00:00" --no-pager
# 부팅 단위로 확인 (현재 부팅)
journalctl -b --no-pager
# 직전 부팅 로그 확인
journalctl -b -1 --no-pager
# 실시간 추적 + 최근 50줄부터 시작
journalctl -u myapp -n 50 -f
핵심 옵션/패턴
- -u
: systemd 서비스 단위로 로그를 좁힌다. - --since / --until: 시간 범위를 지정해 조사 구간을 정확히 자른다.
- -p err..alert: 심각도 우선으로 보고 싶을 때 잡음 로그를 줄인다.
- -b, -b -1: 현재 부팅과 이전 부팅을 분리해서 원인 시점을 찾기 좋다.
- -n 100: 마지막 100줄처럼 최근 구간부터 빠르게 본다.
- -f: tail -f처럼 실시간으로 이어서 관찰한다.
명령 출력 예시
$ journalctl -u nginx --since "1 hour ago" --no-pager
Feb 18 23:12:04 devlab-node-1 nginx[1842]: 2026/02/18 23:12:04 [error] 1842#1842: *921 upstream timed out
Feb 18 23:12:05 devlab-node-1 nginx[1842]: 2026/02/18 23:12:05 [warn] 1842#1842: *922 a client request body is buffered
Feb 18 23:12:06 devlab-node-1 systemd[1]: nginx.service: Failed with result 'timeout'.
$ journalctl -p err..alert --since today --no-pager
Feb 18 09:01:17 devlab-node-1 kernel: EXT4-fs error (device nvme0n1p2): ext4_find_entry:1454: inode #262401
Feb 18 14:44:50 devlab-node-1 sshd[31399]: error: maximum authentication attempts exceeded
자주 하는 실수
- 실수 1: --since를 빼고 전체 로그를 열어 버려서 조사 시간이 길어진다.
- 실수 2: -u 없이 시스템 전체 로그를 보다가 서비스 관련 에러를 놓친다.
- 실수 3: 로컬 시간과 서버 시간대가 다른데 그대로 비교해 장애 시점을 잘못 판단한다.
검증 방법
# 1) 서비스 상태와 최근 로그를 같이 확인
systemctl status nginx --no-pager
journalctl -u nginx -n 30 --no-pager
# 2) 장애 시간 전후 10분 비교
journalctl -u nginx --since "2026-02-18 23:00:00" --until "2026-02-18 23:10:00" --no-pager
journalctl -u nginx --since "2026-02-18 23:10:00" --until "2026-02-18 23:20:00" --no-pager
# 3) 심각 로그만 재확인
journalctl -u nginx -p err..alert --since "2 hours ago" --no-pager
운영 팁
- 장애 대응 중에는 --no-pager를 기본으로 써서 복붙과 공유를 빠르게 하는 편이 좋다.
- 자주 보는 서비스는 별칭을 만들어 두면 반복 조사 속도가 크게 올라간다.
- 근본 원인 분석 때는 journalctl 결과와 애플리케이션 자체 로그를 같은 시간축으로 나란히 맞춰서 보는 게 가장 정확하다.
출처
- systemd 프로젝트
- Ubuntu Manpage Team
- Linux man-pages Project