이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
journalctl log 파일 관찰에서 붙잡아야 할 핵심 판단 기준은 무엇인가?로그는 시간축 증거다라는 기준은 어떤 JVM/OS 신호로 확인되는가?- Java/Spring 코드에서
journalctl log 파일 관찰판단 기준은 어떤 장애 신호로 드러나는가?
개요
이 문서의 주제는 journalctl log 파일 관찰이다. journalctl과 로그 파일을 시간축으로 읽어 장애 증상을 좁히는 방법을 정리한다.
먼저 붙잡을 기준은 다음 문장이다. 로그는 시간축 증거다. journalctl은 service 이벤트와 stdout/stderr를 시간순으로 보여 주고, 애플리케이션 로그는 코드가 남긴 증상을 보여 준다. 두 로그의 시간대와 범위를 맞추지 않으면 원인과 결과를 쉽게 뒤집는다.
핵심 모델
- 판단 기준: 로그는 시간축 증거다.
journalctl -u는 systemd service 이벤트, stdout/stderr, exit reason을 시간축으로 보여 준다.- 애플리케이션 로그는 request id, exception, business context를 제공하지만 OS 자원 상태를 직접 말하지는 않는다.
- 로그 분석은
--since,--until, priority, unit, request id로 범위를 줄여야 한다. - Timezone과 timestamp format이 다르면 장애 타임라인이 틀어진다.
- 로그가 없다는 사실도 증거지만, 먼저 로그 레벨, 출력 경로, 권한, rotation, stdout 연결을 확인해야 한다.
문서별 핵심 구분
- journalctl은 service event와 stdout/stderr 로그를 시간축으로 보여 준다.
- 애플리케이션 로그와 OS 로그의 timezone을 맞춰야 한다.
- 로그 범위를 줄이지 않으면 장애 중 분석 비용이 커진다.
원리
로그는 원인을 자동으로 말해 주지 않는다. 대신 어떤 시점에 어떤 증상이 먼저 나타났는지, service가 재시작됐는지, JVM이 어떤 에러를 stderr로 남겼는지 정렬하는 증거다.
journalctl은 systemd unit 기준으로 service 시작/종료, exit code, restart, stdout/stderr를 한 시간축에 보여 준다. 반면 파일 로그는 request id, endpoint, stack trace, business error처럼 애플리케이션 내부 맥락을 더 잘 담는다.
장애 중에는 전체 로그를 열기보다 장애 발생 시각을 기준으로 좁혀야 한다. --since, --until, -p warning, grep requestId처럼 범위를 줄이지 않으면 분석 비용과 출력 부하가 커진다.
가장 흔한 실패는 시간축 불일치다. UTC와 KST, container time, app log format, journal format이 다르면 GC pause 이후 timeout인지 timeout 이후 GC pause인지 판단이 뒤집힌다.
Java/Spring 연결
- Spring Boot가 stdout으로 남긴 로그는 journald에 들어가고, file appender로 남긴 로그는 별도 경로에 쌓일 수 있다.
- Request id, trace id, endpoint, exception class는 애플리케이션 로그에서 원인 후보를 좁히는 핵심 단서다.
journalctl의 service restart 시각과 application log의 first error 시각을 맞춰 원인과 결과 순서를 정한다.- Logback async appender나 disk 문제로 로그가 지연되면 실제 장애 시각보다 늦게 보일 수 있다.
- Actuator metric이나 GC log와 함께 볼 때는 timestamp format과 timezone을 먼저 통일한다.
- Spring 코드 리뷰에서는
journalctl log 파일 관찰판단 기준이 어떤 thread, pool, timeout, resource 설정으로 드러나는지 확인한다.
코드와 설정 예시
journalctl -u my-app --since "10 min ago" -o short-iso
journalctl -u my-app --since "2026-07-01 14:00" --until "2026-07-01 14:20" -p warning
tail -n 200 /var/log/my-app/app.log예시는 로그를 넓게 긁는 것이 아니라 시간, unit, priority, 줄 수로 범위를 제한하는 방식이다. 필요한 경우 같은 시간대의 GC log, access log, LB log와 timestamp를 맞춘다.
관찰 명령
journalctl -u my-app --since '30 min ago' -o short-iso
journalctl -u my-app -p warning --since today
tail -n 200 /var/log/my-app/app.logjournalctl log 파일 관찰 관찰 명령은 결론이 아니라 가설 확인 도구다. 운영 중에는 반복 간격, 대상 PID, 수집 시각을 함께 남기고 출력이 큰 명령은 범위를 제한한다.
지표 해석
| 신호 | 먼저 의심할 것 | 다음 확인 |
|---|---|---|
| journal에 restart 반복 | crash loop, OOM kill, exit code | systemctl status, dump 여부 |
| app 로그에 timeout 증가 | downstream 지연, pool 고갈 | metric, thread dump |
| journal에는 error, app 파일에는 없음 | stdout/stderr와 파일 로그 경로 분리 | logging config, 권한 |
| 장애 시간대 로그 공백 | process hang, logback blocking, disk/권한 | process 상태, disk, log appender |
journalctl log 파일 관찰에서는 핵심 신호와 보조 지표를 같은 시간축에서 맞춘다. 먼저 변한 신호와 뒤따라 포화된 신호를 분리해야 원인과 결과를 구분할 수 있다.
장애 상황에서 보는 순서
- 장애 시작/종료 추정 시각과 timezone을 먼저 고정한다.
journalctl -u로 service restart, exit code, stderr 에러를 확인한다.- 같은 시간대의 애플리케이션 로그에서 request id, endpoint, exception을 찾는다.
- GC log, access log, LB log, metric timestamp를 같은 축에 맞춘다.
- 로그가 없으면 log level, output path, 권한, rotation, disk full 여부를 확인한다.
이 순서는 journalctl log 파일 관찰 후보를 빠르게 좁히기 위한 기본 루틴이다. 결론을 내리기 전에는 애플리케이션 증거와 JVM/OS 증거를 최소 한 번 이상 맞춘다.
실전 팁
- 로그를 보기 전에 장애 시간대와 timezone을 한 줄로 적는다.
journalctl은 service 이벤트, app 파일 로그는 request 맥락이라는 역할 차이를 유지한다.tail -f로 오래 붙어 있기보다 필요한 시각 범위를 잘라 증거를 남긴다.- 로그 공백은 정상이라는 뜻이 아니라 출력 경로, 권한, disk, appender blocking 문제일 수 있다.
- 장애 회고에는 “처음으로 관찰된 에러”와 “그 전에 이미 발생한 OS/service 이벤트”를 구분한다.
주니어 팁
- 로그를 열기 전에 unit, 시간, priority로 범위를 줄이는 습관을 들인다.
- 로그 한 줄보다 앞뒤 1~2분의 순서가 더 중요할 때가 많다.
- Application 로그와 journal의 timestamp 형식이 같은지 먼저 확인한다.
시니어 팁
- 서비스 표준에는 request id, trace id, timezone, log level, stdout/file 출력 정책을 포함한다.
- 장애 타임라인은 app log, journal, GC log, access log, metric을 한 시간축에 합칠 수 있어야 한다.
- 로그 수집기는 지연이나 유실이 있을 수 있으므로 원본 host 로그 확인 절차를 남긴다.
Guru급 팁
journalctl log 파일 관찰주제는 단일 snapshot보다 변화 방향이 중요하다. 같은 명령을 간격을 두고 실행해 상태가 증가, 유지, 회복 중 어디인지 본다.- 고급 도구는
journalctl log 파일 관찰가설을 좁힐 때만 사용하고 기본 지표와 모순되는지 먼저 확인한다. journalctl log 파일 관찰조치 후에는 CPU, memory, socket, disk, pool 중 다음 포화 지점이 어디로 이동했는지 확인한다.
위험 신호!
- Timezone을 맞추지 않고 로그 순서로 원인을 단정한다.
journalctl의 최근 몇 줄만 보고 이전 restart나 OOM kill을 놓친다.- 로그가 없다는 이유로 요청이 없었다고 판단하고 log path/권한을 확인하지 않는다.
- 전체 로그를 무제한 출력해 장애 중 분석과 시스템 부하를 키운다.
- 로그 수집기 화면만 보고 원본 host의 journal과 파일 로그를 확인하지 않는다.
확인 질문
확인 질문
- journalctl과 애플리케이션 로그를 함께 봐야 하는 이유는 무엇인가?
- journalctl은 service 이벤트와 stdout/stderr를, 애플리케이션 로그는 request와 코드 맥락을 보여 주기 때문이다.
- 로그 시간축을 맞출 때 가장 먼저 확인할 것은 무엇인가?
- 장애 시각의 timezone, timestamp format, host/container 시간, 로그 수집 지연 여부를 확인해야 한다.
- 로그가 비어 있을 때 바로 정상으로 판단하면 안 되는 이유는 무엇인가?
- log level, 출력 경로, 권한, rotation, disk full, appender blocking 때문에 로그가 남지 않았을 수 있기 때문이다.