고가용성 구성

고가용성 구성 (Configure high availability)

Grafana Alerting은 알림 규칙의 평가와 알림 전달을 분리하는 Prometheus 모델을 사용해요. Grafana Alerting에서 알림 생성자는 Scheduler이고 수신자는 Alertmanager예요. 여러 Grafana 인스턴스를 실행하면 기본적으로 모든 알림 규칙이 모든 인스턴스에서 평가되며, 이는 중복 평가를 통해 최소 하나의 인스턴스가 작동하는 한 알림이 계속 동작하도록 보장해요.

출처: Configure high availability

본문

고가용성 (High availability)

여러 Grafana 인스턴스를 실행할 때 모든 알림 규칙이 기본적으로 모든 인스턴스에서 평가돼요. 알림 규칙의 평가는 실행 중인 Grafana 인스턴스 수만큼 중복된다고 생각하면 돼요. 이는 최소 하나의 Grafana 인스턴스가 작동하는 한 알림 규칙이 계속 평가되고 알림이 계속 전송되도록 보장해요.

이 중복을 줄이려면 single-node evaluation mode(단일 노드 평가 모드)를 활성화해 하나의 인스턴스만 알림 규칙을 평가하게 할 수 있어요. state history에서 이 중복을 찾을 수 있으며, 고가용성 설정을 검증하는 좋은 방법이에요.

알림 생성자가 모든 인스턴스에서 모든 알림 규칙을 평가하는 동안, 알림 수신자는 중복 알림을 피하려고 최선을 다해요. Alertmanager는 gossip 프로토콜로 정보를 공유해 중복 알림 전송을 방지해요. Alertmanager는 일관성보다 가용성을 선택하므로 가끔 중복되거나 순서가 어긋난 알림이 발생할 수 있어요. 중복이나 순서 어긋남이 알림이 아예 없는 것보다 낫다는 관점을 취해요. Alertmanager는 또한 silence를 gossip하는데, 즉 한 인스턴스에서 만든 silence가 다른 모든 인스턴스에 복제돼요. 알림과 silence는 주기적으로 그리고 정상 종료 시 데이터베이스에 저장돼요.

Memberlist를 사용한 경고 고가용성 활성화

시작하기 전에: 알림과 silence의 gossip은 TCP와 UDP 포트 9094를 모두 사용하므로, 각 Grafana 인스턴스가 이 포트에서 인바운드 연결을 수락할 수 있는지 확인해요.

고가용성 지원을 활성화하려면 커스텀 구성 파일($WORKING_DIR/conf/custom.ini)에서 [unified_alerting] 섹션으로 이동해요.

• [ha_peers]를 클러스터의 각 Grafana 인스턴스 호스트 수로 설정해요(host:port 형식). 예: ha_peers=10.0.0.5:9094,10.0.0.6:9094,10.0.0.7:9094. ha_peers에 최소 하나의 Grafana 인스턴스를 추가해야 해요.
• [ha_listen_address]를 인스턴스 IP 주소(host:port 형식, Kubernetes면 Pod IP)로 설정해요. 기본값은 모든 인터페이스(0.0.0.0)에서 수신 대기해요.
• [ha_advertise_address]를 인스턴스의 hostname 또는 IP 주소(host:port)로 설정해요. 이 설정은 NAT 뒤(예: Docker Swarm, Kubernetes 서비스)에 있는 인스턴스에서 외부 주소와 내부 주소가 다를 때 사용해요. 선택 사항.
• [ha_peer_timeout]을 [unified_alerting] 섹션에 설정해 인스턴스가 Alertmanager를 통해 알림을 보낼 때까지 기다릴 시간을 지정해요. 기본값은 15s이며, Grafana 서버가 다른 지리적 지역에 있거나 네트워크 지연이 높으면 늘릴 수 있어요.

Redis를 사용한 경고 고가용성 활성화

Memberlist의 대안으로 Redis를 구성해 고가용성을 활성화할 수 있어요. Redis standalone, Redis Cluster, Redis Sentinel 모드를 지원해요.

참고: Memberlist가 고가용성의 선호 옵션이에요. Redis는 Grafana 서버 간 직접 통신이 불가능한 환경(TCP/UDP 포트가 차단된 경우)에서만 사용해요.

pub/sub을 지원하는 Redis 서버가 있는지 확인해요. Redis 클러스터 앞에 프록시를 쓴다면 프록시가 pub/sub을 지원하는지 확인해요. 커스텀 구성 파일의 [unified_alerting] 섹션에서:

