Prometheus 알림

Prometheus 알림 (Alerting)

Grafana Alerting을 Prometheus와 함께 사용해 시계열 데이터를 기반으로 알림을 만들 수 있어요. 지표를 모니터링하고 이상을 감지하며 특정 조건이 충족되면 알림을 받을 수 있어요. Grafana Alerting 일반 정보는 Grafana Alerting을 참고하세요.

출처: Prometheus alerting

본문

Grafana Cloud를 이용하면 Grafana 인스턴스를 직접 설치·유지·확장할 필요가 없어요. 무료 계정을 만들면 10k 메트릭, 50GB 로그, 50GB 트레이스, 500VUh k6 테스트 등이 영구 무료로 제공돼요.

시작하기 전에

Prometheus로 알림을 만들기 전에 다음을 확인해요.

Grafana에 Prometheus 데이터 소스가 구성되어 있을 것
알림 규칙을 만들 적절한 권한이 있을 것
모니터링할 PromQL 지표에 대한 이해가 있을 것

알림 규칙 유형

Prometheus는 Grafana에서 두 가지 알림 워크플로우를 지원해요.

유형	설명
Grafana-managed alert rules	Prometheus를 쿼리 데이터 소스로 사용해 Grafana 내에서 정의·평가되는 알림 규칙. Grafana Alerting UI에서 전적으로 만들고 관리해요.
Data source-managed rules	Prometheus 자체(`prometheus.yml` 또는 규칙 파일)에 정의된 알림 규칙. 데이터 소스 구성에서 Manage alerts via Alerting UI가 활성화되면 Grafana가 기존 규칙을 Alerting UI에 표시해요. Prometheus(Mimir와 달리)에서는 읽기 전용이에요.

Grafana-managed 알림 규칙 만들기

Prometheus로 Grafana-managed 알림 규칙을 만들려면:

Alerting > Alert rules로 이동해요.
New alert rule을 클릭해요.
알림 규칙의 이름을 입력해요.
Prometheus 데이터 소스를 선택해요.
쿼리 편집기에서 PromQL 쿼리를 작성해요.
알림 조건을 구성해요(예: 마지막 값이 임계값보다 높을 때).
평가 간격과 대기 기간을 설정해요.
알림과 라벨을 구성해요.
Save rule을 클릭해요.

자세한 지침은 Create a Grafana-managed alert rule을 참고하세요.

데이터 소스 관리형 규칙 보기

Prometheus 데이터 소스 구성에서 Manage alerts via Alerting UI가 활성화되면 Grafana가 Prometheus에 정의된 알림 규칙을 가져와 표시해요. 이 규칙은 Grafana-managed 규칙 옆에 표시되지만 데이터 소스 관리형으로 표시돼요.

Prometheus 데이터 소스에서는 이 보기가 읽기 전용이에요. 이 규칙을 수정하려면 Prometheus 규칙 파일을 직접 업데이트해요.

참고: Mimir와 Cortex 데이터 소스에서는 Alerting UI가 데이터 소스 관리형 규칙의 보기와 생성을 모두 지원해요. Prometheus는 보기만 지원해요.

평가 그룹과 간격

알림 규칙은 평가 그룹으로 구성돼요. 각 그룹은 그 그룹의 규칙이 얼마나 자주 평가되는지 결정하는 평가 간격을 가져요. 예를 들어 평가 간격 1m은 알림 쿼리가 60초마다 실행된다는 뜻이에요.

**대기 기간(pending period)**은 조건이 발화 전에 연속으로 참이어야 하는 시간을 결정해요. 예를 들어 1분 평가 간격과 5분 대기 기간이라면 발화 전에 조건이 5회 연속 평가에서 참이어야 해요.

사용 사례에 따라 평가 간격을 선택해요.

15s–30s: 빠른 감지가 중요한 중요 인프라 알림
1m: 표준 모니터링 알림(권장 기본값)
5m: 긴급하지 않거나 시끄러운 지표로 평가 부하를 줄이고 싶을 때

예시 알림 쿼리

