Grafana SLO로 Fast-burn/Slow-burn 알림 자동화하기

운영 중인 서비스에서 CPU 80% 초과 알림이 일주일에 50회 발화되지만, 실제 장애로 이어진 건 그 중 단 2회뿐이었다면 어떨까요. 나머지 48회는 의미 없는 노이즈였고, on-call 담당자는 결국 중요한 2회에도 무감각해집니다. 단순 임계값 기반 알림의 본질적 한계가 바로 이것입니다. "지금 이 상황이 사용자에게 얼마나 영향을 미치고 있는가"라는 핵심 질문에는 답하지 못합니다.

이 문제를 해결하는 체계적 전략이 Google SRE 팀이 오랜 운영 경험을 정리한 SRE Workbook에 담긴 Multi-Window, Multi-Burn-Rate(MWMB) 알림 전략입니다. Prometheus 에러 버짓(Error Budget)이 소진되는 속도(번 레이트, Burn Rate)를 기준으로 Critical과 Warning 두 단계 알림을 구성하면, 노이즈는 줄이면서 실제 서비스 신뢰성 위협은 정확하게 잡아낼 수 있습니다.

이 가이드를 따라가면 기존 임계값 알림 대비 오탐률을 크게 낮춘 프로덕션급 SLO 알림 파이프라인을 완성할 수 있습니다. Grafana SLO 플러그인(grafana-slo-app)이 MWMB 알림 규칙을 자동으로 프로비저닝하는 원리부터, Alertmanager 라우팅으로 Fast-burn은 즉각 온콜 호출로, Slow-burn은 티켓 생성으로 분기하는 완성된 파이프라인까지 다룹니다. Grafana Cloud와 Self-hosted Prometheus 환경 모두를 커버합니다.

이 글을 읽기 전 알면 좋은 사전 지식: Prometheus 기본 개념(메트릭 수집, PromQL), YAML 문법. Kubernetes 예시에는 kubectl 기본 사용법과 CRD 개념도 도움이 됩니다.

핵심 개념

개념이 이미 익숙하다면 바로 '실전 적용' 섹션으로 이동해도 좋습니다.

SLI, SLO, 에러 버짓, 그리고 Burn Rate

세 가지 개념의 관계를 먼저 잡아두면 이후 내용이 훨씬 명확해집니다.

SLI(Service Level Indicator): 서비스 신뢰성을 측정하는 지표. 예: "전체 요청 중 성공 응답(2xx)의 비율"
SLO(Service Level Objective): SLI에 대한 목표치. 예: "월간 요청의 99.9%는 성공해야 한다"
에러 버짓(Error Budget): SLO 달성 범위 내에서 허용되는 오류의 총량

99.9% SLO를 가진 서비스라면 한 달(약 720시간) 동안 허용되는 에러 비율은 0.1%입니다. 이 여유분 전체가 에러 버짓이며, Burn Rate는 이 버짓이 소진되는 속도를 나타냅니다.

Burn Rate 계산 예시

99.9% SLO 기준, 월간 에러 버짓 = 720시간 × 0.1% = 약 43.2분

Burn Rate 소진 예상 시간 계산 의미

1× 30일 ÷ 1 = 30일 정상 소진 속도

14.4× 30일 ÷ 14.4 ≈ 2.1일(약 50시간) 즉각 대응 필요

6× 30일 ÷ 6 = 5일 당일 대응 필요

3× 30일 ÷ 3 = 10일 티켓 발행으로 대응

자신의 SLO 목표치에 맞는 임계값을 조정할 때 소진 예상 시간 = 30일 ÷ Burn Rate 공식을 활용하면 됩니다. Google 기본값(14.4×, 6×, 3×, 1×)은 99.9% SLO 기준으로 설계된 값이므로, 99.0% SLO 서비스에는 그대로 적용할 수 없습니다.

Burn Rate	소진 예상 시간 계산	의미
1×	30일 ÷ 1 = 30일	정상 소진 속도
14.4×	30일 ÷ 14.4 ≈ 2.1일(약 50시간)	즉각 대응 필요
6×	30일 ÷ 6 = 5일	당일 대응 필요
3×	30일 ÷ 3 = 10일	티켓 발행으로 대응

Multi-Window, Multi-Burn-Rate(MWMB) 알림 전략

