estudy 한국어/English

Alertmanger 역할

1,488 단어·3 분·원문(.md)

Alertmanager는 Prometheus 모니터링 생태계의 핵심 컴포넌트중 하나로 prometheus 서버가 수집한 메트릭을 바탕으로 생성한

alert 경고를 확인하고 적절한 수신자에게 전달하는 역할을 한다.

쉽게 말해서 시스템에 문제가 생겼을때 누구에게 어떻게 얼마나 자주 알릴 것인가를 통제하는 중앙 우체국 같은 역할을 한다.

주요 흐름 #

  1. deduplication
    1. 고가용성을 위해 여러대의 prometheus를 운영할경우 동일한 문제에 대해 여러 서버가 동시에 같은 경고를 날릴수잇는데 이러면 noise가 심해지므로 alertmanager는 이렇나 중복 경고를 식별해 단일 알림으로 만든다.
  2. grouping
    1. 유사한 성격의 경고들을 묶어서 하나의 알림 메시지로 발송한다
    2. 대규모 장애시 수백개의 개별 알림이 쏟아지는 알림 폭탄을 방지해서 담당자가 핵심 문제를 빠르게 파악할 수 있게 돋는다.
  3. routing
    1. 경고에 부여된 라벨이나 심각도등의 조건에 따라 알림을 받을 수신자를 결정한다.
    2. slack, email, pagerduty, opsgenie, webhook etc...
  4. inhibition
    1. 억제라고 하는데, 특정 경고가 발생했을때 그와 연관된 하위/덜중요한 경고의 알림을 발송하지 않도록 차단한다. 전체 네트워크가 다운되었을때 개별 서버 접속 불가 알림을 억제
  5. silencing
    1. 정기 점검이나 이미 인지하고 있는 장애가 났을때 특정 조건(라벨 매칭)과 시간 동안 알림이 울리지 않도록 일시중지한다.

ex #

그룹화 예시

  • 상황: 클러스터 내의 데이터베이스 서버 1대가 다운되어 해당 db를 바라보는 50개의 웹서버 인스턴스가 동시에 에러 경고를 발생
  • Alertmanger가 50개의 개별 알림을 보내는 대신에 cluster=db-tier or alertname=DatabaseConectionFailed 등의 라벨을 기준으로 그룹화하여 웹서버 50대에서 db 연결 오류 발생이라는 1개의 요약된 알림을 slack으로 보낸다

라벨에 따른 라우팅 (수신자 분리) 예시

  • 상황: 시스템에서 다양한 심각도 severity의 경고가 발생했다.
  • alertmanager의 동작은
    • severity=warning: 디스크 사용량 80% 도달같은 개발팀의 slack 채널로만 조용히 메시지를 보냄
    • severity=critical: 메인서버 다운등과 같은 상황이면 담당자의 pagerduty, 문자메시지를 울려 새벽에 깨워서 일시킨다. 메일로 상세내역 전송도
    • team=frontend: 프론트엔드 팀 채널로 전달한다
    • team=database: dba 채널로 전달 ㅇㅇ

억제 예시

  • 상황: IDC에 특정 랙에 전원 공급이 끊겨 해당 랙에 있느 20대의 서버가 모두 다운이 되었다.
  • Alertmanager는 이때 랙 전체 다운을 알리는 경고 RackDown을 발생시켰다치고 그 랙안에있는 개별서버가 죽었다는 20개의 하위 경고 InstanceDown은 발생시키지 않는다. 근본적으로 랙 다운에만 집중시킬 수 있음.
global:
  # 알림이 해결(Resolved)된 것으로 간주하기까지의 시간
  resolve_timeout: 5m

# 1. 라우팅 및 그룹화 (Routing & Grouping)
route:
  # 조건에 맞지 않는 알림이 갈 기본 수신자
  receiver: 'default-slack'
  
  # 그룹화 기준: 알림 이름(alertname)과 클러스터(cluster)가 같으면 하나로 묶음 (알림 폭탄 방지)
  group_by: ['alertname', 'cluster']
  
  # 그룹화 타이머 설정
  group_wait: 30s      # 첫 알림이 발생한 후, 같은 그룹의 알림을 더 기다려보는 시간
  group_interval: 5m   # 새 알림이 추가되었을 때, 갱신된 그룹 알림을 보내기 전 기다리는 시간
  repeat_interval: 4h  # 문제가 해결되지 않았을 때, 똑같은 알림을 다시 보내는 주기

  # 하위 라우팅 규칙 (조건에 따라 다른 수신자에게 전달)
  routes:
    # 조건 A: 프론트엔드 팀 소관인 경우
    - matchers:
        - team="frontend"
      receiver: 'frontend-slack'

    # 조건 B: 심각도가 critical인 경우 (새벽에도 깨워야 함)
    - matchers:
        - severity="critical"
      receiver: 'pagerduty-critical'

# 2. 억제 규칙 (Inhibition)
inhibit_rules:
  # RackDown(랙 다운) 알림이 발생하면, 그 랙 안에 있는 InstanceDown(서버 다운) 알림은 무시
  - source_matchers:
      - alertname="RackDown"
    target_matchers:
      - alertname="InstanceDown"
    # 소스(RackDown)와 타겟(InstanceDown)의 'rack' 라벨 값이 같을 때만 억제 동작
    equal: ['rack']

# 3. 수신자 설정 (Receivers)
receivers:
  # 기본 슬랙 채널
  - name: 'default-slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
        channel: '#general-alerts'

  # 프론트엔드 팀 슬랙 채널
  - name: 'frontend-slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
        channel: '#frontend-alerts'
        title: '{{ .GroupLabels.alertname }} 경고 발생!'
        text: '클러스터: {{ .GroupLabels.cluster }} 에서 프론트엔드 이슈가 발생했습니다.'

  # PagerDuty (담당자에게 전화/문자 발송)
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - service_key: 'YOUR_PAGERDUTY_INTEGRATION_KEY'
        description: '긴급! {{ .GroupLabels.alertname }} 발생'
SRE/question/q_27.md