다음 예시는 Prometheus의 일반적인 알림 시나리오를 보여줘요. 각 예시는 PromQL 쿼리와 알림 조건 구성 방법을 보여줘요.

높은 CPU 사용량 알림

CPU 사용량을 모니터링하고 90%를 초과하면 알림을 보내요.

Query A:

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[$__rate_interval])) * 100)

조건: A의 마지막 값이 90보다 높을 때 알리도록 임계값을 설정해요. 이 접근은 지표 쿼리와 임계값을 분리해 PromQL을 편집하지 않고 나중에 임계값을 조정하기 쉽게 해요.

높은 메모리 사용량 알림

노드 전체의 메모리 사용량을 모니터링해요.

Query A:

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

조건: A의 마지막 값이 85를 초과하면 알림.

높은 오류율 알림

서비스별 HTTP 오류율을 모니터링해요.

Query A:

sum(rate(http_requests_total{status=~"5.."}[$__rate_interval])) by (job)
  /
sum(rate(http_requests_total[$__rate_interval])) by (job)
  * 100

조건: A의 마지막 값이 5(오류율 5% 초과 의미)를 초과하면 알림.

타깃 다운 알림

Prometheus 스크래이프 대상이 도달 가능한지 모니터링해요.

Query A:

up{job="myservice"}

조건: A의 마지막 값이 1보다 낮으면 알림.

지표가 사라질 때 알림

absent()를 사용해 지표가 완전히 스크래이프되지 않는 것을 감지해요. 예를 들어 서비스가 충돌해 지표를 더 이상 보고하지 않을 때:

Query A:

absent(up{job="myservice"})

조건: A의 마지막 값이 1과 같으면 알림(absent() 함수는 지표가 없으면 1을, 지표가 있으면 아무것도 반환하지 않아요).

시간 창에 걸친 부실 감지(지표는 존재하지만 최근에 보고하지 않음)의 경우:

absent_over_time(up{job="myservice"}[5m])

다중 조건 알림(높은 지연 시간 AND 높은 트래픽)

여러 쿼리와 표현식을 사용해 여러 조건이 동시에 참일 때만 알림을 보내요. 이렇게 하면 낮은 트래픽 기간에 알림을 피해 노이즈를 줄여요.

Query A (P95 지연 시간):

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="api"}[$__rate_interval])) by (le))

Query B (요청률):

sum(rate(http_requests_total{job="api"}[$__rate_interval]))

Expression C (Math, 두 조건 결합):

$A > 2 && $B > 100

조건: C에 값이 있을 때 알림(지연 시간이 2초를 초과하고 요청률이 100 req/s를 초과할 때만 데이터를 반환해요).

기록 규칙 (Recording rules)

Grafana-managed recording rules는 비용이 큰 PromQL 표현식을 스케줄에 따라 미리 계산하고 결과를 새 메트릭으로 Prometheus 호환 데이터 소스에 기록해요. 이렇게 하면 대시보드 로드나 알림 평가 때마다 비용이 큰 표현식을 다시 평가하는 대신 미리 집계된 지표를 질의할 수 있어요.

기록 규칙을 언제 사용하나

동일한 비용이 큰 표현식을 반복적으로 질의하는 대시보드 패널: 한 번 미리 계산하고 결과를 질의해요.
복잡한 표현식의 알림 규칙: 미리 집계된 지표에 대해 알림을 보내 알림 쿼리를 단순화해요.
높은 카디널리티 집계: 수천 개의 시리즈를 소수의 미리 계산된 시리즈로 줄여요.

Prometheus용 Grafana-managed 기록 규칙 설정