단일 창(window)으로 Burn Rate를 평가하면 두 가지 문제가 생깁니다. 짧은 창은 일시적 트래픽 스파이크에 오탐(false positive)이 많고, 긴 창은 탐지 자체가 너무 늦어집니다. MWMB 전략은 짧은 창 AND 긴 창 조건을 동시에 충족할 때만 알림을 발화해 두 문제를 모두 해결합니다.

Google SRE Workbook이 권장하는 임계값은 다음과 같습니다:

단계	Burn Rate	짧은 창	긴 창	소진 예상 시간	대응 방식
Critical (Fast-Burn)	≥ 14.4×	5분	1시간	~2일	즉각 온콜 호출
Critical (Fast-Burn)	≥ 6×	30분	6시간	~5일	즉각 온콜 호출
Warning (Slow-Burn)	≥ 3×	2시간	24시간	~10일	티켓 발행
Warning (Slow-Burn)	≥ 1×	6시간	72시간	~30일	티켓 발행

이중 창 검증의 효과: 5분 창만으로 평가하면 일시적 트래픽 폭증에도 알림이 발화됩니다. 5분 AND 1시간 조건을 함께 쓰면, 5분 동안 급격히 나빠졌고 그 추세가 1시간 동안 지속됐을 때만 알림이 울립니다.

Recording Rules(기록 규칙)

MWMB 전략은 5분, 30분, 1시간, 6시간, 24시간, 72시간 등 여러 시간 창에 걸친 SLI 쿼리를 반복 실행해야 합니다. 이 쿼리를 매번 실시간으로 계산하면 Prometheus에 상당한 부하가 걸립니다.

Recording Rules(기록 규칙) 는 이 문제를 해결하는 Prometheus 메커니즘입니다. 복잡한 쿼리를 미리 계산해 새로운 메트릭으로 저장해두면, 알림 평가 시 사전 집계된 결과를 재사용할 수 있어 평가 지연과 스토리지 부하를 동시에 줄여줍니다.

grafana-slo-app은 SLO 생성 시 이 Recording Rules도 함께 자동으로 프로비저닝합니다.

Alertmanager와 grafana-slo-app이 자동으로 만들어주는 것들

Alertmanager는 Prometheus에서 발화된 알림을 받아 중복 제거, 그룹화, 라우팅을 담당하는 컴포넌트입니다. 어떤 알림을 어느 채널(PagerDuty, Slack, 웹훅 등)로 보낼지 alertmanager.yml 설정 파일로 제어합니다.

grafana-slo-app은 Grafana 공식 플러그인으로, SLO를 UI에서 한 번 생성하면 다음 리소스를 모두 자동으로 프로비저닝합니다:

SLO 생성
  ├── 대시보드 (에러 버짓 번다운 차트 포함)
  ├── 기록 규칙 (Recording Rules) — 다중 창 SLI 쿼리 최적화
  └── 알림 규칙 (Alert Rules)
        ├── [Critical] fast-burn: grafana_slo_severity="critical"
        └── [Warning]  slow-burn: grafana_slo_severity="warning"

자동 생성된 알림에는 Alertmanager 라우팅에 바로 활용할 수 있는 레이블이 부착됩니다:

grafana_slo_uuid — SLO 고유 식별자
grafana_slo_window — 평가 창 (예: 5m, 1h)
grafana_slo_severity — critical 또는 warning

실전 적용

예시 1: Grafana Cloud — Alertmanager 이중 라우팅 구성

grafana-slo-app이 생성하는 알림 규칙이 실제로 어떤 형태인지 먼저 살펴보면, Alertmanager 라우팅 설정의 matchers가 어느 레이블을 기준으로 동작하는지 직접 확인할 수 있습니다.

yaml

# grafana-slo-app이 자동 생성하는 Alert Rule 예시 (단순화된 형태)
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: slo-api-gateway
spec:
  groups:
    - name: slo-api-gateway.rules
      rules:
        - alert: SLOFastBurn
          expr: |
            (
              slo:sli_error:ratio_rate5m{grafana_slo_uuid="<uuid>"}
              > (14.4 * (1 - 0.999))
            )
            and
            (
              slo:sli_error:ratio_rate1h{grafana_slo_uuid="<uuid>"}
              > (14.4 * (1 - 0.999))
            )
          labels:
            grafana_slo_severity: critical
            grafana_slo_uuid: "<uuid>"
          annotations:
            summary: "Fast-burn: SLO 에러 버짓이 빠르게 소진 중"

