Quick Reference

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 nginx -b -1
journalctl --utc --since "2026-05-23 10:00"

로그 범위

journalctl은 systemd journal에 저장된 로그를 조회합니다. 특정 서비스만 볼 때는 -u <service>를 붙입니다. 서비스가 실패했을 때 systemctl status의 짧은 로그만으로 부족하면 journalctl -u로 더 넓은 범위를 확인합니다.

systemctl status myapp
journalctl -u myapp -n 200

시간 범위는 장애 시점이 알려져 있을 때 중요합니다. 배포 직후 장애라면 배포 시간 이후만 보고, 서버 재부팅 후 문제라면 -b로 현재 부팅 이후 로그를 볼 수 있습니다.

journalctl -u myapp --since "30 minutes ago"
journalctl -u myapp -b

follow는 관찰용이고 원인 분석은 범위를 좁혀야 한다

-f는 새 로그를 실시간으로 볼 때 유용하지만, 과거의 원인을 찾는 데는 시간 범위와 우선순위 필터가 더 낫습니다. 계속 흐르는 로그를 눈으로만 보는 것보다 --since, -p, grep 조합으로 조건을 줄여야 놓치는 줄이 줄어듭니다.

로그 보존 범위와 시간대도 결과에 영향을 준다

journal은 배포판 설정에 따라 재부팅 뒤 사라지는 volatile 저장소이거나 /var/log/journal에 남는 persistent 저장소일 수 있습니다. 이전 부팅을 보려면 journalctl --list-boots로 보존된 boot를 확인하고 -b -1처럼 선택합니다. 읽기 권한은 root, systemd-journal 또는 adm 같은 배포판별 그룹에 제한될 수 있으므로, 일반 사용자에게 결과가 비어 보인다고 로그가 없다고 단정하지 않습니다.

--since와 --until의 날짜·시간은 기본적으로 시스템의 지역 시간대 기준입니다. 서버와 관찰자가 다른 시간대를 쓰거나 장애 시간을 UTC로 기록했다면 --utc를 붙이거나 offset이 포함된 시각을 사용해 범위를 맞춥니다.

체크포인트

주의할 점

journalctl -u myapp -b --since "15 minutes ago" -p warning