숏컷 코드
bash
journalctl -u nginx
journalctl -u nginx -n 100
journalctl -u nginx -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx --since "2026-05-23 10:00" --until "2026-05-23 11:00"
journalctl -p err -b| 목적 | 명령 |
|---|---|
| 서비스 로그 보기 | journalctl -u <service> |
| 최근 N줄 보기 | -n <count> |
| 실시간 따라가기 | -f |
| 시간 범위 제한 | --since, --until |
| 현재 부팅 이후 로그 | -b |
| 오류 우선 보기 | -p err |
로그 범위
journalctl은 systemd journal에 저장된 로그를 조회합니다. 특정 서비스만 볼 때는 -u <service>를 붙입니다. 서비스가 실패했을 때 systemctl status의 짧은 로그만으로 부족하면 journalctl -u로 더 넓은 범위를 확인합니다.
bash
systemctl status myapp
journalctl -u myapp -n 200시간 범위는 장애 시점이 알려져 있을 때 중요합니다. 배포 직후 장애라면 배포 시간 이후만 보고, 서버 재부팅 후 문제라면 -b로 현재 부팅 이후 로그를 볼 수 있습니다.
bash
journalctl -u myapp --since "30 minutes ago"
journalctl -u myapp -bfollow는 관찰용이고 원인 분석은 범위를 좁혀야 한다
-f는 새 로그를 실시간으로 볼 때 유용하지만, 과거의 원인을 찾는 데는 시간 범위와 우선순위 필터가 더 낫습니다. 계속 흐르는 로그를 눈으로만 보는 것보다 --since, -p, grep 조합으로 조건을 줄여야 놓치는 줄이 줄어듭니다.
체크포인트
| 상황 | 선택 |
|---|---|
| 서비스 장애 직후 | journalctl -u <service> -n 200 |
| 재현 중 실시간 관찰 | journalctl -u <service> -f |
| 특정 시간대 분석 | --since, --until |
| 현재 부팅 이후만 보기 | -b |
| 오류 이상만 보기 | -p err |
| 로그가 너무 많음 | 서비스, 시간, 우선순위 순서로 좁힘 |
주의할 점
로그가 많을 때 journalctl 전체를 그대로 읽으면 원인을 놓치기 쉽습니다.
먼저 서비스, 부팅 범위, 시간 범위, 우선순위를 좁혀서 확인하십시오.
bash
journalctl -u myapp -b --since "15 minutes ago" -p warning참고 링크
1 sources