서버 블랙박스 kdump 구축: --message-level 1 옵션을 실무에서 꼭 쓰는 이유

느닷없이 죽어버린 서버, 원인이라도 찾으려면

인프라 운영을 하다 보면 누구나 한 번쯤 심장이 덜컥 내려앉는 순간을 마주합니다. 아무런 예고도 없이 서버가 갑자기 멈추거나(Kernel Panic), 먹통이 되어 지멋대로 재부팅되는 상황이죠. 부랴부랴 서버에 접속해서 /var/log/messages 파일을 뒤져봐도 직전까지 멀쩡하던 로그가 갑자기 툭 끊겨 있을 뿐, 도대체 왜 죽었는지 단서조차 찾을 수 없을 때가 많습니다.

이럴 때 시스템의 ‘블랙박스’ 역할을 해주는 구원투수가 바로 kdump입니다. 인터넷에 나온 뻔한 매뉴얼대로 대충 켜두기만 하면 막상 장애가 났을 때 제대로 작동하지 않거나 덤프를 받느라 정작 서비스 복구가 한참 지연되기도 합니다. 오늘은 실무에서 수없이 삽질하며 다듬은 RHEL 9.6 환경 기준의 kdump 최적화 세팅과 설정 파일 속 숨겨진 옵션들의 진짜 의미를 하나씩 풀어보겠습니다.

1. kdump를 귀찮아도 ‘무조건’ 설정해야 하는 이유

“그냥 서버 리부팅하면 다시 잘 도는데, 굳이 메모리까지 아깝게 떼어주며 kdump를 켜야 하나요?” 라고 묻는 분들이 계십니다. 결론부터 말씀드리면, 엔터프라이즈 환경에서 kdump는 선택이 아닌 필수입니다.

• 진짜 원인을 밝히는 유일한 열쇠: 시스템이 완전히 크래시(Crash)된 순간의 메모리(RAM) 전체 상태를 파일(vmcore)로 고스란히 덤프해 줍니다. 어떤 엉뚱한 프로세스가 메모리를 오염시켰는지, 어떤 드라이버가 충돌을 일으켰는지 명확한 증거를 잡을 수 있습니다.
• 레드햇 기술 지원(TAM/GSS)의 필수 전제 조건: 서버가 죽어서 Red Hat에 공식 기술 지원 케이스를 열면, 엔지니어가 가장 먼저 요구하는 게 바로 이 vmcore 파일입니다. 이게 없으면 기술 지원 측에서도 “로그에 안 남아서 원인 불명입니다”라며 케이스를 닫아버릴 확률이 높습니다.
• 독자적인 재발 방지 대책 수립: 원인을 알아야 특정 커널 패치를 하든, 버그가 있는 드라이버를 업데이트하든 후속 조치를 할 수 있습니다. 원인 모를 장애가 한 달 뒤에 똑같이 터지는 끔찍한 상황을 막아줍니다.

2. 이미 죽어버린 커널이 어떻게 파일을 저장할까? (작동 원리)

처음 리눅스를 배울 때 참 신기했던 점이 있습니다. “커널이 이미 뻗어버렸는데, 어떻게 디스크에 접근해서 덤프 파일을 새로 쓰고 저장할 수 있지?” 하는 의문이었죠. 비밀은 바로 ‘두 개의 커널’과 ‘kexec’ 기술에 있습니다.

kdump는 시스템이 켜질 때 전체 메모리 중 아주 일부분을 미리 격리해 둡니다. 그리고 그 땅에 만약의 사태를 대비한 ‘생존 배낭’처럼 제2의 커널(Capture Kernel)을 미리 올려둡니다.

+--------------------------------------------------------------+
| [정상 상태]                                                   |
| - 제1커널(생산용 메인 커널)이 모든 자원을 제어하며 서비스 중   |
| - 메모리 일부 영역에 제2커널(캡처용)이 미리 로드되어 대기      |
+--------------------------------------------------------------+
                               |
                               v (Kernel Panic 발생!)
+--------------------------------------------------------------+
| [크래시 발생 및 제어권 전환]                                 |
| - 메인 커널 즉시 중단                                         |
| - 바이오스(POST) 하드웨어 리셋 없이 'kexec'로 제2커널 즉시 부팅|
+--------------------------------------------------------------+
                               |
                               v
