알림의 연결 오류 처리

알림의 연결 오류 처리 (Handle connectivity errors in alerts)

연결 문제는 오해를 부르는 알림이나 눈치채지 못한 실패의 흔한 원인이에요. 대상이 오프라인이 되거나, Prometheus가 스크랩하지 못하거나, 알림 쿼리가 대상 타임아웃·네트워크 다운으로 실패하는 등 여러 이유가 있을 수 있어요. 이 안내서는 Prometheus 규칙을 쓰든 Grafana Alerting을 쓰든 두 가지를 결합하든 이런 실패 유형을 감지·처리하는 방법을 다뤄요.

출처: 문서

본문

알림의 연결 문제 이해

연결 문제는 몇 가지 흔한 시나리오로 나뉘어요: 서버·컨테이너 크래시/종료, 서비스 과부하·타임아웃, 잘못 설정된 인증·권한, DNS 문제·ISP 중단 같은 네트워크 문제. 알림 관점에서 연결 오류는 보통 두 가지 사용 사례 중 하나를 말해요:

• 대상이 다운·도달 불가능: 서비스 크래시, 호스트 다운, 방화벽·DNS 문제로 연결 차단. 이는 **가용성 문제(availability problems)**예요.
• 알림 쿼리 실패: 알림이 쿼리를 평가하지 못함 — 데이터 소스 타임아웃이나 잘못된 쿼리로. 이는 **실행 오류(execution errors)**예요.

이 두 경우는 다르게 동작하고 다른 전략이 필요하므로 일찍 구분하는 게 도움이 돼요.

대부분의 알림 규칙은 대상에 직접 닿지 않아요. 실제 인프라·애플리케이션에서 데이터를 스크랩하는 Prometheus 같은 모니터링 시스템의 메트릭을 쿼리해요. 연결 문제가 나타날 수 있는 두 가지 전형적 설정이 있어요:

• Alert rule → Target: 예: 데이터베이스 같은 외부 데이터 소스를 쿼리하는 규칙.
• Alert rule → Prometheus ← Target: Observability 스택에서 더 흔해요. Prometheus가 노드·컨테이너를 스크랩하고 규칙이 나중에 메트릭을 쿼리해요. 이 설정에서는 어느 쪽이든 연결 문제가 생길 수 있어요. Prometheus가 대상을 스크랩하지 못하면 규칙이 발화하지 않을 수 있는데, 뭔가 잘못됐을 가능성이 높은 상황이에요.

Prometheus up 메트릭으로 대상 가용성 감지

Prometheus는 scrape_interval 주기로 대상에서 메트릭을 정기 스크랩해요. 기본 스크랩 간격은 60초로 일반적인 관행으로 간주돼요. Prometheus는 스크랩 대상마다 up이라는 내장 메트릭을 제공해요:

• up == 1 : 대상 도달 가능, Prometheus가 예상대로 메트릭 수집.
• up == 0 : Prometheus가 대상에 도달할 수 없음 — 다운타임이나 네트워크 오류 가능.

대상이 도달 불가능해질 때를 감지하는 일반적인 알림 규칙 PromQL:

up == 0

하지만 이 규칙은 스크랩 실패 한 번으로 발화해 시끄러울 수 있어요. 소음을 줄이려면 지연을 추가하세요:

up == 0 for: 5m

Prometheus의 for 옵션(또는 Grafana의 pending 기간)은 조건이 전체 기간 동안 참일 때까지 알림을 지연시켜요. 5분을 기다리면 단일 스크랩 오류가 발화 알림을 만들지 않아요. Prometheus가 기본적으로 매분 스크랩하므로 알림은 5회 연속 실패 후에만 발화해요.

하지만 이런 up 알림은 몇 가지 잠재적 단점이 있어요:

• 스크랩 간격 사이로 실패가 빠질 수 있음: 두 평가 사이에 시작·끝나는 중단은 감지되지 않아요. for 기간을 줄일 수 있지만, 그러면 거짓 경보를 트리거하는 스크랩 실패가 생길 수 있어요.
• 간헐적 복구가 for 타이머를 재설정: 성공적인 스크랩 한 번이 알림 타이머를 재설정해 간헐적 중단을 가려요.

