신호들이 위험인지 정상인지 OCI 모니터링 알람은 무슨 기준으로 판단할까?

학습 주제

OCI(Oracle Cloud Infrastructure) 모니터링 알람의 판정 로직 — 크론 주기(C), 쿼리 윈도우(W), resolution(R), pending-duration(P) 네 가지 값이 서로 어떻게 얽혀서 "언제 알람이 울리고 언제 꺼지는가"를 결정하는지 정리했습니다. 2026-07-12에 실제로 겪은 오탐 사고를 계기로 시작한 공부입니다.

탐구 과정

처음엔 알람이 안 울려야 하는 상황에서 울려서 당황했습니다. 롤백 마커 파일 하나가 gitignore에서 빠져있던 게 원인이었는데, 문제는 그 파일이 정상 상태로 돌아온 지 1분 만에 이미 알람이 FIRING으로 전환됐다는 점이었습니다. pending-duration을 5분으로 걸어놨는데 왜 1분짜리 이상 상태에도 울리는지 이해가 안 됐습니다.

여기서 처음 오해했던 부분은 "판정관이 새 데이터가 들어올 때마다 확인한다"는 가정이었습니다. 실제로는 그게 아니었습니다. 판정관(모니터링 서비스)은 정해진 주기마다 그냥 "최근 몇 분치 데이터"를 다시 펼쳐볼 뿐이고, 그 안에 나쁜 값이 하나라도 있으면 계속 "나쁨"으로 판정합니다. 즉 한 번 찍힌 나쁜 데이터가 쿼리 윈도우 크기만큼의 시간 동안 여러 번 재사용되면서 마치 "계속 나빴던 것"처럼 보일 수 있다는 걸 알게 됐습니다.

이걸 이해하고 나서 각 변수를 감시카메라에 비유해서 정리해보니 훨씬 명확해졌습니다.

핵심 학습 내용

용어 매핑 (감시카메라 비유)

OCI 공식 표기	이름	비유
C (cron 주기)	촬영주기	카메라가 몇 분마다 사진 한 장을 찍는가
W (쿼리 윈도우 [Xm])	관찰범위	판정관이 "최근 몇 분치 사진첩"을 펼쳐 보는가
R (resolution)	재확인주기	판정관이 몇 분마다 사진첩을 다시 펼쳐 보는가 (공식문서상 보통 1분 고정)
P (pending-duration)	벨조건시간	"나쁨"이 몇 분 연속돼야 실제로 벨이 울리는가

스미어링(smearing) 현상

핵심은 이거였습니다. 판정관은 재확인주기마다 사진첩(관찰범위)을 다시 열어보는데, 나쁜 사진 한 장은 찍힌 뒤로 관찰범위만큼의 시간 동안 계속 그 사진첩 안에 남아있습니다. 그래서 재확인할 때마다 같은 나쁜 사진을 계속 다시 보게 되고, 실제로는 딱 한 번 일어난 일인데도 "연속으로 나쁨"이라는 조건이 채워질 수 있습니다.

판정은 두 단계로 나눠서 봐야 합니다.

1. 1단계 (즉시): 지금 사진첩 안에 나쁜 사진이 있나 없나
2. 2단계 (별도 타이머): 그 "예" 상태가 몇 분 연속 유지됐나 (= 벨조건시간)

1단계만 있으면 순간적으로 튄 값 하나에도 바로 알람이 뜨는 문제가 생기기 때문에, "나쁨이 최소 몇 분은 버텨야 진짜 문제로 취급한다"는 디바운스 개념으로 2단계를 넣는 겁니다.

예시로 확인한 세 가지 패턴

예시 1 — 촬영주기 5분, 관찰범위 5분, 벨조건시간 3분인 상황에서 사진 한 장(단일 blip)만 나쁘게 찍혔는데도:

분:         0    1    2    3    4    5    6
사진찍힘:   🔴                       🟢
판정상태:    나쁨 나쁨 나쁨 나쁨 나쁨 나쁨  OK
연속나쁨시간: 0분  1분  2분  3분  4분  5분
                              ↑                ↑
                     🚨 3분에 FIRING     6분에 OK 복귀

벨조건시간(3분)이 관찰범위(5분)보다 작으니까, 단 한 장의 나쁜 사진만으로도 조건이 채워져서 울립니다. 그리고 OK 복귀는 마지막 나쁜 사진 이후 관찰범위만큼(5분) 지나야 일어난다는 것도 확인했습니다.

예시 2 — 같은 상황에서 벨조건시간만 8분(관찰범위보다 크게)으로 올리면 → 5분 만에 판정상태가 OK로 끊겨버려서 안 울립니다.

