모니터 경보 문제 해결

원문 보기 위키 갱신 2026.10.05

모니터 경보 문제 해결 (Troubleshooting Monitor Alerts)

이 가이드는 모니터의 경보 동작이 타당한지 판단하는 데 도움이 되는 몇 가지 기초 개념을 소개해요. 모니터의 평가가 실제 기반 데이터를 정확히 반영하지 못하고 있다고 의심된다면, 이 가이드를 이용해 모니터를 점검하고 다음을 문제 해결할 수 있어요:

모니터 상태와 상태(status) 동작
데이터 가용성과 평가 문제
경보 조건 구성
모니터 그룹과 보존
알림 문제

출처: 문서

본문

모니터 상태와 상태 표시 (Monitor state and status)

모니터 평가(evaluations) 는 무상태(stateless)예요. 즉 특정 평가의 결과가 이전 평가의 결과에 의존하지 않아요. 하지만 모니터 자체는 상태가 있는(stateful) 객체이고, 그 상태는 쿼리와 구성의 평가 결과에 따라 업데이트돼요. 특정 상태를 가진 모니터 평가가 반드시 모니터의 상태를 그와 같은 상태로 바꾸는 것은 아니에요.

상태 추적 방법 (How status is tracked)

모니터 평가와 상태 모두에서, 상태는 그룹별로 추적돼요. 멀티 알림(multi alert) 모니터의 경우 그룹은 각 그룹화 키에 대해 하나의 값을 가진 태그 집합이에요(예: env와 host로 그룹화된 모니터의 env:dev, host:myhost). 단순 경보(simple alert)의 경우에는 그룹이 하나뿐이고(*), 모니터 범위 안의 모든 것을 나타내요.

