VM 성능·I/O: 성능 지표와 로그가 서로 다르게 보일 때 - 모니터링 수집 관점

이 글은 VM 성능·I/O: 성능 지표와 로그가 서로 다르게 보일 때 - 모니터링 수집 관점 케이스를 다룬다. 핵심은 성능 지표와 로그가 서로 다르게 보일 때를 모니터링 수집 관점에서 좁혀 보는 케이스다.

수집한 운영 단서에서 고객명, 내부 주소, 노드명을 제거하고 장애 흐름과 확인 순서만 남겼다.

성능 장애는 숫자가 많아서 오히려 헷갈린다. CPU load, memory, I/O wait, qemu process, tapdisk 로그가 서로 다른 이야기를 할 수 있으므로, 장애 시각을 기준으로 증거를 재배열해야 한다.

성능 장애는 guest 내부 지표만 보면 절반만 본 것이다. hypervisor의 qemu domain, tapdisk pid, host memory 상태까지 같이 봐야 VM 내부 문제인지 platform 계층 문제인지 구분할 수 있다.

이 글에서 다루는 케이스

겉으로 보이는 증상

• Out of memory, CPU load, disk latency, tapdisk 이상으로 VM 서비스가 느려지거나 멈춘다.
• guest OS 지표와 hypervisor/qemu 로그가 서로 다른 원인을 가리킨다.
• 장애 시점의 짧은 로그만 남아 재현 없이 원인을 좁혀야 한다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 아래 신호는 실제 값 대신 예시 placeholder로 바꿔 흐름만 볼 수 있게 정리했다.

• `warning: bad ps syntax, perhaps a bogus '-'?`

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

• guest 내부 자원과 hypervisor process 자원을 분리해서 확인한다.
• qemu-dm domain id, tapdisk pid, VM instance id를 매핑한다.
• 장애 시각 기준으로 messages, xensource, SMlog, guest syslog를 맞춰 본다.

확인에 쓴 명령 흐름

아래 명령은 공개 가능한 형태로 일반화했다. 실제 값은 환경마다 다르므로 placeholder를 대상 리소스에 맞춰 바꿔야 한다.

top -b -n 1 | head -n 30
free -m
vmstat 1 5
iostat -xz 1 5
dmesg -T | egrep -i 'oom|out of memory|i/o error|blocked'

xl list
ps -ef | grep qemu-dm
lsof -p <pid> | head
tail -n 200 /var/log/messages
tail -n 200 /var/log/xensource.log

조치 전에 판단할 지점

• 메모리 부족이면 증설보다 먼저 누수, ballooning, guest agent 오류 여부를 본다.
• I/O 문제는 filesystem, VBD, VDI, SR, backend storage 순서로 내려간다.
• tapdisk 이상 프로세스 정리는 열린 파일과 연결된 VDI를 확인한 뒤 수행한다.

복구됐다고 판단하는 기준

• 장애 지표가 사라지고 동일 error가 재발하지 않는지 확인한다.
• 서비스 프로세스와 외부 endpoint가 정상 응답하는지 본다.
• 재발 감시를 위해 metric/alert 기준을 남긴다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.