이 자동 생성 규칙의 grafana_slo_severity 레이블을 기준으로 Alertmanager 라우팅을 분기합니다.

yaml

# alertmanager.yml
route:
  receiver: 'default'
  routes:
    # Fast-Burn: 즉각 온콜 호출 (구체적인 matcher를 항상 상단에 배치)
    - matchers:
        - grafana_slo_severity = "critical"
      receiver: 'pagerduty-oncall'
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 1h
 
    # Slow-Burn: 티켓 생성
    - matchers:
        - grafana_slo_severity = "warning"
      receiver: 'jira-ticket'
      group_wait: 5m
      group_interval: 30m
      repeat_interval: 6h
 
receivers:
  - name: 'pagerduty-oncall'
    pagerduty_configs:
      - routing_key: '${PAGERDUTY_ROUTING_KEY}'   # 환경 변수 또는 Secret으로 주입
        description: '{{ .CommonAnnotations.summary }}'
        severity: 'critical'
 
  - name: 'jira-ticket'
    webhook_configs:
      - url: '${JIRA_AUTOMATION_WEBHOOK_URL}'      # Jira Automation 웹훅 URL
        send_resolved: true
 
  - name: 'default'
    slack_configs:
      - api_url: '${SLACK_WEBHOOK_URL}'
        channel: '#alerts'

민감 정보 주입 방법: routing_key 같은 인증 정보를 YAML에 직접 하드코딩하면 보안 사고로 이어질 수 있습니다. Grafana Cloud 환경에서는 Grafana Secrets Manager 또는 Kubernetes Secret을 활용하고, Self-hosted 환경에서는 ${ENV_VAR} 환경 변수 참조 방식을 사용하는 것을 권장합니다.

Grafana Cloud에서 alertmanager.yml 적용 방법: Grafana Cloud 좌측 메뉴 → Alerting → Alertmanager → Alertmanager configuration 탭에서 전체 YAML을 직접 붙여넣거나 UI의 Contact points / Notification policies로 구성할 수 있습니다. Terraform grafana_alertmanager_config 리소스를 통한 GitOps 방식도 지원됩니다.

Jira 웹훅 연동: Jira Automation의 "웹훅으로 규칙 트리거" 기능 또는 Atlassian Forge 앱을 통해 알림 수신 시 Jira 티켓을 자동 생성할 수 있습니다. 특정 환경에 종속되지 않는 범용 구성을 원한다면 webhook_configs에 자체 미들웨어 URL을 사용하는 방식도 유효합니다.

설정 항목	Fast-Burn 값	Slow-Burn 값	이유
`group_wait`	30초	5분	Critical은 집계 대기 최소화
`repeat_interval`	1시간	6시간	Warning 반복 알림 빈도 낮춤
`receiver`	PagerDuty	Jira 웹훅	중요도별 채널 분리

예시 2: Self-hosted 환경 — Sloth로 MWMB 규칙 생성

Grafana Cloud를 사용하지 않는 Self-hosted Prometheus 환경에서는 Sloth를 사용해 YAML로 SLO를 정의하고 MWMB 알림 규칙을 자동 생성할 수 있습니다.

yaml

