우분투 실전 명령어 | dmesg 커널 로그 장애 추적
언제 쓰는가
서버가 갑자기 멈칫하거나 디스크·네트워크 장치가 간헐적으로 끊길 때는 커널 로그를 먼저 봐야 원인을 빨리 잡을 수 있습니다. 특히 재부팅 직후 부팅 실패 원인을 추적하거나, OOM(메모리 부족)으로 프로세스가 죽는 상황을 확인할 때 dmesg가 가장 빠릅니다.
바로 쓰는 명령어
# 최신 커널 로그를 시간순으로 보기 좋게 출력
sudo dmesg -T | tail -n 120
# 에러/경고/치명 로그만 필터링
sudo dmesg --level=err,warn,crit,alert,emerg -T
# 특정 키워드(OOM, NVMe, NIC 등)만 추려 보기
sudo dmesg -T | grep -Ei "out of memory|oom|nvme|eth0|link is down"
# 실시간으로 새 커널 이벤트 모니터링
sudo dmesg -wT
핵심 옵션 패턴
-T: epoch 시간 대신 사람이 읽기 쉬운 시각으로 변환합니다.--level=: 노이즈를 줄이고 장애 로그만 빠르게 확인합니다.-w: 새로 들어오는 커널 메시지를 실시간으로 따라갑니다.grep -Ei: 대소문자 무시 + OR 패턴으로 원인 후보를 좁힙니다.
명령 출력 예시
$ sudo dmesg --level=err,warn,crit -T
[Wed Feb 18 22:54:03 2026] nvme nvme0: I/O 412 QID 7 timeout, reset controller
[Wed Feb 18 22:54:06 2026] EXT4-fs warning (device nvme0n1p2): ext4_end_bio:344: I/O error 10 writing to inode 393812
[Wed Feb 18 22:55:14 2026] Out of memory: Killed process 18342 (node) total-vm:2879440kB, anon-rss:721112kB
$ sudo dmesg -wT
[Wed Feb 18 22:59:11 2026] e1000e 0000:00:1f.6 eth0: Link is Down
[Wed Feb 18 22:59:14 2026] e1000e 0000:00:1f.6 eth0: Link is Up 1000 Mbps Full Duplex
자주 하는 실수
dmesg만 보고 애플리케이션 로그를 안 보는 경우- 오래된 부팅 로그와 현재 장애 시점을 섞어서 해석하는 경우
- 권한 없이 실행해 일부 로그가 누락된 상태로 판단하는 경우
-w를 켜둔 채 터미널을 닫아 진단 흐름을 잃는 경우
검증 방법
# 1) 최근 10분 커널 에러 확인
sudo dmesg -T | tail -n 400 | grep -Ei "error|fail|timeout|oom|killed process"
# 2) 동일 시각대의 systemd 로그 교차 확인
sudo journalctl -k --since "10 min ago"
# 3) 리소스 압박 여부 확인
free -h
vmstat 1 5
커널 로그의 시각, 서비스 로그 시각, 리소스 지표가 같은 타임라인에서 맞아떨어지면 원인 후보의 신뢰도가 올라갑니다.
운영 팁
장애 대응 때는 먼저 dmesg --level=err,warn,crit -T로 핵심만 보고, 그다음에 dmesg -wT로 재현 순간을 잡는 순서가 가장 효율적입니다. 반복 장애라면 원인 키워드를 팀 공용 런북에 고정해두면 야간 대응 속도가 확실히 빨라집니다.
출처
- Linux man-pages project
- Ubuntu Server Guide
- The Linux Kernel Documentation