Grafana Alerting 성능 고려 사항 및 제한
Grafana Alerting 성능 고려 사항 및 제한 (Performance considerations and limitations)
Grafana Alerting은 다차원 알림(multi-dimensional alerting)을 지원해서, 하나의 알림 규칙으로 수많은 알림을 만들 수 있어요. 이 페이지는 그런 다차원 알림이 야기하는 성능 고려 사항과 함께, 규칙 소스·Prometheus 버전·데이터베이스 부하 등 알림 시스템 운영 시 알아둬야 할 제한 사항을 다뤄요.
출처: 문서
본문
알림 규칙을 평가(evaluate)하면 알림 쿼리 계산에 RAM과 CPU를 쓰고, 알림을 보내고 결과를 Grafana SQL 데이터베이스에 기록하는 데 네트워크 리소스를 사용해요. 규칙마다 설정이 다르므로 리소스 소비량이 달라지고, 따라서 특정 구성이 지원할 수 있는 최대 규칙 수도 달라져요.
성능 고려 사항은 다음과 같아요:
- 규칙 평가 빈도: 알림 규칙의 "Evaluate Every" 속성이 평가 빈도를 결정해요. 더 많은 규칙을 동시에 지원하려면 가장 낮은 허용 평가 빈도를 쓰는 것이 좋아요.
- 결과 집합의 카디널리티(cardinality): 예를 들어 모든 가상 머신의 모든 API 경로에 대한 응답 오류를 모니터링한다면, 그 집합의 카디널리티는 '경로 수 n × VM 수 v'가 돼요. 경로별이 아니라 VM별 오류로 줄이는 식으로 카디널리티를 낮출 수 있어요.
- 알림 쿼리 복잡도: 데이터 소스가 빠르게 처리·응답할 수 있는 쿼리일수록 리소스를 적게 써요. 앞선 항목들을 최대한 줄였다면 개별 쿼리 성능도 차이를 만들 수 있어요.
알림 규칙을 평가할 때마다 결과 집합의 각 멤버에 대해 하나씩, 즉 알림 인스턴스 집합이 생성돼요. 모든 인스턴스의 상태는 Grafana SQL 데이터베이스의 alert_instance 테이블에 기록되는데, 이 쓰기 중심 작업이 SQLite를 쓸 때 문제를 일으킬 수 있어요.
Grafana Alerting은 알림 규칙 평가 횟수를 세는 grafana_alerting_rule_evaluations_total 메트릭을 노출해요. 평가가 인스턴스에 미치는 영향을 확인하려면 평가 비율을 리소스 소비와 비교해 보면 돼요:
rate(grafana_alerting_rule_evaluations_total[5m])
이 요소들은 모두 Grafana 인스턴스의 부하에 영향을 주지만, 데이터 소스에 미치는 영향도 염두에 둬야 해요. 모니터링 데이터베이스가 처리하는 쿼리 대부분이 알림 쿼리인 경우가 많아서, 같은 부하 요인이 데이터 소스에도 적용돼요.
규칙 소스 지원 제한 (Limited rule sources support)
Grafana Alerting은 대부분의 Prometheus, Loki, Mimir, Alertmanager 호환 데이터 소스에 저장된 알림·레코딩 규칙을 가져올 수 있어요. 이 외 다른 데이터 소스에서는 현재 알림 규칙을 읽거나 쓸 수 없어요.
Prometheus 버전 지원
Prometheus와 Alertmanager의 최신 두 개의 마이너 버전을 지원해요. 그보다 오래된 버전은 동작을 보장할 수 없어요. 예를 들어 현재 Prometheus 버전이 2.31.1이라면 >= 2.29.0을 지원해요.
Grafana Alertmanager는 Grafana 관리형 알림만 받을 수 있어요
Grafana로 외부 알림을 받을 수는 없어요. Grafana 관리형 알림(Grafana managed alerts)을 통해서만 Grafana Alertmanager로 알림을 보낼 수 있어요. 반대로 Grafana 관리형 알림을 외부 Alertmanager로 보내는 옵션도 있는데, Alerting 페이지의 Admin 탭에서 찾을 수 있어요.
많은 알림 인스턴스로 인한 데이터베이스 부하
알림 규칙이나 인스턴스가 많으면 데이터베이스 부하가 매우 높아질 수 있어요. Grafana는 각 평가 후 알림 규칙마다 SQL 업데이트를 한 번 수행하는데, 이 업데이트는 규칙에 속한 모든 알림 인스턴스를 하나로 묶어 단일 protobuf 기반 행으로 압축해서, 인스턴스가 많은 규칙에서도 데이터베이스 오버헤드를 낮게 유지해요.
Warning 이전 Grafana 버전은 알림 인스턴스 상태를 압축하지 않고 인스턴스당 한 행씩 기록했고,
alertingSaveStateCompressed피처 토글로 압축 저장을 선택했어요. Grafana 13.2는 그 피처 토글과 압축되지 않은 저장 경로를 완전히 제거해요. 만약alertingSaveStateCompressed를 명시적으로 비활성화한 Grafana 버전에서 업그레이드한다면, 13.2 이상으로 업그레이드하기 전에 토글을 켜고 최소 한 번의 평가 주기(Grafana 13.2 기준 읽히지 않으므로) 동안 실행하세요. 그렇지 않으면 업그레이드 후에도 이전 압축 안 된 형식으로 남아 있는 알림 상태를 읽지 못해요. 이로 인해 알림 상태 자체 외의 데이터 손실은 없어요 — Grafana가 모든 규칙을 재평가하고 인스턴스 상태를 처음부터 다시 만들지만, 업그레이드 직후 알림 이력과 현재 상태에 일시적인 공백이 생길 수 있어요.
주기적으로 상태 저장 (Save state periodically)
모든 평가 후가 아니라 주기적으로 상태를 기록해 데이터베이스 부하를 줄일 수도 있어요. alertingSaveStatePeriodic 피처 토글을 켜면 state_periodic_save_interval이 지정한 간격으로 알림 상태를 저장해요. Grafana는 모든 알림 인스턴스를 규칙 UID별로 묶어 압축해 효율적으로 저장해요. 기본적으로 상태는 5분마다 그리고 종료 시에 저장돼요. state_periodic_save_batch_size와 state_periodic_save_jitter_enabled는 배치 단위가 아니라 규칙 UID로 묶으므로 여기선 적용되지 않아요.
[unified_alerting]
state_periodic_save_interval = 1m
만약 Grafana가 크래시하거나 강제 종료되면, 데이터베이스는 최대 state_periodic_save_interval만큼 오래된 상태일 수 있어요. 재시작 시 일부 알림이 재평가되기 전까지 UI에 잘못된 상태가 표시될 수 있고, 크래시 전에 발화 중이던 알림이 다시 발생할 수 있어요. 그 경우 발화 알림에 대한 중복 알림이 전송될 수 있어요.
알림 규칙당 결과 수 제한
각 평가는 규칙 쿼리 결과 집합의 시리즈마다 알림 인스턴스 하나를 생성해요. 카디널리티가 높은 규칙은 더 많은 CPU, 메모리, 네트워크, 데이터베이스 자원을 소비해요. 이를 방지하기 위해 Grafana는 단일 알림 규칙이 한 번의 평가에서 생성하는 쿼리 평가 결과 수를 제한할 수 있어요. 한도를 초과하면 평가가 다음 같은 오류로 실패해요:
query evaluation returned too many results: 12345 (limit: 10000)
규칙은 Error 상태가 되고, 결과 집합을 한도 아래로 줄이기 전까지 그 평가 동안 알림 인스턴스를 생성하지 않아요. 셀프 매니지드 Grafana에서는 [quota] 섹션의 alerting_rule_evaluation_results 옵션으로 이 한도를 설정해요. 기본값은 -1(제한 없음)이에요. Grafana Cloud에서는 Grafana Labs가 이 한도를 관리해요.
오류를 해결하려면 규칙 결과 집합의 카디널리티를 줄여요:
- 더 적은 시리즈를 반환하도록 쿼리를 집계해요(예: 더 적은 라벨로 sum/average).
- 알림이 필요한 시리즈만 반환하도록 라벨 필터를 추가해요.
- 카디널리티가 높은 규칙 하나를 더 좁은 쿼리를 가진 여러 규칙으로 나눠요.
Grafana 11.6.0 알림 규칙 마이그레이션
Grafana 11.6.0으로 업그레이드하면 alert_rule_versions 테이블에 마이그레이션이 수행돼요. 11.6.0 업그레이드에서 마이그레이션 실패가 발생한다면 alert_rule_versions 테이블에 행이 너무 많은 것이에요. 마이그레이션을 완료하려면 alert_rule_versions 테이블을 truncate 해야 해요.