데이터 소스를 기록 규칙 대상으로 활성화: Prometheus 데이터 소스 구성에서 Allow as recording rules target이 켜져 있는지 확인해요(기본적으로 켜져 있음). 이렇게 하면 Grafana가 기록 규칙 결과를 이 인스턴스에 기록할 수 있어요.
쓰기 접근 확인: Prometheus 호환 백엔드가 remote write를 지원해야 해요. Grafana Cloud Metrics(Mimir)와 셀프 관리 Mimir는 이를 네이티브 지원해요. 표준 Prometheus는 --web.enable-remote-write-receiver 플래그가 필요해요(Prometheus 2.33+).
기록 규칙 만들기:
1. Alerting > Alert rules로 이동해요.
2. New alert rule을 클릭해요.
3. 규칙 유형으로 Recording rule을 선택해요(Grafana-managed 섹션 아래).
4. 미리 계산할 PromQL 표현식을 입력해요:

      sum(rate(http_requests_total[$__rate_interval])) by (service)

결과의 메트릭 이름을 입력해요(예: service:http_requests:rate5m). Prometheus 기록 규칙 명명 규칙을 따라요: level:metric:operations.
결과가 기록될 Prometheus 인스턴스인 Target data source를 선택해요.
평가 간격을 설정해요(예: 매 1분).
Save rule을 클릭해요.
기록된 지표 질의: 첫 평가 후 새 메트릭을 대시보드와 알림에 사용할 수 있어요.

       service:http_requests:rate5m{service="api"}

PDC와 기록 규칙

Prometheus 인스턴스가 Private data source connect (PDC) 뒤에 있다면 Grafana가 PDC 터널을 통해 기록 규칙 결과를 기록할 수 있어요. PDC가 읽기와 쓰기를 모두 지원하므로 추가 구성이 필요 없어요.

제한 사항

기록 규칙은 대상 데이터 소스가 remote write를 지원해야 해요. 표준 Prometheus는 --web.enable-remote-write-receiver 플래그가 필요해요.
Thanos는 기록 대상을 기록 규칙으로 지원하지 않아요(Prometheus 유형 비교 참고).
기록 규칙 평가는 대시보드 시간 범위가 아닌 구성된 평가 간격을 사용해요. $__rate_interval 대신 고정 범위 벡터(예: [5m])를 사용해요.

자세한 내용은 Create Grafana-managed recording rules를 참고하세요.

제한 사항

Grafana Alerting과 함께 Prometheus를 사용할 때 다음 제한 사항을 알아두세요.

템플릿 변수 미지원

알림 쿼리는 템플릿 변수를 지원하지 않아요. Grafana는 대시보드 컨텍스트 없이 백엔드에서 알림 규칙을 평가하므로 $instance나 $job 같은 변수는 해석되지 않아요. 대시보드 쿼리가 템플릿 변수를 사용한다면 하드코딩된 값으로 알림용 별도 쿼리를 만들거나 라벨 매처를 직접 사용해요.

쿼리 복잡성

중첩 함수가 많거나 결과 집합이 큰 복잡한 쿼리는 타임아웃되거나 평가에 실패할 수 있어요. 알림용 쿼리를 다음으로 단순화해요.

범위 벡터에 사용되는 시간 범위 줄이기
반환된 시리즈 수를 제한하는 적절한 집계 사용
스캔되는 데이터를 좁히는 라벨 필터 추가
비용이 큰 표현식을 미리 계산하는 기록 규칙 사용

Explore와 Alerting의 OAuth 토큰 처리 차이

OAuth 인증 Prometheus 엔드포인트(Google Managed Prometheus, Azure Managed Prometheus)를 사용할 때 쿼리는 Explore와 대시보드에서 성공하지만 알림 평가 중에는 간헐적으로 실패할 수 있어요. 이는 알림 백엔드가 토큰 갱신을 대화형 쿼리 경로와 다르게 처리하기 때문이에요.

GCP를 사용한다면 OAuth 토큰을 갱신하고 토큰 수명보다 짧은 스케줄로 데이터 소스 자격 증명을 업데이트하는 사이드카 프로세스인 datasource-syncer 패턴을 고려해요. 자세한 문제 해결 단계는 OAuth token expiration errors를 참고하세요.

데이터 소스 관리형 규칙은 읽기 전용