• ha_redis_address를 Grafana가 연결할 Redis 서버 주소로 설정해요. Redis standalone이면 단일 주소, Redis Cluster나 Sentinel이면 콤마 구분 주소 목록.
• (선택) Redis Cluster 사용 시 ha_redis_cluster_mode_enabled를 true로 설정.
• (선택) Redis Sentinel 사용 시 ha_redis_sentinel_mode_enabled를 true로, ha_redis_sentinel_master_name을 Sentinel 마스터 이름으로 설정.
• (선택) Redis 서버에 인증이 활성화되어 있으면 ha_redis_username과 ha_redis_password 설정.
• (선택) Redis Sentinel에 인증이 활성화되어 있으면 ha_redis_sentinel_username과 ha_redis_sentinel_password 설정.
• (선택) Redis 서버를 여러 Grafana 인스턴스와 공유할 계획이면 ha_redis_prefix를 고유 값으로 설정.
• (선택) Grafana와 Redis 사이 통신을 TLS로 보호하려면 ha_redis_tls_enabled를 true로, 관련 ha_redis_tls_* 필드를 구성.
• [ha_advertise_address]를 ha_advertise_address = "${POD_IP}:9094"로 설정. 인스턴스가 RFC 6890의 일부인 IP 주소가 기본 경로로 없으면 필수.

Kubernetes를 사용한 경고 고가용성 활성화

컨테이너 정의를 통해 환경 변수로 Pod IP를 노출할 수 있어요.

env:
  - name: POD_IP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP

Grafana 배포에 포트 9094를 추가해요.

ports:
  - name: grafana
    containerPort: 3000
    protocol: TCP
  - name: gossip-tcp
    containerPort: 9094
    protocol: TCP
  - name: gossip-udp
    containerPort: 9094
    protocol: UDP

환경 변수를 Grafana 배포에 추가해요.

env:
  - name: POD_IP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP

ha_peers가 필요로 하는 서비스 IP 대신 Pod IP를 반환하는 headless 서비스를 만들어요.

apiVersion: v1
kind: Service
metadata:
  name: grafana-alerting
  namespace: grafana
  labels:
    app.kubernetes.io/name: grafana-alerting
    app.kubernetes.io/part-of: grafana
spec:
  type: ClusterIP
  clusterIP: 'None'
  ports:
    - port: 9094
  selector:
    app: grafana

Grafana 배포에 셀렉터와 일치하는 라벨(예: app:grafana)이 있는지 확인하고, grafana.ini에 다음을 추가해요.

[unified_alerting]
enabled = true
ha_listen_address = "${POD_IP}:9094"
ha_peers = "grafana-alerting.grafana:9094"
ha_advertise_address = "${POD_IP}:9094"
ha_peer_timeout = 15s
ha_reconnect_timeout = 2m

단일 노드 평가 모드 (Single-node evaluation mode)

참고: 단일 노드 평가 모드는 현재 공개 미리보기 상태예요. Grafana Labs가 제한적 지원을 제공하며, 일반 제공 전에 호환성 변경이 있을 수 있어요.

기본적으로 고가용성 클러스터의 모든 Grafana 인스턴스가 모든 알림 규칙을 평가해요. 이는 데이터 소스의 쿼리 로드가 Grafana 인스턴스 수만큼 곱해진다는 뜻이에요. 단일 노드 평가 모드는 하나의 인스턴스만 알림 규칙을 평가하도록 바꿔 쿼리 로드를 N배에서 1배로 줄여요.

[unified_alerting]
ha_single_node_evaluation = true

이 설정은 고가용성 클러스터링(Memberlist 또는 Redis)이 구성되어 있어야 해요.

동작 방식: Grafana 클러스터가 자동으로 모든 알림 규칙을 평가할 책임이 있는 기본(primary) 인스턴스를 선택해요. 다른 인스턴스는 평가를 건너뛰어요.

• 알림 브로드캐스팅: 기본 인스턴스는 발화된 알림을 클러스터 통신 채널을 통해 다른 모든 인스턴스로 브로드캐스트해요. 이는 각 인스턴스의 임베디드 Alertmanager가 현재 알림을 가지도록 보장하며, 장애 복구와 Alertmanager API가 모든 인스턴스에서 올바른 데이터를 반환하는 데 필요해요.
• 자동 장애 복구: 기본 인스턴스를 사용할 수 없게 되면 클러스터가 위치를 재할당하고 새 인스턴스가 평가를 담당해요. 장애 복구 중에는 짧은 평가 공백이 있어요. 기존 알림 상태는 데이터베이스에 남아요.

기본 HA(모든 인스턴스 평가)	단일 노드 평가 모드
모든 노드에서 중복 평가	단 하나의 노드만 평가
데이터 소스에 높은 쿼리 로드(N배)	쿼리 로드 감소(1배)
인스턴스 장애 시 평가 공백 없음	장애 복구 중 짧은 평가 공백