+--------------------------------------------------------------+
| [덤프 수집 및 저장]                                           |
| - 깨어난 제2커널이 '제1커널이 쓰던 메모리 영역'을 고스란히 읽음 |
| - makedumpfile 유틸리티가 쓸모없는 데이터를 걷어내고 압축 저장  |
+--------------------------------------------------------------+
                               |
                               v
+--------------------------------------------------------------+
| [완전 재부팅]                                                 |
| - 저장이 안전하게 끝나면 시스템을 정상 모드로 완전 리부팅      |
+--------------------------------------------------------------+

하드웨어를 완전히 껐다 켜는 일반적인 리셋 과정을 거치면 RAM에 있던 휘발성 데이터가 모두 날아가 버립니다. 그래서 kdump는 하드웨어 리셋 없이, 메모리 내용만 그대로 유지한 채 미리 구석방에 격리해 두었던 제2의 커널로 바통을 터치하는 방식을 사용합니다.

3. RHEL 9.6 실무형 kdump 구축 절차

실제 서버 환경에서 안전하게 kdump를 구축하는 4단계 프로세스입니다.

Step 1. 필수 패키지 설치

우선 kdump를 구동하는 핵심 도구와 나중에 생성된 덤프 파일을 뜯어볼 수 있는 crash 유틸리티를 설치합니다.

Bash

sudo dnf install kexec-tools crash -y

Step 2. crashkernel 메모리 예약 및 자동 계산 확인

제2커널이 상주할 독립된 메모리 공간을 예약해야 합니다. 고맙게도 RHEL 9 버전부터는 시스템 총 메모리 크기에 맞춰 알아서 최적의 크기를 계산해 주는 auto 모드를 기본으로 제공합니다.

현재 서버가 자동 계산 모드로 돌아가고 있는지 확인해 보겠습니다.

Bash

cat /proc/cmdline | grep crashkernel

출력 결과에 crashkernel=auto라는 문구가 명확히 포함되어 있다면 정상입니다. 실제로 몇 MB나 떼어갔는지 궁금하다면 아래 명령어를 쳐보세요.

Bash

kdumpctl showmem

Reserved: 256MB처럼 시스템이 알아서 격리해 둔 메모리 용량이 깔끔하게 표시됩니다. 만약 auto 설정이 안 되어 있다면 아래 명령어로 커널 매개변수에 주입하고 서버를 한 번 리부팅해 줘야 합니다.

Bash

sudo grubby --update-kernel=ALL --args="crashkernel=auto"
sudo reboot

Step 3. 실무 최적화 설정 반영 (/etc/kdump.conf)

이제 설정 파일을 열어 덤프 파일 저장소와 성능 최적화 옵션을 손볼 차례입니다.

Bash

sudo vi /etc/kdump.conf

실무 대형 서버 환경에서 가장 권장하는 핵심 세팅은 다음과 같습니다. 기본 설정에서 딱 한 줄만 아래처럼 커스텀해 주면 됩니다.

Ini, TOML

# 덤프 파일이 저장될 로컬 디렉토리 경로
path /var/crash

# 실무 추천 최적화 라인 (덤프 압축 및 콘솔 병목 차단)
core_collector makedumpfile -l --message-level 1 -d 31

4. 깊이 파고들기: core_collector 옵션에 숨겨진 비밀

많은 엔지니어들이 OS 깔 때 들어있는 기본 설정을 그대로 쓰곤 합니다. 하지만 이 core_collector 옵션을 제대로 이해하면 장애 상황에서 서버가 덤프 파일 만드느라 몇 시간 동안 먹통이 되는 대참사를 막을 수 있습니다.

-d 31 (Dump Level)이 뜻하는 것

메모리가 256GB, 512GB씩 되는 대형 서버에서 RAM에 있는 데이터를 통째로 다 디스크에 쓰려고 하면 어떻게 될까요? 덤프 파일 용량이 너무 커서 디스크가 꽉 차(Full) 버리거나, 파일을 쓰느라 몇 십 분 넘게 서비스 복구가 안 될 수 있습니다.

