Grafana Alerting에서 누락 데이터 처리
Grafana Alerting에서 누락 데이터 처리 (Handle missing data in Grafana Alerting)
대상이 메트릭 데이터 보고를 멈출 때의 누락 데이터는 알림 문제 해결에서 가장 흔한 문제 중 하나예요. 클라우드 네이티브 환경에서는 pod나 노드가 수요에 맞춰 축소되거나 전체 job이 조용히 사라지면서 항상 일어나요. 이때 알림이 발화하지 않고, 시스템이 보고를 멈췄다는 것을 눈치채지 못할 수 있어요. 이 안내서는 기본 데이터가 누락되는 다양한 시나리오를 다루고 그 경우에 대응하도록 알림을 설계하는 방법을 보여줘요.
출처: 문서
본문
No Data vs. Missing Series
인스턴스가 데이터 보고를 멈추는 흔한 원인은 호스트 크래시(시스템 다운, Prometheus가 스크랩 중단), 임시 네트워크 실패(간헐적 스크랩 실패가 데이터 간격 생성), 배포 변경(위임 해제, 쿠버네티스 pod 축출, 스케일 다운), 일시적 워크로드(의도적으로 메트릭 보고 중단) 등이에요.
가장 먼저 이해할 것은 쿼리 실패(연결 오류), No Data, Missing Series의 차이예요. 알림 쿼리는 종종 인스턴스·pod·리전·라벨 조합마다 하나씩, 여러 시계열을 반환해요. 이를 다차원 알림이라 해요 — 단일 알림 규칙이 여러 알림 인스턴스를 트리거할 수 있어요.
예를 들어 애플리케이션이 배포된 리전의 초당 지연 시간을 보고하는 http_request_latency_seconds 메트릭이 있다고 해요. 쿼리는 리전마다 하나의 시리즈(예: region1, region2)를 반환하고 두 개의 알림 인스턴스만 생성해요. 이 시나리오에서 다음을 경험할 수 있어요:
- Connectivity Error : 알림 규칙 쿼리가 실패할 때
- No Data : 쿼리가 성공적으로 실행됐지만 데이터를 전혀 반환하지 않을 때
- Missing Series : 이전에 데이터를 반환하던 특정 시리즈 하나 이상이 없지만, 다른 시리즈는 여전히 데이터를 반환할 때
No Data와 Missing Series 두 경우 모두 쿼리는 기술적으로 "작동"하지만, 명시적으로 처리하도록 구성하지 않으면 알림이 발화하지 않아요. 다음 표는 어느 리전이든 지연 시간이 2초를 초과하면 알림이 발화하는 avg_over_time(http_request_latency_seconds[5m]) > 2 예제로 두 시나리오를 보여줘요.
No Data 시나리오 — 쿼리가 어떤 시리즈에 대해서도 데이터를 반환하지 않음:
| 시간 | region1 | region2 | 알림 발화 |
|---|---|---|---|
| 00:00 | 1.5s 🟢 | 1s 🟢 | ✅ 알림 없음 |
| 01:00 | No Data ⚠️ | No Data ⚠️ | ⚠️ 알림 없음 (조용한 실패) |
| 02:00 | 1.4s 🟢 | 1s 🟢 | ✅ 알림 없음 |
MissingSeries 시나리오 — 특정 시리즈(region2)만 사라짐:
| 시간 | region1 | region2 | 알림 발화 |
|---|---|---|---|
| 00:00 | 1.5s 🟢 | 1s 🟢 | ✅ 알림 없음 |
| 01:00 | 1.6s 🟢 | Missing Series ⚠️ | ⚠️ 알림 없음 (조용한 실패) |
| 02:00 | 1.4s 🟢 | 1s 🟢 | ✅ 알림 없음 |
두 경우 모두 뭔가 조용히 고장났어요.
Prometheus에서 누락 데이터 감지
Prometheus는 쿼리가 데이터를 반환하지 않을 때 알림을 발화하지 않아요. 쿼리 오류처럼 보고할 것이 없다고 단순 가정해요. 명시적으로 확인하지 않으면 누락 데이터가 기존 알림을 트리거하지 않아요. Prometheus에서 누락 데이터를 잡는 일반적인 방법은 absent_over_time 함수를 쓰는 것이에요:
absent_over_time(http_request_latency_seconds[5m]) == 1
이것은 http_request_latency_seconds의 모든 시리즈가 5분간 없을 때 트리거해요 — 전체 메트릭이 사라질 때 No Data 경우를 잡아요. 하지만 absent_over_time()은 라벨을 보존하지 않아 어떤 특정 시리즈가 누락됐는지 감지하지 못해요. 알림은 어떤 시리즈가 보고를 멈췄는지 알려주지 않고 쿼리가 데이터를 반환하지 않는다는 것만 알려줘요.
리전·라벨별 누락 데이터를 확인하려면 알림 쿼리에 라벨을 지정할 수 있어요:
# Detect missing data in region1
absent_over_time(http_request_latency_seconds{region="region1"}[5m]) == 1
# Detect missing data in region2
absent_over_time(http_request_latency_seconds{region="region2"}[5m]) == 1
하지만 이는 잘 확장되지 않아요. 각 라벨 집합에 하드코딩된 쿼리는 인스턴스가 언제든 나타나고 사라질 수 있는 동적 클라우드 환경에서 신뢰할 수 없어요. 특정 대상이 사라졌을 때를 감지하려면 아래 "누락 시리즈에 대한 알림 인스턴스 축출(Evict)"을 참고해 Grafana가 이 경우를 어떻게 처리하고 감지를 설정하는지 확인하세요.
Grafana 알림에서 No Data 문제 관리
Prometheus는 absent_over_time() 같은 함수로 누락 데이터를 감지하지만, Grafana 알림에 사용 가능한 모든 데이터 소스(Graphite, InfluxDB, PostgreSQL 등)가 비슷한 함수를 지원하는 것은 아니에요. 이를 처리하기 위해 Grafana Alerting은 내장 No Data 상태 로직을 구현해서 absent_* 쿼리로 누락 데이터를 감지할 필요가 없어요. 대신 알림 규칙 설정에서 데이터가 반환되지 않을 때 알림이 어떻게 동작할지 구성할 수 있어요.
오류 처리와 비슷하게, Grafana는 기본적으로 특별한 No data 알림을 트리거하고 이 동작을 제어할 수 있게 해요. Configure no data and error handling에서 "Alert state if no data or all values are null"을 클릭하고 다음 옵션 중 하나를 선택하세요:
- No Data (default) : 새
DatasourceNoData알림을 트리거해 No data를 특정 문제로 취급. - Alerting : 데이터가 사라지면 각 기존 알림 인스턴스를 Alerting 상태로 전이.
- Normal : 누락 데이터를 무시하고 모든 인스턴스를 Normal 상태로 전이. 실험적 서비스, 산발적 작업, 주기적 보고 같은 간헐적 데이터를 받을 때 유용.
- Keep Last State : 데이터가 돌아올 때까지 알림을 이전 상태에 유지. 까다로운 exporter·시끄러운 환경처럼 짧은 메트릭 간격이 자주 발생하는 환경에서 흔함.
DatasourceNoData 알림 관리
Grafana가 NoData 알림을 트리거하면 원래 알림 인스턴스와 분리된 별개의 알림 인스턴스를 만들어요. 이 알림은 다르게 동작해요:
- 전용
alertname: DatasourceNoData를 사용해요. - 원래 알림 인스턴스의 모든 라벨을 상속하지 않아요.
이 때문에 DatasourceNoData 알림은 알림 전용 설정이 필요할 수 있어요. 일반 권장사항은 중복 DatasourceError 알림 줄이기를 참고하세요 — 유사한 관행을 NoData 알림에 적용할 수 있어요.
누락 시리즈에 대한 알림 인스턴스 축출 (Evict alert instances for missing series)
MissingSeries는 일부 시리즈만 사라지고 전부가 아닐 때 발생해요. Grafana는 두 평가 간격 후 누락 시리즈를 stale로 표시하고 알림 인스턴스 축출 프로세스를 트리거해요. 내부 동작은 다음과 같아요:
- 데이터가 누락된 알림 인스턴스는 두 평가 간격 동안 마지막 상태를 유지해요.
- 그 후에도 데이터가 여전히 누락되면: Grafana가
grafana_state_reason: MissingSeries애노테이션을 추가해요. 인스턴스는 Normal 상태로 전이돼요. 이전에 발화 중이었다면 해제(resolved) 알림이 전송돼요. 알림 인스턴스는 Grafana UI에서 제거돼요.
인스턴스가 stale이 되면 사라지기 전에 알림 이력에서 Normal (Missing Series)로 찾을 수 있어요. 축출 과정:
| 시간 | region1 | region2 | 알림 발화 |
|---|---|---|---|
| 00:00 | 1.5s 🟢 | 1s 🟢 | 🟢🟢 알림 없음 |
| 01:00 | 3s 🔴 Alerting | 3s 🔴 Alerting | 🔴🔴 두 리전 모두 인스턴스 발화 |
| 02:00 | 1.6s 🟢 | (MissingSeries) ⚠️ Alerting | 🟢🔴 region2 누락, 상태 유지 |
| 03:00 | 1.4s 🟢 | (MissingSeries) Normal | 🟢🟢 region2 해제, 📩 알림 전송, 인스턴스 축출 |
| 04:00 | 1.4s 🟢 | — | 🟢 알림 없음. region2 축출됨 |
왜 MissingSeries가 No Data 동작과 일치하지 않나요?
오토스케일링 그룹, 일시적 pod, 스팟 인스턴스 같은 동적 환경에서 시리즈는 자연스럽게 오고 가요. MissingSeries는 보통 인프라나 배포 변경을 알려요. 기본적으로 No Data는 잠재적 문제를 나타내도록 알림을 트리거해요. MissingSeries의 축출 과정은 pod나 인스턴스가 사라질 때 알림 플래핑을 막고 소음을 줄이도록 설계돼요. 스케일 이벤트가 빈번한 환경에서는 개별 인프라 신호보다 증상 기반 알림을 우선하고, 개별 인스턴스를 명시적으로 추적할 필요가 없다면 집계 알림을 사용하세요.
MissingSeries 알림 처리
stale 알림 인스턴스는 Alerting, No Data, Error 같은 발화 상태에서 Normal로 전이될 때 해제 알림을 트리거하고, grafana_state_reason 애노테이션이 MissingSeries로 설정돼 알림이 복구가 아니라 시리즈 데이터 누락으로 축출됐음을 나타내요. 이 알림을 인식하면 적절히 처리할 수 있어요:
grafana_state_reason애노테이션을 표시해 MissingSeries 알림을 명확히 식별.- 또는 이 애노테이션으로 이 알림을 다르게 처리.
또한 이 알림을 검토해 뭔가 고장났는지, 알림이 불필요했는지 확인하세요. 소음을 줄이려면:
- 계획된 유지보수·롤아웃 중 알림을 무음화(silence)하거나 뮤트.
- 오고 갈 것으로 예상하는 시리즈에서 발화하지 않도록 규칙을 조정하고, 대신 집계 알림을 사용.
Prometheus에서 missing series 감지
이전에 region 같은 특정 라벨의 누락 데이터를 감지하는 예제를 보여줬어요:
# Detect missing data in region1
absent_over_time(http_request_latency_seconds{region="region1"}[5m]) == 1
# Detect missing data in region2
absent_over_time(http_request_latency_seconds{region="region2"}[5m]) == 1
하지만 이 접근법은 가능한 모든 region 값을 하드코딩해야 하므로 잘 확장되지 않아요. 대안으로 present_over_time 함수로 누락 시리즈를 동적으로 감지하는 알림 규칙을 만들 수 있어요:
present_over_time(http_request_latency_seconds{}[24h])
unless
present_over_time(http_request_latency_seconds{}[10m])
또는 region 같은 라벨로 그룹화하려면:
group(present_over_time(http_request_latency_seconds{}[24h])) by (region)
unless
group(present_over_time(http_request_latency_seconds{}[10m])) by (region)
이 쿼리는 지난 24시간 중 어느 시점에는 존재했지만 지난 10분에는 존재하지 않은 리전(또는 다른 대상)을 찾아요. 규칙은 각 누락 리전에 대해 알림 인스턴스를 트리거해요. 같은 기법을 어떤 라벨·대상 차원에도 적용할 수 있어요.
결론
누락 데이터가 항상 실패는 아니에요. 특정 대상이 보고를 멈출 때 동적 환경의 흔한 시나리오예요. Grafana Alerting은 구별되는 시나리오를 자동 처리해요. 이렇게 생각하세요:
DatasourceNoData와MissingSeries알림은 일반 알림처럼 동작하지 않으므로 이해하세요.- Grafana의 No Data 처리 옵션으로 쿼리가 아무것도 반환하지 않을 때 무슨 일이 일어날지 정의하세요.
- NoData가 문제가 아닐 때 쿼리를 항상 데이터를 반환하도록 재작성하는 것을 고려해요 — 예: Prometheus에서
your_metric_query OR on() vector(0)로 빈 결과일 때 0 반환. - Prometheus에서
absent_over_time()이나present_over_time으로 메트릭·대상이 사라질 때를 감지하세요. - 스크랩 지연으로 데이터가 자주 누락되면 데이터 지연을 고려하는 기법을 쓰세요: Grafana에서 Time Range 쿼리 옵션을 조정해 실시간보다 약간 뒤(예: To를 now-1m로) 평가해 늦은 데이터 포인트를 보정하거나, Prometheus에서
last_over_time(metric_name[10m])으로 주어진 창의 가장 최근 샘플을 고르세요. - 기본적으로 모든 인스턴스에 알림을 걸지 마세요. 동적 환경에서는 개별 인스턴스 누락이 사용자에게 직접 영향을 주지 않는다면 집계하고 증상에 알림을 거는 것이 좋아요.
- 사라지는 데이터로 소음이 너무 많다면 알림을 조정하거나 Keep Last State를 사용하거나 그 알림을 다르게 라우팅하는 것을 고려해요.
- 알림 쿼리 실패를 포함한 연결 문제는 형제 안내서인 연결 오류 처리를 참고하세요.