상태가 평가와 일치하지 않을 때 (When state doesn't match evaluation)

모니터의 상태는 평가가 없어도 업데이트될 때가 있어요. 예를 들어 자동 해결 (auto-resolve) 때문이에요.

데이터 가용성과 평가 문제 (Data availability and evaluation issues)

모니터의 상태나 상태 표시(status)가 기대와 다르다면, 기반 데이터 소스의 동작을 확인해 보세요. 메트릭 모니터의 경우 히스토리 (history) 그래프를 사용해 메트릭 쿼리가 가져오는 데이터 포인트를 볼 수 있어요. N/A 그룹은 모니터에 포함되지 않지만 대시보드 쿼리에는 표시돼요.

희소 메트릭 (Sparse metrics)

메트릭이 모니터의 평가 창에 없고, 모니터가 no-data 조건을 예상하도록 구성되지 않은 경우, 평가는 skipped(건너뜀)될 수 있어요. 이 경우 모니터 상태는 업데이트되지 않으므로 이전에 OK 상태였던 모니터는 OK로 남고, Alert 상태였던 모니터도 마찬가지로 유지돼요. 모니터 상태 페이지의 히스토리 그래프를 사용해 관심 있는 그룹과 시간대를 선택하세요. 데이터가 희소하게 채워져 있다면 모니터 산술과 희소 메트릭 (monitor arithmetic and sparse metrics)을 참고하세요.

롤업 함수가 있는 "No Data" 상태 ("No Data" status with rollup functions)

모니터가 예상치 못하게 "No Data" 상태로 평가된다면, 롤업(rollup)과 평가 창 설정을 검토해 보세요. 예를 들어 모니터에 4분 롤업과 20분 평가 창이 있으면, 4분마다 데이터 포인트가 하나씩 생성되어 창 안에 최대 5개의 데이터 포인트가 생겨요. Require Full Window(전체 창 요구) 옵션이 활성화된 경우, 창이 완전히 채워지지 않아 평가가 "No Data"로 이어질 수 있어요.

대부분의 사용 사례에서는 특정 시나리오가 정확한 평가를 위해 완전한 데이터를 요구하지 않는 한 Require Full Window 설정을 비활성화하세요. 자세한 내용은 모니터의 롤업 (Rollups in monitors)을 참고하세요.

클라우드 메트릭 지연 (Cloud metric delays)

크롤러 기반 클라우드 메트릭을 쿼리하는 모니터라면, 평가 지연 (evaluation delay)을 사용해 모니터가 평가하기 전에 메트릭이 도착했는지 확인하는 것이 좋아요. 클라우드 통합 크롤러 일정에 대한 자세한 내용은 클라우드 메트릭 지연 (cloud metric delay)을 읽어보세요.

경보 조건 (Alert conditions)

예상치 못한 모니터 동작은 때로 잘못 구성된 경보 조건 (alert conditions) 때문일 수 있고, 이는 모니터 유형에 따라 달라져요. 모니터 쿼리가 as_count() 함수를 사용한다면 모니터 평가에서의 as_count() (as_count() in Monitor Evaluations) 가이드를 확인하세요.

모니터가 예상치 못하게 경보를 발생시키면 사용 사례에 맞는 올바른 집계자(aggregator)를 사용하고 있는지 확인해 보세요. 각 집계 방식이 경보 동작에 어떤 영향을 미치는지에 대한 예시는 모니터 집계자 가이드 (Monitor Aggregators guide)를 참고하세요.

복구 임계값(recovery thresholds)을 사용한다면 복구 임계값 가이드 (recovery thresholds guide)에 나열된 조건을 확인해서 해당 동작이 예상된 것인지 확인해 보세요.

새 그룹 지연 (New group delays)

멀티 알림 모니터 범위 안에서 새 모니터 그룹을 만들 것으로 예상된다면, 새 그룹 평가에 지연을 구성하는 것이 좋아요. 이렇게 하면 새 컨테이너 생성과 관련된 높은 리소스 사용량 같은 새 그룹의 예상 동작에서 발생하는 경보를 피할 수 있어요. 자세한 내용은 새 그룹 지연 (new group delay)을 읽어보세요.

모니터 그룹과 보존 (Monitor groups and retention)

Datadog는 쿼리가 변경되지 않는 한, 모니터 그룹이 보고를 중단한 후에도 일정 기간 동안 UI에 유지해요. 이 보존 기간은 모니터 그룹이 얼마나 오래 표시되고 계속 평가되는지에 영향을 줘요. 보존 기간은 모니터 유형과 구성에 따라 달라져요. 자세한 내용은 그룹 보존 시간 (Group retention time)을 참고하세요.

모니터 그룹의 지속성에 대한 자세한 내용(이름이 바뀌거나 폐기된 호스트가 경보에 계속 나타나는 경우를 처리하는 방법 포함)은 모니터 설정 변경이 적용되지 않는 경우 (Monitor settings changes not taking effect)를 참고하세요.

알림 문제 (Notification issues)

모니터가 예상대로 동작하는데 원치 않는 알림이 생성된다면, 알림을 줄이거나 억제하는 여러 옵션이 있어요:

상태를 빠르게 오가는 모니터의 경우 경보 요동 줄이기 (reduce alert flapping)을 읽고 경보 피로를 최소화하는 방법을 확인하세요.
예상된 경보이거나 조직에 유용하지 않은 경보라면 다운타임 (Downtimes)을 사용해 원하지 않는 알림을 억제하세요.
경보 라우팅을 제어하려면 템플릿 변수 (template variables)와 조건부 변수 (conditional variables)로 warning 또는 alert 상태를 분리하는 방법을 사용하세요.

누락된 알림 (Missing notifications)

알림이 제대로 전달되지 않고 있다고 의심된다면, 아래 항목을 확인해서 알림이 전달될 수 있도록 해 주세요:

수신자의 이메일 환경설정을 확인하고 Notification from monitor alerts가 체크되어 있는지 확인해요.
이벤트 스트림 (event stream)에서 Error delivering notification 문자열이 포함된 이벤트를 확인해요.

Opsgenie 다중 알림 (Opsgenie multi-notifications)

모니터에서 여러 개의 @opsgenie-[...] 알림을 사용하고 있다면, Datadog는 이 알림들을 같은 별칭(alias)으로 Opsgenie에 보내요. Opsgenie의 기능 때문에 Opsgenie는 중복으로 보이는 것을 버리게 돼요.

모니터 경보 문제 해결