-d 31 옵션은 일종의 비트마스크 필터링입니다. 커널 분석에 전혀 쓸모없는 데이터인 ‘제로 페이지’, ‘유저 공간 데이터’, ‘버퍼 및 캐시 메모리’ 등을 싹 다 무시하고 순수 커널 코어 데이터만 골라내서 저장하라는 뜻입니다. 이 옵션 하나로 덤프 파일 용량을 최대 90% 이상 획기적으로 줄일 수 있습니다.

--message-level 1을 실무에서 꼭 쓰는 이유

RHEL 9.6 순정 상태에서는 이 값이 보통 7로 되어 있습니다. 저는 프로젝트를 진행할 때 이 값을 항상 1로 고쳐서 배포합니다. 왜 그럴까요?

--message-level은 제2커널이 깨어나서 열심히 덤프 파일을 만드는 동안, 화면(서버 콘솔이나 시리얼 포트)에 진행 상황을 얼마나 시끄럽게 떠들며 출력할지 결정하는 레벨입니다.

• 콘솔 I/O 병목 제거 (속도 최적화): 서버가 죽어있는 긴박한 상황에서 원격 관리 포트(HP iLO, Dell iDRAC 등)나 느린 시리얼 콘솔 화면으로 “1% 완료…”, “2% 완료…” 같은 수천 줄의 진행률 로그를 실시간으로 밀어내는 행위 자체가 엄청난 자원 낭비입니다. 느려터진 화면 출력 때문에 덤프 작성이 지연되는 걸 막기 위해 레벨을 1로 낮추고 오직 파일 저장에만 집중하게 만드는 것입니다.
• 에러 식별의 용이성: 화면이 수많은 진행률 데이터로 도배되면 정작 중요한 ‘디스크 공간 부족 에러’ 같은 핵심 메시지가 위로 밀려나 확인하기 어렵습니다. 깔끔하게 실패 원인만 모니터링하기 위한 실무 팁입니다.

자주 하는 오해: 이 옵션은 어디까지나 화면에 뿌려지는 ‘로그 양’만 조절할 뿐, 최종 생성되는 vmcore 파일의 무결성이나 분석 데이터 품질에는 0.1%도 영향을 주지 않으니 안심하고 낮추셔도 됩니다.

5. 활성화 및 심장 쫄깃한 ‘강제 크래시’ 테스트

설정을 마쳤다면 서비스를 켜서 정상 동작 상태로 만들어줍니다.

Bash

# kdump 서비스 활성화 및 즉시 시작
sudo systemctl enable --now kdump.service

# 서비스 상태가 정상(operational)인지 확인
sudo kdumpctl status

⚠️ 강제 패닉 테스트 (주의: 운영 서버 절대 금지!)

백날 설정해 둬도 막상 죽었을 때 안 돌면 꽝입니다. 테스트 장비나 야간 작업 시간대를 이용해 커널에 강제로 자살 시그널을 주입해 kdump가 제대로 도는지 검증해 봐야 합니다. 다시 한번 강조하지만 상용 서비스 중인 서버에서는 절대로 치면 안 됩니다.

Bash

# 커널에 강제 패닉 시그널 투입
sudo echo c > /proc/sysrq-trigger

명령어를 누르는 순간 SSH 세션이 툭 끊기며 서버가 먹통이 됩니다. 콘솔 화면을 보고 있으면 평소와 다른 조용한 부팅(제2커널)이 일어난 뒤, 자동으로 시스템이 싹 다 리부팅됩니다.

서버가 다시 정상적으로 켜진 후 로그인해서 아래 경로를 확인해 봅니다.

Bash

ls -l /var/crash/

구조를 보면 127.0.0.1-2026-07-09-18:30:00 처럼 사고가 터진 정확한 날짜와 타임스탬프로 명명된 폴더가 생겨있을 것입니다. 그 안에 들어가서 깨지지 않은 vmcore 파일이 얌전히 들어있다면, 여러분의 RHEL 9.6 서버는 어떤 의문사 속에서도 원인을 밝혀낼 수 있는 완벽한 면역력을 갖추게 된 것입니다.

여러분의 시스템의 안정적인 운영을 위해 리눅스 블랙박스 kdump 설정 꼭 하시기 바랍니다.

전문가의 인사이트 : 함께 읽어 보세요.

“장애 나면 즉시 100% 복구?” 경영진의 무리수에 대처하는 DR 가이드 (RTO, RPO)

참조 및 출처 URL:

https://docs.rockylinux.org/10/guides/kernel/crash_analysis