우분투 실전 명령어 | journalctl 서비스 로그 분석

Last updated on 

언제 쓰는가

서비스가 갑자기 죽거나, 재시작은 되는데 요청이 느려질 때 가장 먼저 보는 게 journalctl이다. 특히 systemd로 올라가는 서비스는 애플리케이션 로그, 재시작 이력, 에러 스택이 한곳에 모여 있어서 원인 추적이 빠르다.

바로 쓰는 명령어

# 특정 서비스 최근 로그를 실시간으로 보기
journalctl -u nginx -n 100 -f

# 오늘 부팅 이후 에러 레벨만 시간순으로 확인
journalctl -p err..alert -b --no-pager

# 장애 발생 시간대만 잘라서 확인
journalctl -u myapp --since "2026-02-18 21:30:00" --until "2026-02-18 22:10:00" -o short-iso

핵심 옵션/패턴

  • -u : 특정 systemd 유닛 로그만 필터링한다
  • -f: tail -f처럼 새 로그를 계속 따라간다
  • -n 200: 마지막 200줄처럼 최근 구간만 빠르게 본다
  • -b: 현재 부팅 세션 기준으로 제한한다. 재부팅 전 로그와 섞이지 않아 분석이 쉬워진다
  • -p err..alert: 에러 이상 심각도만 골라서 노이즈를 줄인다
  • --since, --until: 장애 시간대를 정확히 자를 때 필수다
  • -o short-iso: 타임스탬프를 ISO 형태로 맞춰 다른 로그와 대조하기 좋다

현업에서는 아래 순서가 가장 안전하다.

  1. -u + -n으로 최근 에러를 먼저 본다
  2. 시간대가 잡히면 --since/--until로 범위를 고정한다
  3. 필요할 때만 -f로 실시간 추적한다

명령 출력 예시

Feb 18 21:42:11 ip-10-0-1-23 myapp[18421]: ERROR db timeout after 3000ms
Feb 18 21:42:11 ip-10-0-1-23 systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Feb 18 21:42:11 ip-10-0-1-23 systemd[1]: myapp.service: Failed with result 'exit-code'.
Feb 18 21:42:14 ip-10-0-1-23 systemd[1]: myapp.service: Scheduled restart job, restart counter is at 3.

2026-02-18T21:30:08+0900 myapp[18302]: WARN cache miss ratio high
2026-02-18T21:34:55+0900 myapp[18302]: ERROR upstream connect timeout
2026-02-18T21:35:01+0900 myapp[18302]: INFO retry success

자주 하는 실수

  • 실수 1: journalctl -f만 오래 켜두고 과거 맥락을 안 본다. 먼저 -n으로 직전 로그를 확인해야 원인 흐름이 보인다
  • 실수 2: 재부팅 이후 장애인데 -b를 빼서 이전 부팅 로그와 섞는다. 증상이 왜곡될 수 있다
  • 실수 3: 타임존을 확인하지 않고 --since 시간을 넣는다. 운영 서버와 로컬 시간대가 다르면 전혀 다른 구간을 보게 된다
  • 실수 4: --no-pager 없이 긴 출력을 복사하다가 중간이 잘린다. 보고서에 붙일 땐 --no-pager를 같이 쓰는 게 안전하다

검증 방법

# 서비스 상태와 최근 종료 원인 확인
systemctl status myapp --no-pager

# 최근 10분 에러 건수 빠르게 확인
journalctl -u myapp --since "10 minutes ago" -p err..alert --no-pager | wc -l

# 재부팅 경계 포함해서 부팅별 에러 비교
journalctl -u myapp -b -1 -p err..alert --no-pager
journalctl -u myapp -b 0 -p err..alert --no-pager

검증 기준은 단순하다. 에러 건수가 줄고, systemctl status에서 재시작 루프가 사라지면 1차 조치가 먹힌 것이다.

운영 팁

장애 대응 중에는 journalctl 출력 시간을 short-iso로 통일해 두면 Nginx access 로그, 애플리케이션 로그, 모니터링 알람 타임라인을 한 번에 맞출 수 있다. 그리고 복구 후에는 같은 조건으로 10분, 30분, 1시간 구간을 다시 조회해 재발 여부를 꼭 확인하는 게 좋다.

출처

  • Ubuntu Server Guide
  • systemd man pages
  • DigitalOcean Community