단일 노드 평가 모드 모니터링:

메트릭	설명
grafana_alertmanager_peer_position	클러스터에서 각 인스턴스의 위치. 위치 0 인스턴스가 primary이며 모든 알림 규칙을 평가.
grafana_alerting_alerts_received_total	각 인스턴스가 받은 알림 총 수. 비-primary 인스턴스는 클러스터 브로드캐스트 채널을 통해 받아야 함.
grafana_alerting_alertmanager_alerts{state="active"}	각 인스턴스의 활성 알림 수. 모든 인스턴스에서 동일해야 함.

HA 백엔드(Memberlist/Redis)별 메트릭은 원문 문서를 참고하세요.

알림 브로드캐스트 큐 크기 조정 (Tune alert broadcast queue size):

기본 인스턴스는 알림을 다른 인스턴스로 브로드캐스트하는 데 메시지 큐를 사용해요. 기본적으로 큐는 최대 200개 메시지를 보유해요. 알림 규칙이 많으면 큐가 채워져 메시지가 드롭될 수 있어요. 큐 크기를 늘리려면 [unified_alerting] 섹션에 다음을 추가해요.

[unified_alerting]
ha_single_evaluation_alert_broadcast_queue_size = 500

기본값은 200이며, 이 설정은 Memberlist와 Redis HA 백엔드 모두에 적용돼요.

고가용성 설정 검증 (Verify your high availability setup)

여러 Grafana 인스턴스를 실행하면 기본적으로 모든 알림 규칙이 매 인스턴스에서 평가돼요. 이 중복 평가는 state history에서 볼 수 있으며, 고가용성 구성이 올바르게 작동하는지 확인하는 간단한 방법이에요.

참고: HA 노드에서 execute_alerts=false와 execute_alerts=true를 섞어 쓴다면 알림 상태가 인스턴스 간 공유되지 않으므로, execute_alerts=false 인스턴스는 알림 상태를 표시하지 않아요. HA 설정(ha_peers 등)은 서론에 설명한 대로 alertmanager 간 통신, silence 동기화, 중복 알림 회피에만 적용돼요.

Grafana가 노출하는 Alertmanager 메트릭을 모니터링해 고가용성 설정을 확인할 수도 있어요. Grafana v12.4부터 이 메트릭들은 grafana_ 접두사를 사용해요(예: grafana_alertmanager_cluster_members). 주요 메트릭:

• grafana_alertmanager_cluster_members: 클러스터의 현재 구성원 수.
• grafana_alertmanager_cluster_messages_received_total: 받은 클러스터 메시지 총 수.
• grafana_alertmanager_cluster_messages_sent_total: 보낸 클러스터 메시지 총 수.
• grafana_alertmanager_cluster_messages_publish_failures_total: 게시에 실패한 메시지 수.
• grafana_alertmanager_cluster_pings_seconds: ping 메시지의 대기 시간 히스토그램.
• grafana_alertmanager_cluster_pings_failures_total: 실패한 ping 수.
• grafana_alertmanager_peer_position: 인스턴스가 클러스터에서 차지한다고 믿는 위치(0부터 순차 번호).

이 메트릭들은 Grafana의 /metrics 엔드포인트로 노출되며 자동 수집·표시되지 않아요. Prometheus 인스턴스가 연결되어 있다면 Grafana 메트릭을 스크랩하는 scrape_config를 추가하고 Explore에서 쿼리하세요.

- job_name: grafana
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  static_configs:
    - targets:
        - grafana:3000

중복 알림 방지 (Prevent duplicate notifications)

고가용성 모드에서 각 Grafana 인스턴스는 알림을 처리하는 자체 사전 구성 alertmanager를 실행해요. 여러 Grafana 인스턴스가 실행되면 모든 알림 규칙이 각 인스턴스에서 기본 평가되고, 각 인스턴스는 발화 알림을 자신의 Alertmanager로 보내요. 이로 인해 알림 처리가 모든 실행 인스턴스에서 중복돼요. HA 모드의 Alertmanager는 알림 전달을 조정하기 위해 서로 통신하지만, 이 설정은 가끔 중복되거나 순서가 어긋난 알림을 만들 수 있어요. 설계상 HA는 알림 누락 위험보다 중복 알림 전송을 우선해요.

중복 알림을 피하려면 모든 Grafana 인스턴스의 알림을 관리하는 공유 Alertmanager를 구성할 수 있어요. 자세한 내용은 외부 alertmanager 추가 문서를 참고하세요.

더 알아보기 (Learn more)

• Grafana Alerting
• Alertmanager 구성
• 알림 고가용성 예시 (Docker Compose)
• Alerting 메타 모니터링
• 고가용성 Grafana