예시 3 — 벨조건시간 8분인데 진짜로 5분 간격으로 두 번 연속 나쁜 사진이 찍히면 → 8분에 FIRING이 뜹니다. 이걸 공식으로도 확인해봤는데,

k_min = ceil((P-W)/C) + 1

P=8, W=5, C=5를 대입하면 ceil((8-5)/5)+1 = 2 — 최소 2번 연속 나쁜 사진이 필요하다는 계산이 예시와 정확히 일치했습니다.

인과관계 정리

변수들 사이 의존관계를 도식으로 그려보니:

촬영주기 (C)
   │  제약: 관찰범위(W) ≥ 촬영주기(C) 여야 함 (아니면 사진첩에 빈 구간 생김)
   ▼
관찰범위 (W)
   │  촬영주기·관찰범위가 함께 결정: 관측된 나쁨 지속시간
   │        = (연속나쁨횟수-1)×촬영주기 + 관찰범위
   ▼
관측된 나쁨 지속시간
   │  이걸 벨조건시간(P)과 비교
   ▼
🚨 FIRING 시점

별도로, 관찰범위(W)는 OK 복귀 시점도 단독으로 결정합니다:
관찰범위 → OK 복귀 시점 (= 마지막 나쁜 사진 + 관찰범위)

재확인주기(R)는 원래 지연 요인이 될 수 있는데(재확인주기가 촬영주기보다 느리면 판정 자체가 밀림), OCI는 보통 1분 고정이라 대부분의 커스텀 메트릭 촬영주기(5분)보다 훨씬 빠르기 때문에 실질적인 영향이 0이라 이번 정리에서는 인과선에서 제외했습니다.

이해한 내용

가장 크게 이해하게 된 건 "알람이 몇 분 연속 나빴다"는 표현이 실제 물리적 사건의 횟수를 의미하지 않을 수도 있다는 점입니다. 관찰범위가 벨조건시간보다 크거나 같으면, 단 한 번의 이상값도 여러 번 재사용되면서 "연속 나쁨"으로 카운트될 수 있습니다. 반대로 벨조건시간을 관찰범위보다 확실히 크게 잡으면 진짜로 여러 번 나쁜 일이 반복돼야만 알람이 울립니다.

또 하나 명확해진 건 OK 복귀 조건입니다. 공식 문서 표현으로는 "최근 평가 한 번만 깨끗하면 즉시 OK로 복귀"하는데, 이게 벨조건시간과는 무관하고 오직 관찰범위에만 좌우된다는 점이 처음엔 헷갈렸습니다. FIRING은 벨조건시간이 결정하고, OK 복귀는 관찰범위가 결정한다 — 이 둘이 서로 다른 변수에 의해 결정된다는 게 비대칭적이라 정리하는 데 시간이 좀 걸렸습니다.

실전 적용

2026-07-12 사고에서는 C=5분, W=10분, P=5분으로 걸려있던 롤백 마커 알람이 문제였습니다. P=3분처럼 벨조건시간이 촬영주기(5분)보다 작으면, 어떤 관찰범위 값을 고르더라도 구조적으로 단일 blip을 못 피한다는 걸 확인했고, 그래서 P=8분(>C=5분)으로 조정했습니다. 이 원리를 알고 나니 이후에 다른 알람들(디스크, 메모리 등)의 pending-duration을 정할 때도 "촬영주기보다는 확실히 크게" 잡는 걸 기본 원칙으로 삼게 됐습니다.

실측으로도 검증했습니다. 디스크·메모리 알람의 임계치를 임시로 낮춰서(각각 10%, 5%) 강제로 트리거되게 만들고, pending-duration 5분이 지난 뒤 실제로 FIRING 전환되는 걸 타임스탬프로 확인했습니다.

disk:   DiskSpaceUtilization[5m]{resourceId="..."}.mean() > 10
memory: MemoryUtilization[5m]{resourceId="..."}.mean() > 5

o5fzatuzsq (메모리) | FIRING | 2026-07-09T03:28:00+00:00

추가 학습 계획

• 예시 3의 연속 2회 나쁨 패턴은 공식으로 유도한 것이라 아직 실제 OCI 콘솔로 재현 검증은 안 해봤습니다. 다음엔 이걸 직접 태워서 확인해보고 싶습니다.
• resolution(재확인주기)이 촬영주기보다 느린 경우의 실제 지연 효과도 시뮬레이션해보고 싶습니다. 지금 프로젝트에선 영향이 없지만 다른 환경에서는 중요할 수 있어서요.
• 다른 클라우드(AWS CloudWatch, GCP Monitoring)의 알람 평가 모델과 비교해서 이 사고 모델이 얼마나 일반화되는지도 확인해볼 계획입니다.