Grafana는 Prometheus 알림 규칙을 표시할 수 있지만 UI를 통해 만들거나 수정할 수 없어요. Prometheus 네이티브 알림 규칙을 관리하려면 Prometheus 규칙 파일을 직접 편집하고 구성을 다시 로드해요.

실행 오류에 대한 알림 상태 구성

기본적으로 Grafana-managed 알림 규칙이 실행 오류나 타임아웃(네트워크 장애, i/o 타임아웃, Prometheus의 일시적 502 등)을 만나면 규칙이 Error 상태에 들어가 알림이 발화해요. 이는 근본 원인이 진짜 임계값 위반이 아니라 짧은 연결 중단일 때 오탐을 일으키고 온콜 팀에 스팸을 보낼 수 있어요.

일시적 오류로 인한 오탐을 막으려면 각 알림 규칙에서 Alert state if execution error or timeout 설정을 구성해요.

알림 규칙을 열어 편집해요.
알림 조건 섹션에서 Alert state if execution error or timeout을 찾아요.
값을 Alerting(기본값)에서 다음 중 하나로 바꿔요.
- Keep Last State: 성공적인 평가가 발생할 때까지 알림이 이전 상태(발화 또는 정상)를 유지해요. 대부분의 Prometheus 알림 규칙에 권장되는 설정이에요.
- OK: 오류 중 알림이 정상으로 설정되어 발화를 방지해요.
Save rule을 클릭해요.

참고: 알림 규칙이 자주 오류 상태에 들어간다면 이 설정으로 알림만 억제하지 말고 근본 원인(네트워크 안정성, Prometheus 리소스 한계, 쿼리 타임아웃 설정)을 조사하세요.

이 동작을 트리거하는 일반적인 일시적 오류는 다음을 포함해요.

알림 상태 이력의 sse.dependencyError 또는 sse.dataQueryError
"context deadline exceeded" 또는 "i/o timeout" 메시지
Prometheus 서버의 HTTP 502 또는 500 응답

이 오류 문제 해결에 대한 자세한 내용은 Troubleshoot Prometheus data source issues를 참고하세요.

모범 사례

Prometheus 알림을 만들 때 다음 모범 사례를 따르세요.

오류 상태 처리 구성: Alert state if execution error or timeout을 Keep Last State로 설정해 일시적 백엔드 오류가 오탐을 트리거하지 않게 해요.
$__rate_interval 사용: 알림 쿼리에서 rate()나 increase()를 쓸 때 $__rate_interval을 사용해 범위 창이 항상 스크래이프 간격에 비해 충분히 크게 해요. Grafana는 평가 간격과 스크래이프 간격 구성에 따라 이 변수를 해석해요.
라벨 필터 추가: 관련 데이터에 집중하고 쿼리 성능을 높이는 특정 라벨 매처를 포함해요.
현실적인 대기 기간 설정: 잠깐의 급증에 알림을 보내지 않도록 대기 기간을 사용해요. 예를 들어 5분 대기 기간을 설정해 발화 전에 조건이 지속되어야 해요.
먼저 쿼리 테스트: 알림을 만들기 전에 Explore에서 쿼리가 예상 결과를 반환하는지 확인해요.
의미 있는 이름 사용: 무엇을 모니터링하고 심각도가 어떤지 나타내는 설명적인 이름을 알림 규칙에 붙여요.
기록 규칙으로 사전 집계: 복잡하거나 자주 평가되는 표현식에는 기록 규칙을 만들고 미리 집계된 지표에 대해 알림을 보내요.
가용성 모니터링에 absent() 사용: 지표가 보고를 멈추는 것을 감지해요. 이는 종종 충돌하거나 응답하지 않는 서비스를 나타내요.

알림 규칙을 만들거나 평가할 때 오류가 발생하면 Troubleshoot Prometheus data source issues를 참고하세요.

더 알아보기 (Learn more)

Grafana Alerting - 알림 개요
Create a Grafana-managed alert rule - 알림 규칙 생성
Create Grafana-managed recording rules - 기록 규칙
Prometheus query editor - 쿼리 편집기
Prometheus alerting - 원문 문서