기간이 길수록 이런 일이 발생할 가능성이 커져요. 단일 복구가 알림을 재설정하므로 up == 0 for: 5m이 때로는 신뢰할 수 없어요. 대상이 대부분 다운 상태여도 알림이 발화하지 않아 지속적 문제를 모를 수 있어요.

avg_over_time으로 신호 평활화

이 문제를 우회하는 한 방법은 up 메트릭을 비슷하거나 더 긴 기간에 걸쳐 평균내 신호를 평활화하는 것이에요:

avg_over_time(up[10m]) < 0.8

이 규칙은 연속 스크랩 실패를 찾는 대신, 대상이 지난 10분 중 20% 이상 도달 불가능일 때 발화해요. 1분 스크랩 간격에서 지난 10분 내 3회 이상의 실패 스크랩이 알림을 트리거해요. 이 쿼리는 임계값과 시간 창으로 정확도를 제어하므로 for 기간(또는 Grafana의 pending)을 0m이나 1m 같은 더 짧은 값으로 낮춰 더 빨리 발화시킬 수 있어요.

합성 검사로 외부 가용성 모니터링

Prometheus는 종종 모니터링 대상과 같은 네트워크 안에서 실행돼요. 즉 Prometheus는 대상에 도달할 수 있어도, 외부 사용자가 도달 가능하다는 보장은 없어요. 방화벽, DNS 설정 오류, 기타 네트워크 문제가 Prometheus 스크랩이 성공하는 동안 공개 트래픽을 차단할 수 있어요. 이때 **합성 모니터링(synthetic monitoring)**이 도움이 돼요. Blackbox Exporter 같은 도구로 네트워크 외부에서 서비스가 사용 가능하고 도달 가능한지 지속적으로 검증할 수 있어요. Blackbox Exporter는 검사 결과를 메트릭으로 노출하며, Prometheus가 다른 대상처럼 스크랩할 수 있어요. 예를 들어 probe_success 메트릭은 프로브가 서비스에 도달했는지 보고해요. 구조:

Alert rules → Prometheus ← Blackbox Exporter (external probe) → Target

외부에서 서비스에 도달할 수 없을 때를 감지하려면 probe_success 메트릭으로 알림을 정의할 수 있어요:

probe_success == 0 for: 5m

이 알림은 프로브가 5분 연속 실패하면 발화해요 — 서비스를 외부에서 도달할 수 없음을 나타내요. 내부·외부 검사를 결합하면 연결 오류 감지를 더 신뢰성 있게 만들어요:

up == 0 or probe_success == 0

up 메트릭처럼 avg_over_time()로 평활화해 더 견고하게 만들 수 있어요:

avg_over_time(up[10m]) < 0.8 or avg_over_time(probe_success[10m]) < 0.8

이 알림은 Prometheus가 지난 10분 중 20% 이상 대상 스크랩에 실패하거나 외부 프로브가 20% 이상 실패하면 발화해요. 이 평활화 기법은 어떤 이진 가용성 신호에도 적용할 수 있어요.

오프라인 호스트 관리

많은 설정에서 Prometheus는 공통 job 라벨 뒤의 서버·컨테이너 플릿처럼 같은 대상 아래 여러 호스트를 스크랩해요. 한 호스트가 오프라인이 되고 다른 호스트는 정상적으로 메트릭을 보고하는 경우가 흔해요. 알림이 instance, host, pod 같은 라벨로 나누지 않고 일반 up 메트릭만 확인한다면 호스트가 보고를 멈춘 것을 놓칠 수 있어요. 이는 이 맥락에서 연결 오류가 아니에요 — 특정 대상 하나 이상이 조용해진 것뿐이에요. 이런 문제는 up == 0 알림으로 잡히지 않아요. 이런 경우 missing data 처리 안내서를 참고하세요.

Grafana Alerting의 쿼리 오류 처리

모든 연결 문제가 대상 오프라인에서 오는 건 아니에요. 때로는 알림 규칙이 대상을 쿼리할 때 실패해요. 이는 가용성 문제가 아니라 쿼리 실행 오류예요: 데이터 소스 타임아웃, 네트워크 끊김, 잘못된 쿼리. 이 오류는 스택의 다른 부분(데이터 소스와 그 대상 사이가 아니라 알림 규칙과 데이터 소스 사이)에서 와요. 가용성 문제는 up이나 probe_success 같은 메트릭으로 처리하지만 실행 오류는 다른 설정이 필요해요.

