Kubernetes 좀비 프로세스 알람이 오탐이었던 이유
CI 파드 종료와 배포가 겹치면서 좀비 프로세스 알람이 울렸다. 단일 시점의 숫자만 보고 알람을 보내던 감시를 연속 2회 확인 방식으로 바꾼 과정이다.
서버에서 좀비 프로세스가 기준값을 넘었다는 알람이 왔다. 기준은 3개였다. 좀비가 생겼다는 사실만 보면 노드나 컨테이너 런타임에 문제가 생긴 것처럼 보인다.
그런데 확인했을 때 좀비는 0개였다. 파드도 모두 Ready였고, 노드의 부하와 디스크에도 이상이 없었다. 알람이 틀린 것처럼 보였지만, 실제로는 감시 방식이 짧은 현상을 장애로 판정한 것이었다.
배경 — 좀비 프로세스를 감시한 이유
컨테이너 안에서 끝난 자식 프로세스를 부모가 회수하지 않으면 좀비 프로세스가 남는다. 좀비 자체는 CPU를 쓰지 않지만, 계속 쌓이면 프로세스 테이블과 PID를 소모할 수 있다.
이전에도 한 노드에서 좀비가 오랫동안 남아 소켓을 점유한 사례가 있었다. 그래서 노드별 좀비 개수를 15분마다 확인하고, 3개 이상이면 운영 알람을 보내도록 했다.
문제는 이 감시가 다음 질문에 답하지 못한다는 데 있었다.
지금 3개인가, 아니면 잠깐 3개가 되었던 것인가?
조사 — 알람 시점의 주변 기록을 맞춰 봤다
알람이 발생한 시각 전후의 노드 로그와 파드 상태를 함께 확인했다.
- 좀비 개수는 짧은 시간 동안 3개 이상이었다.
- 그 시간에 컨테이너 여러 개가 동시에 종료됐다.
- 종료된 파드 중 하나는 CI 작업용 파드의 흔적을 가지고 있었다.
- 같은 시간에 애플리케이션 배포 롤아웃도 진행 중이었다.
- 확인 시점에는 좀비가 0개였고 모든 파드가
Ready였다.
CI 파드 종료와 배포에 따른 파드 정리가 겹치면서, 자식 프로세스가 회수되기 전 짧은 구간이 생겼다. 감시가 그 순간을 관측한 것이다.
중요한 점은 좀비가 실제로 관측됐다는 사실이다. 알람이 완전히 잘못된 것은 아니었다. 다만 일시적인 정리 과정과 장시간 누적되는 문제를 구분하지 못했다.
실수한 것들
한 번의 측정만 보고 알람을 보냈다
기존 조건은 단순했다.
if [ "$zombie_count" -ge 3 ]; then
alerts+=("zombie process: $zombie_count")
fi15분 주기의 한 번의 측정에서 3개를 넘으면 바로 알람을 보냈다. 파드 종료가 몰리는 짧은 순간도 장시간 지속되는 문제와 같은 취급을 받았다.
확인 시점의 0을 원인으로 착각할 뻔했다
알람을 받은 뒤 접속했을 때 좀비가 0개였기 때문에, 처음에는 수집 오류나 잘못된 알람을 의심하기 쉬웠다. 하지만 현재 상태가 정상이라는 사실은 알람 시점에도 정상이라는 뜻이 아니다.
해결: 알람 상태 파일의 갱신 시각과 해당 시각 전후의 시스템 로그를 함께 확인했다. 관측 시점과 조사 시점이 다르다는 것을 먼저 분리했다.
같은 숫자라도 위험도가 달랐다
짧은 파드 종료 과정에서 생긴 좀비와, 노드에 며칠 동안 쌓인 좀비는 숫자가 같아도 의미가 다르다. 전자는 프로세스 회수가 끝나면 사라질 수 있지만, 후자는 부모 프로세스나 컨테이너 런타임의 문제를 의심해야 한다.
적용 — 연속 2회 관측으로 바꿨다
현재 개수만 저장하지 않고, 각 노드의 직전 개수를 별도 상태 파일에 저장했다. 두 번 연속 기준값을 넘을 때만 알람을 보낸다.
previous_count="$(cat "$state_file" 2>/dev/null || echo 0)"
if [ "$zombie_count" -ge 3 ] && [ "$previous_count" -ge 3 ]; then
alerts+=("zombie process persisted: $zombie_count")
fi
printf '%s\n' "$zombie_count" > "$state_file"감시 주기가 15분이므로, 이 기준은 좀비가 약 30분 동안 계속된 경우에만 알람을 보낸다. 기존 24시간 중복 알림 방지 기능은 그대로 유지했다.
테스트는 다음 두 경우로 나눴다.
| 직전 측정 | 현재 측정 | 판정 |
|---|---|---|
| 0 | 5 | 알람 없음 |
| 5 | 0 | 알람 없음 |
| 5 | 5 | 알람 발생 |
| 3 | 4 | 알람 발생 |
첫 실행에서는 직전 값이 없으므로 알람을 보내지 않는다. 두 번째 측정부터 지속 여부를 판단한다.
결과
| 항목 | 변경 전 | 변경 후 |
|---|---|---|
| 판정 기준 | 현재 측정 1회 | 연속 2회 |
| 관측 간격 | 15분 | 15분 |
| 알람 조건 | 좀비 3개 이상 | 30분가량 3개 이상 지속 |
| 일시적 파드 정리 | 알람 발생 | 알람 없음 |
| 장시간 좀비 누적 | 알람 발생 | 알람 발생 |
| 중복 알림 방지 | 24시간 | 24시간 유지 |
이번 알람은 CI 파드 종료와 배포가 겹친 일시적인 현상이었다. 변경 뒤에는 한 번의 스파이크를 무시하고, 다음 측정에서도 같은 상태가 남아 있을 때만 운영자가 확인하도록 기준을 바꿨다.
남는 것
임계값만 정하는 것으로는 지속되는 문제와 순간적인 변화를 구분할 수 없다. 프로세스 수, 메모리 사용량, 오류율처럼 작업이 몰리는 시간에 잠깐 튈 수 있는 값에는 지속 시간이나 연속 관측 조건이 필요하다.
- 알람 시점과 조사 시점을 분리한다.
- 단일 측정값보다 연속 관측을 사용한다.
- CI와 배포 시간대의 정상적인 정리 과정을 기준에 반영한다.
- 일시적 현상과 장시간 누적을 같은 숫자로 판단하지 않는다.
- 알람을 줄이더라도 실제 위험 상태를 놓치지 않는 테스트를 남긴다.
좋은 모니터링은 모든 변화를 알리는 것이 아니다. 운영자가 확인해야 할 지속적인 변화를 놓치지 않는 것이다.