# slo-api-gateway.yaml (Sloth 입력 파일)
version: "prometheus/v1"
service: "api-gateway"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "99.9% of requests should be successful"
    sli:
      events:
        # [{{.window}}]는 Sloth의 Go 템플릿 문법으로, 규칙 생성 시
        # 5m, 30m, 1h, 6h 등 각 평가 창 값으로 자동 치환됩니다.
        error_query: sum(rate(http_requests_total{job="api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="api"}[{{.window}}]))
    alerting:
      name: APIGatewayAvailability
      page_alert:
        labels:
          severity: critical
          team: platform
      ticket_alert:
        labels:
          severity: warning
          team: platform

위 파일을 Sloth CLI로 처리하면 Prometheus에 바로 적용 가능한 기록 규칙과 알림 규칙 YAML이 생성됩니다:

bash

# Sloth로 PrometheusRule 생성
sloth generate -i slo-api-gateway.yaml -o rules/api-gateway-slo.yaml
 
# Kubernetes 환경이라면 PrometheusRule CRD로 적용
kubectl apply -f rules/api-gateway-slo.yaml

Sloth가 생성한 알림 규칙에도 severity: critical / severity: warning 레이블이 포함되므로, Alertmanager 라우팅은 예시 1과 동일한 matchers 구조로 적용할 수 있습니다.

예시 3: 환경별 접근법 — Grafana-managed vs Data source-managed

알림 관리 모드 선택은 운영 환경과 GitOps 요구사항에 따라 달라집니다.

구분	Grafana-managed	Data source-managed
알림 저장 위치	Grafana 내부 DB	Prometheus/Mimir 직접 저장
Alertmanager	Grafana 내장 AM	외부 Prometheus AM
GitOps 적합성	API / Terraform	PrometheusRule CRD
추천 환경	Grafana Cloud	Self-hosted Kubernetes
전환 시 주의	—	Contact Point 재구성 필수

Data source-managed 모드로 전환할 경우, 아래 절차로 엔드투엔드 라우팅을 검증해보시면 좋습니다:

bash

# 외부 Alertmanager 설정 문법 검증
amtool check-config alertmanager.yml
 
# 테스트 알림 발화로 실제 라우팅 경로 확인
amtool alert add alertname="TestSLOAlert" grafana_slo_severity="critical" \
  --alertmanager.url=http://localhost:9093

Data source-managed 전환 시 주의: 기존 Grafana Alertmanager에 설정된 Notification Policy와 Contact Point는 외부 Alertmanager에 반드시 재구성해야 합니다. 이를 누락하면 SLO 알림이 발화돼도 아무도 통보받지 못하는 운영 공백이 생깁니다. 전환 직후 테스트 알림으로 전체 경로를 반드시 확인하는 것을 권장합니다.

장단점 분석

장점

항목	내용
알림 피로 감소	실제 에러 버짓 소진이 위협받는 상황에서만 발화되므로 노이즈가 크게 줄어듭니다
원클릭 자동화	grafana-slo-app은 SLO 생성 한 번으로 기록 규칙, 대시보드, 알림 규칙을 모두 프로비저닝합니다
오탐 억제	짧은 창 AND 긴 창 이중 검증으로 순간 스파이크에 의한 거짓 알림이 억제됩니다
대응 분리	Critical은 즉시 온콜 호출, Warning은 티켓으로 분리해 야간 불필요 호출을 방지합니다
SLO-as-Code	Terraform `grafana_slo` 리소스로 GitOps 파이프라인에 통합할 수 있습니다

단점 및 주의사항

항목	내용	대응 방안
Cloud 종속성	grafana-slo-app 전체 기능은 Grafana Cloud 전용	Self-hosted 환경에서는 Sloth + Prometheus 조합 활용
알림 지연	Slow-Burn은 최장 72시간 창을 사용해 탐지까지 수 시간 소요 가능	Fast-Burn 임계값을 낮춰 조기 탐지를 보완하는 방향으로 튜닝
임계값 튜닝	Google 기본값(14.4×, 6×, 3×, 1×)이 모든 서비스에 최적이 아님	`소진 예상 시간 = 30일 ÷ Burn Rate` 공식으로 SLO 목표치에 맞게 재산출
레이블 복잡성	다수 SLO 운영 시 `grafana_slo_uuid`, `team` 등 레이블과 라우팅 트리 정합성 유지 부담	레이블 명명 규칙을 팀 내 표준으로 문서화
AM 이중 관리	Grafana-managed에서 외부 AM 전환 시 Contact Point 동기화 운영 부담	전환 전 체크리스트 작성 후 스테이징 환경에서 검증

실무에서 가장 흔한 실수

Alertmanager 라우팅 순서 오류: routes 배열에서 grafana_slo_severity = "critical" 규칙이 catch-all 규칙보다 하위에 위치하면, Critical 알림이 PagerDuty 대신 기본 채널로 전달됩니다. 가장 구체적인 매처를 항상 배열 상단에 배치해야 합니다.
Data source-managed 전환 후 Contact Point 미재구성: 외부 Alertmanager로 전환했지만 Notification Policy를 옮기지 않아 SLO 알림이 발화돼도 아무도 통보받지 못하는 상황이 발생합니다. 전환 직후 테스트 알림으로 엔드투엔드 경로를 검증하는 것을 권장합니다.
Google 기본 임계값을 그대로 적용: 99.9% SLO 기준으로 설계된 기본값을 99.0% SLO 서비스에 그대로 적용하면 번 레이트 스케일이 달라져 알림이 너무 자주 또는 너무 늦게 발화됩니다. 소진 예상 시간 = 30일 ÷ Burn Rate 공식으로 자신의 SLO 목표치에 맞게 임계값을 재산출하는 것을 권장합니다.

마치며

MWMB 이중 알림 전략은 "임계값 초과"가 아닌 "에러 버짓 소진 속도"를 기준으로 삼아 알림 노이즈를 줄이면서 실제 서비스 신뢰성 위협을 더 정확하게 잡아냅니다. 알림 피로가 줄어들면 팀의 온콜 부담이 낮아지고, 에러 버짓이 가시화되면 신뢰성 개선 우선순위 논의가 느낌이 아닌 데이터 기반으로 바뀝니다.

지금 바로 시작해볼 수 있는 3단계:

SLO 정의: Grafana Cloud라면 grafana-slo-app에서 핵심 API 엔드포인트의 가용성 SLO(예: 99.9%)를 생성합니다. Self-hosted라면 sloth generate -i my-slo.yaml -o rules/my-slo.yaml로 MWMB 규칙 파일을 자동 생성할 수 있습니다.
Alertmanager 라우팅 적용: 예시 1의 alertmanager.yml을 참고해 grafana_slo_severity = "critical" → PagerDuty/IRM, grafana_slo_severity = "warning" → 웹훅 티켓으로 라우팅을 구성한 뒤 테스트 알림으로 엔드투엔드 경로를 검증합니다.
에러 버짓 대시보드 모니터링: 자동 생성된 번다운 차트를 팀 채널에 공유해 에러 버짓 잔량을 가시화하고, 월간 추세를 보며 임계값 튜닝 여부를 판단합니다.

다음 글: Terraform grafana_slo 리소스로 SLO를 코드로 관리하고 GitOps 파이프라인에 통합하는 SLO-as-Code 실전 가이드

참고 자료

DevOps

Grafana SLO로 Fast-burn/Slow-burn 알림 자동화하기

이 글을 읽기 전 알면 좋은 사전 지식: Prometheus 기본 개념(메트릭 수집, PromQL), YAML 문법. Kubernetes 예시에는 kubectl 기본 사용법과 CRD 개념도 도움이 됩니다.

핵심 개념

개념이 이미 익숙하다면 바로 '실전 적용' 섹션으로 이동해도 좋습니다.

SLI, SLO, 에러 버짓, 그리고 Burn Rate

세 가지 개념의 관계를 먼저 잡아두면 이후 내용이 훨씬 명확해집니다.

SLI(Service Level Indicator): 서비스 신뢰성을 측정하는 지표. 예: "전체 요청 중 성공 응답(2xx)의 비율"
SLO(Service Level Objective): SLI에 대한 목표치. 예: "월간 요청의 99.9%는 성공해야 한다"
에러 버짓(Error Budget): SLO 달성 범위 내에서 허용되는 오류의 총량

Burn Rate 계산 예시

99.9% SLO 기준, 월간 에러 버짓 = 720시간 × 0.1% = 약 43.2분

Burn Rate 소진 예상 시간 계산 의미

1× 30일 ÷ 1 = 30일 정상 소진 속도

14.4× 30일 ÷ 14.4 ≈ 2.1일(약 50시간) 즉각 대응 필요

6× 30일 ÷ 6 = 5일 당일 대응 필요

3× 30일 ÷ 3 = 10일 티켓 발행으로 대응

자신의 SLO 목표치에 맞는 임계값을 조정할 때 소진 예상 시간 = 30일 ÷ Burn Rate 공식을 활용하면 됩니다. Google 기본값(14.4×, 6×, 3×, 1×)은 99.9% SLO 기준으로 설계된 값이므로, 99.0% SLO 서비스에는 그대로 적용할 수 없습니다.

Burn Rate	소진 예상 시간 계산	의미
1×	30일 ÷ 1 = 30일	정상 소진 속도
14.4×	30일 ÷ 14.4 ≈ 2.1일(약 50시간)	즉각 대응 필요
6×	30일 ÷ 6 = 5일	당일 대응 필요
3×	30일 ÷ 3 = 10일	티켓 발행으로 대응

Multi-Window, Multi-Burn-Rate(MWMB) 알림 전략

Google SRE Workbook이 권장하는 임계값은 다음과 같습니다:

단계	Burn Rate	짧은 창	긴 창	소진 예상 시간	대응 방식
Critical (Fast-Burn)	≥ 14.4×	5분	1시간	~2일	즉각 온콜 호출
Critical (Fast-Burn)	≥ 6×	30분	6시간	~5일	즉각 온콜 호출
Warning (Slow-Burn)	≥ 3×	2시간	24시간	~10일	티켓 발행
Warning (Slow-Burn)	≥ 1×	6시간	72시간	~30일	티켓 발행

이중 창 검증의 효과: 5분 창만으로 평가하면 일시적 트래픽 폭증에도 알림이 발화됩니다. 5분 AND 1시간 조건을 함께 쓰면, 5분 동안 급격히 나빠졌고 그 추세가 1시간 동안 지속됐을 때만 알림이 울립니다.

Recording Rules(기록 규칙)

grafana-slo-app은 SLO 생성 시 이 Recording Rules도 함께 자동으로 프로비저닝합니다.

Alertmanager와 grafana-slo-app이 자동으로 만들어주는 것들

grafana-slo-app은 Grafana 공식 플러그인으로, SLO를 UI에서 한 번 생성하면 다음 리소스를 모두 자동으로 프로비저닝합니다:

SLO 생성
  ├── 대시보드 (에러 버짓 번다운 차트 포함)
  ├── 기록 규칙 (Recording Rules) — 다중 창 SLI 쿼리 최적화
  └── 알림 규칙 (Alert Rules)
        ├── [Critical] fast-burn: grafana_slo_severity="critical"
        └── [Warning]  slow-burn: grafana_slo_severity="warning"

자동 생성된 알림에는 Alertmanager 라우팅에 바로 활용할 수 있는 레이블이 부착됩니다:

grafana_slo_uuid — SLO 고유 식별자
grafana_slo_window — 평가 창 (예: 5m, 1h)
grafana_slo_severity — critical 또는 warning

실전 적용

예시 1: Grafana Cloud — Alertmanager 이중 라우팅 구성

yaml

# grafana-slo-app이 자동 생성하는 Alert Rule 예시 (단순화된 형태)
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: slo-api-gateway
spec:
  groups:
    - name: slo-api-gateway.rules
      rules:
        - alert: SLOFastBurn
          expr: |
            (
              slo:sli_error:ratio_rate5m{grafana_slo_uuid="<uuid>"}
              > (14.4 * (1 - 0.999))
            )
            and
            (
              slo:sli_error:ratio_rate1h{grafana_slo_uuid="<uuid>"}
              > (14.4 * (1 - 0.999))
            )
          labels:
            grafana_slo_severity: critical
            grafana_slo_uuid: "<uuid>"
          annotations:
            summary: "Fast-burn: SLO 에러 버짓이 빠르게 소진 중"

이 자동 생성 규칙의 grafana_slo_severity 레이블을 기준으로 Alertmanager 라우팅을 분기합니다.

yaml

# alertmanager.yml
route:
  receiver: 'default'
  routes:
    # Fast-Burn: 즉각 온콜 호출 (구체적인 matcher를 항상 상단에 배치)
    - matchers:
        - grafana_slo_severity = "critical"
      receiver: 'pagerduty-oncall'
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 1h
 
    # Slow-Burn: 티켓 생성
    - matchers:
        - grafana_slo_severity = "warning"
      receiver: 'jira-ticket'
      group_wait: 5m
      group_interval: 30m
      repeat_interval: 6h
 
receivers:
  - name: 'pagerduty-oncall'
    pagerduty_configs:
      - routing_key: '${PAGERDUTY_ROUTING_KEY}'   # 환경 변수 또는 Secret으로 주입
        description: '{{ .CommonAnnotations.summary }}'
        severity: 'critical'
 
  - name: 'jira-ticket'
    webhook_configs:
      - url: '${JIRA_AUTOMATION_WEBHOOK_URL}'      # Jira Automation 웹훅 URL
        send_resolved: true
 
  - name: 'default'
    slack_configs:
      - api_url: '${SLACK_WEBHOOK_URL}'
        channel: '#alerts'

민감 정보 주입 방법: routing_key 같은 인증 정보를 YAML에 직접 하드코딩하면 보안 사고로 이어질 수 있습니다. Grafana Cloud 환경에서는 Grafana Secrets Manager 또는 Kubernetes Secret을 활용하고, Self-hosted 환경에서는 ${ENV_VAR} 환경 변수 참조 방식을 사용하는 것을 권장합니다.

Grafana Cloud에서 alertmanager.yml 적용 방법: Grafana Cloud 좌측 메뉴 → Alerting → Alertmanager → Alertmanager configuration 탭에서 전체 YAML을 직접 붙여넣거나 UI의 Contact points / Notification policies로 구성할 수 있습니다. Terraform grafana_alertmanager_config 리소스를 통한 GitOps 방식도 지원됩니다.

Jira 웹훅 연동: Jira Automation의 "웹훅으로 규칙 트리거" 기능 또는 Atlassian Forge 앱을 통해 알림 수신 시 Jira 티켓을 자동 생성할 수 있습니다. 특정 환경에 종속되지 않는 범용 구성을 원한다면 webhook_configs에 자체 미들웨어 URL을 사용하는 방식도 유효합니다.

설정 항목	Fast-Burn 값	Slow-Burn 값	이유
`group_wait`	30초	5분	Critical은 집계 대기 최소화
`repeat_interval`	1시간	6시간	Warning 반복 알림 빈도 낮춤
`receiver`	PagerDuty	Jira 웹훅	중요도별 채널 분리

예시 2: Self-hosted 환경 — Sloth로 MWMB 규칙 생성

Grafana Cloud를 사용하지 않는 Self-hosted Prometheus 환경에서는 Sloth를 사용해 YAML로 SLO를 정의하고 MWMB 알림 규칙을 자동 생성할 수 있습니다.

yaml

# slo-api-gateway.yaml (Sloth 입력 파일)
version: "prometheus/v1"
service: "api-gateway"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "99.9% of requests should be successful"
    sli:
      events:
        # [{{.window}}]는 Sloth의 Go 템플릿 문법으로, 규칙 생성 시
        # 5m, 30m, 1h, 6h 등 각 평가 창 값으로 자동 치환됩니다.
        error_query: sum(rate(http_requests_total{job="api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="api"}[{{.window}}]))
    alerting:
      name: APIGatewayAvailability
      page_alert:
        labels:
          severity: critical
          team: platform
      ticket_alert:
        labels:
          severity: warning
          team: platform

위 파일을 Sloth CLI로 처리하면 Prometheus에 바로 적용 가능한 기록 규칙과 알림 규칙 YAML이 생성됩니다:

bash

# Sloth로 PrometheusRule 생성
sloth generate -i slo-api-gateway.yaml -o rules/api-gateway-slo.yaml
 
# Kubernetes 환경이라면 PrometheusRule CRD로 적용
kubectl apply -f rules/api-gateway-slo.yaml

예시 3: 환경별 접근법 — Grafana-managed vs Data source-managed

알림 관리 모드 선택은 운영 환경과 GitOps 요구사항에 따라 달라집니다.

구분	Grafana-managed	Data source-managed
알림 저장 위치	Grafana 내부 DB	Prometheus/Mimir 직접 저장
Alertmanager	Grafana 내장 AM	외부 Prometheus AM
GitOps 적합성	API / Terraform	PrometheusRule CRD
추천 환경	Grafana Cloud	Self-hosted Kubernetes
전환 시 주의	—	Contact Point 재구성 필수

Data source-managed 모드로 전환할 경우, 아래 절차로 엔드투엔드 라우팅을 검증해보시면 좋습니다:

bash

# 외부 Alertmanager 설정 문법 검증
amtool check-config alertmanager.yml
 
# 테스트 알림 발화로 실제 라우팅 경로 확인
amtool alert add alertname="TestSLOAlert" grafana_slo_severity="critical" \
  --alertmanager.url=http://localhost:9093

Data source-managed 전환 시 주의: 기존 Grafana Alertmanager에 설정된 Notification Policy와 Contact Point는 외부 Alertmanager에 반드시 재구성해야 합니다. 이를 누락하면 SLO 알림이 발화돼도 아무도 통보받지 못하는 운영 공백이 생깁니다. 전환 직후 테스트 알림으로 전체 경로를 반드시 확인하는 것을 권장합니다.

장단점 분석

장점

항목	내용
알림 피로 감소	실제 에러 버짓 소진이 위협받는 상황에서만 발화되므로 노이즈가 크게 줄어듭니다
원클릭 자동화	grafana-slo-app은 SLO 생성 한 번으로 기록 규칙, 대시보드, 알림 규칙을 모두 프로비저닝합니다
오탐 억제	짧은 창 AND 긴 창 이중 검증으로 순간 스파이크에 의한 거짓 알림이 억제됩니다
대응 분리	Critical은 즉시 온콜 호출, Warning은 티켓으로 분리해 야간 불필요 호출을 방지합니다
SLO-as-Code	Terraform `grafana_slo` 리소스로 GitOps 파이프라인에 통합할 수 있습니다

단점 및 주의사항

항목	내용	대응 방안
Cloud 종속성	grafana-slo-app 전체 기능은 Grafana Cloud 전용	Self-hosted 환경에서는 Sloth + Prometheus 조합 활용
알림 지연	Slow-Burn은 최장 72시간 창을 사용해 탐지까지 수 시간 소요 가능	Fast-Burn 임계값을 낮춰 조기 탐지를 보완하는 방향으로 튜닝
임계값 튜닝	Google 기본값(14.4×, 6×, 3×, 1×)이 모든 서비스에 최적이 아님	`소진 예상 시간 = 30일 ÷ Burn Rate` 공식으로 SLO 목표치에 맞게 재산출
레이블 복잡성	다수 SLO 운영 시 `grafana_slo_uuid`, `team` 등 레이블과 라우팅 트리 정합성 유지 부담	레이블 명명 규칙을 팀 내 표준으로 문서화
AM 이중 관리	Grafana-managed에서 외부 AM 전환 시 Contact Point 동기화 운영 부담	전환 전 체크리스트 작성 후 스테이징 환경에서 검증

실무에서 가장 흔한 실수

Alertmanager 라우팅 순서 오류: routes 배열에서 grafana_slo_severity = "critical" 규칙이 catch-all 규칙보다 하위에 위치하면, Critical 알림이 PagerDuty 대신 기본 채널로 전달됩니다. 가장 구체적인 매처를 항상 배열 상단에 배치해야 합니다.
Data source-managed 전환 후 Contact Point 미재구성: 외부 Alertmanager로 전환했지만 Notification Policy를 옮기지 않아 SLO 알림이 발화돼도 아무도 통보받지 못하는 상황이 발생합니다. 전환 직후 테스트 알림으로 엔드투엔드 경로를 검증하는 것을 권장합니다.
Google 기본 임계값을 그대로 적용: 99.9% SLO 기준으로 설계된 기본값을 99.0% SLO 서비스에 그대로 적용하면 번 레이트 스케일이 달라져 알림이 너무 자주 또는 너무 늦게 발화됩니다. 소진 예상 시간 = 30일 ÷ Burn Rate 공식으로 자신의 SLO 목표치에 맞게 임계값을 재산출하는 것을 권장합니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

SLO 정의: Grafana Cloud라면 grafana-slo-app에서 핵심 API 엔드포인트의 가용성 SLO(예: 99.9%)를 생성합니다. Self-hosted라면 sloth generate -i my-slo.yaml -o rules/my-slo.yaml로 MWMB 규칙 파일을 자동 생성할 수 있습니다.
Alertmanager 라우팅 적용: 예시 1의 alertmanager.yml을 참고해 grafana_slo_severity = "critical" → PagerDuty/IRM, grafana_slo_severity = "warning" → 웹훅 티켓으로 라우팅을 구성한 뒤 테스트 알림으로 엔드투엔드 경로를 검증합니다.
에러 버짓 대시보드 모니터링: 자동 생성된 번다운 차트를 팀 채널에 공유해 에러 버짓 잔량을 가시화하고, 월간 추세를 보며 임계값 튜닝 여부를 판단합니다.

다음 글: Terraform grafana_slo 리소스로 SLO를 코드로 관리하고 GitOps 파이프라인에 통합하는 SLO-as-Code 실전 가이드