Grafana Alerting은 데이터 소스와 무관하게 실행 오류를 내장 처리해요. Prometheus뿐 아니라 Graphite, InfluxDB, PostgreSQL 등도 포함해요. 기본적으로 Grafana Alerting은 쿼리 오류를 자동 처리해 중요한 실패를 놓치지 않게 해요. 규칙이 실행에 실패하면 Grafana가 특별한 DatasourceError 알림을 발화해요. Configure no data and error handling에서 "Alert state if execution error or timeout"을 클릭해 원하는 옵션을 선택할 수 있어요:

• Error (default) : 별도의 DatasourceError 알림을 트리거. 규칙이 항상 쿼리 오류를 알리도록 보장하지만 소음을 만들 수 있음.
• Alerting : 오류를 알림 조건이 발화하는 것처럼 취급. 규칙의 모든 기존 인스턴스를 Alerting 상태로 전이.
• Normal : 쿼리 오류를 무시하고 모든 인스턴스를 Normal 상태로 전이. 오류가 중요하지 않거나 이미 다른 알림이 연결 문제를 감지 중일 때 유용.
• Keep Last State : 쿼리가 다시 성공할 때까지 이전 상태 유지. 불안정한 환경에서 플래핑을 피하기에 적합.

이는 규칙이 Prometheus 자체를 쿼리할 때도 외부 데이터 소스만이 아니라 적용돼요.

연결 오류를 위한 알림 설계

실제로는 up이나 probe_success를 사용한 명시적 알림 규칙을 만들지 먼저 결정하고, 각 규칙에 대해 전용 연결 알림이 이미 있는지, 대상 안정성, 알림 중요도에 따라 오류 처리 동작을 선택하세요. 사용자에게 영향을 주지 않을 수 있는 인프라 신호보다는 증상 심각도에 따라 알림 우선순위를 정하세요.

중복 오류 알림 줄이기

단일 데이터 소스 오류가 여러 알림을 동시에 발화시켜 소음이 될 수 있어요. 앞서 설명한 대로 Grafana 알림의 오류 처리 동작을 제어할 수 있어요. Keep Last State나 Normal 옵션은 알림이 발화하지 않게 해 중복 알림을 피하는 데 도움을 줘요, 특히 이미 up이나 probe_success 알림으로 커버되는 서비스에요. 기본 동작을 쓰면 단일 연결 오류가 여러 DatasourceError 알림을 트리거할 가능성이 높아요. 이 알림을 원래 알림과 같은 방식으로 취급하지 말고 전용 알림 전략을 구현하세요:

• datasource_uid 라벨로 같은 데이터 소스의 오류를 그룹화해 DatasourceError 알림의 중복을 줄여요.
• DatasourceError 알림을 별도로 라우팅해 영향과 긴급성에 따라 다른 팀이나 채널로 보내요.

결론

연결 문제는 시끄럽거나 오해를 부르는 알림의 흔한 원인이에요. 이 안내서는 두 가지 유형을 다뤘어요: 대상 자체가 다운·도달 불가능한 가용성 문제, 그리고 규칙이 데이터 소스에 도달하지 못하는 쿼리 실행 오류(타임아웃, 잘못된 쿼리, 데이터 소스 중단). 이들은 스택의 다른 부분에서 오므로 각각 다른 기법이 필요해요. Prometheus에서는 up == 0만 의존하지 말고, 간헐적 실패를 고려해 쿼리를 평활화하고 네트워크 외부 도달성을 감지하는 합성 모니터링을 사용하세요. Grafana Alerting에서는 오류 처리를 명시적으로 구성하세요 — 모든 알림이 같지 않고 긴급성도 다르므로, 알림의 신뢰성·심각도와 연결 문제 전용 알림 유무에 따라 오류 처리 동작을 조정하세요. 그리고 세 번째 경우인 missing data도 잊지 마세요.

더 알아보기 (Learn more)

• Grafana Alerting에서 누락 데이터 처리
• No Data 및 Error 알림
• 알림 알림 처리
• 알림 모범 사례
• Grafana Alerting 소개