Grafana Alerting Contact Point·Notification Policy로 팀·심각도별 알림 분기하기

모니터링 시스템을 처음 구축할 때 가장 흔하게 저지르는 실수가 있습니다. 알림은 잔뜩 만들어 놨는데, 전부 하나의 Slack 채널로 쏟아지게 해두는 것입니다. 저도 그랬습니다. 처음 며칠은 그럭저럭 괜찮습니다. 그러다 어느 날 새벽 3시, #alerts 채널에 수백 개의 알림이 폭발하는 순간이 오고, 정작 중요한 severity=critical 알림은 노이즈에 파묻혀 아무도 못 봅니다. 그 사건 이후 저는 알림 구조를 처음부터 다시 설계하게 됐고, 이 글은 그 과정에서 얻은 것들을 정리한 것입니다.

Grafana Unified Alerting의 Contact Point와 Notification Policy는 이 문제를 레이블 기반 라우팅 트리로 풀어냅니다. 여기에 Grafana Cloud IRM의 Escalation Chain까지 연결하면, 알림이 발생한 순간부터 담당자가 응답하거나 에스컬레이션될 때까지의 전체 흐름을 선언적으로 정의할 수 있습니다. 이 글을 읽고 나면 심각도·팀별 라우팅 트리를 Terraform으로 선언할 수 있고, Grafana IRM 에스컬레이션 체인까지 연결해 알림이 절대 누락되지 않는 구조를 직접 구성할 수 있습니다.

한 가지 먼저 짚어두고 싶은 게 있습니다. Grafana OnCall OSS는 2026년 3월 24일 공식 아카이브되었습니다. 자체 호스팅 환경에서 OnCall을 운영 중이었다면 이 글에서 다루는 IRM 에스컬레이션 체인 부분은 Grafana Cloud IRM을 기준으로 읽어주셔야 합니다. 완전 자체 호스팅을 고수해야 하는 환경이라면 Alertmanager + PagerDuty/OpsGenie 직접 연동이 현실적인 대안입니다. 이 전제를 먼저 확인하고 나머지를 읽으시면 훨씬 수월합니다.

핵심 개념

Grafana Unified Alerting의 세 축

Grafana 알림 시스템은 크게 세 가지 구성 요소로 이루어져 있습니다. 각각의 역할이 명확하게 분리되어 있어서, 한번 익혀두면 나중에 구조를 바꾸거나 확장하기가 훨씬 수월합니다.

전체 흐름을 한 줄로 정리하면 이렇습니다:

Alert Rule 발화 → labels 평가 → Notification Policy 매칭 → Contact Point 전송 → IRM Escalation Chain

Contact Point — 알림이 닿는 목적지

Contact Point는 알림이 실제로 전달되는 채널을 정의하는 오브젝트입니다. Slack, PagerDuty, Microsoft Teams, Email, Webhook 등 30개 이상의 통합을 지원하며, 하나의 Contact Point 안에 여러 채널을 묶을 수도 있습니다. 예를 들어 backend-critical이라는 Contact Point 하나에 PagerDuty와 Slack을 동시에 등록해두면, 알림 하나로 두 채널 모두에 전송됩니다.

Contact Point vs. Notification Channel: 과거 Grafana Legacy Alerting에서 쓰던 "Notification Channel" 개념이 Unified Alerting에서 "Contact Point"로 대체된 것입니다. 개념은 거의 같지만, Contact Point는 라우팅 트리와 완전히 분리되어 재사용하기가 훨씬 쉽습니다.

Notification Policy — 레이블 기반 라우팅 트리

Notification Policy가 이 시스템의 핵심입니다. 라우팅 트리 구조로 되어 있고, 루트에는 항상 Default Policy가 있습니다. 모든 알림은 이 트리를 위에서 아래로 내려가며 가장 구체적인 자식 정책에 매칭됩니다.

각 정책은 label matcher 조건으로 알림을 필터링합니다. 매처에는 네 가지 연산자가 있습니다:

여러 조건은 AND 논리로 결합되고, 가장 구체적인(=가장 깊은) 자식 정책이 우선 적용됩니다. 어떤 자식 정책에도 매칭되지 않은 알림은 Default Policy로 떨어집니다. =~ 연산자는 Kubernetes 네임스페이스처럼 값이 동적으로 다양한 경우에 특히 유용합니다.

알림 그룹핑 — group_by, group_wait, group_interval, repeat_interval

이 네 값이 어떻게 함께 작동하는지 한 번에 정리해 두면 나중에 헷갈리는 일이 없습니다:

예를 들어 group_wait: 0s, group_interval: 1m으로 설정하면 critical 알림은 즉시 전송되고, 이후 같은 그룹에 추가 알림이 들어올 때마다 1분 간격으로 업데이트됩니다.

알림 그룹핑 주의: 서로 다른 라우트로 분기된 알림은 절대 하나로 묶이지 않습니다. 그룹핑은 동일한 라우트 내에서만 작동하므로, 라우팅 설계 시 그룹핑 전략도 함께 고민하는 것을 권장합니다.

Continue matching subsequent sibling nodes 옵션을 켜두면 하나의 알림이 여러 정책에 의해 처리될 수도 있습니다. 로그 채널에 모든 알림을 보내면서 동시에 심각도별 채널로도 라우팅하고 싶을 때 유용하지만, 의도치 않은 중복 알림이 생길 수 있으니 명확한 목적이 있을 때만 켜는 것을 권장합니다.

Grafana Cloud IRM — 에스컬레이션 체인

IRM의 Escalation Chain은 Contact Point에서 알림을 받은 이후의 단계별 워크플로입니다. "5분 안에 아무도 응답하지 않으면 다음 담당자에게 넘긴다"는 식의 자동화된 에스컬레이션 로직을 여기서 정의합니다.

Escalation Chain: backend-critical
  ├── Step 1: Notify on-call from schedule [backend-primary]
  ├── Step 2: Wait 5 minutes
  ├── Step 3: Notify on-call from schedule [backend-primary] (Important)
  ├── Step 4: Wait 10 minutes
  ├── Step 5: Notify on-call from schedule [backend-backup]
  ├── Step 6: Wait 15 minutes
  └── Step 7: Notify all team members [backend-team]

알림이 Acknowledge(확인), Resolve(해결), 또는 Silence(무음) 처리될 때까지 체인이 계속 실행됩니다.

Default vs. Important 알림: IRM에서 각 Step은 "Default" 또는 "Important" 방식으로 알림을 보낼 수 있습니다. 개별 엔지니어는 자신의 개인 알림 규칙에서 Default는 앱 푸시로, Important는 전화 통화로 받겠다고 설정할 수 있습니다. 팀 정책과 개인 선호를 분리할 수 있어서, 알림 피로를 줄이는 데 실질적으로 도움이 됩니다.

핵심 요약 — TL;DR

• Alert Rule: 레이블(severity, team)을 붙여 알림의 속성을 정의
• Notification Policy: 레이블 매처 트리로 어느 Contact Point로 보낼지 결정
• Contact Point: 실제 전송 채널(Slack, PagerDuty, IRM 웹훅) 정의
• IRM Escalation Chain: 미응답 시 자동으로 다음 담당자로 넘기는 워크플로

실전 적용

예시 1: 심각도별 라우팅 (critical → PagerDuty, warning → Slack)

언제 이 패턴: 팀 구성원 전체가 같은 온콜 풀을 공유하고, 심각도만으로 채널을 나누면 충분한 소규모~중규모 팀에 적합합니다.

가장 기본적이면서 효과적인 패턴입니다. severity 레이블 하나로 알림의 긴급도를 판단하고, 그에 맞는 채널로 분기합니다. 이것만 해도 새벽 3시 알림 폭풍에서 중요한 것을 골라낼 수 있습니다.

먼저 Contact Point를 세 개 만들어 둡니다:

Alert Rule에 레이블을 붙이는 방식입니다. PromQL이 낯설다면 Prometheus 쿼리 언어 공식 문서를 먼저 보고 오시면 이해가 훨씬 빠릅니다.

groups:
  - name: backend-alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status_code=~"5.."}[5m]) > 0.05
        labels:
          severity: critical
          team: backend
          service: api-gateway
        annotations:
          summary: "API Gateway 에러율 급등"

그다음 Notification Policy 트리를 구성합니다:

[Default Policy]
  contact: slack-general
  group_by: [alertname, cluster]
  │
  ├── [severity=critical]
  │     contact: pagerduty-critical
  │     group_wait: 0s        ← critical은 즉시 보냄
  │     group_interval: 1m
  │     repeat_interval: 30m
  │     │
  │     └── [team=backend]
  │           contact: pagerduty-backend-critical
  │           ← 백엔드 팀 전용 PagerDuty 서비스 키 사용
  │
  ├── [severity=warning]
  │     contact: slack-warning
  │     group_wait: 30s
  │     group_interval: 5m
  │     repeat_interval: 4h
  │
  └── [severity=info]
        contact: slack-general
        group_wait: 1m
        repeat_interval: 12h

선택적 심화 — Terraform으로 IaC 관리: IaC를 도입하지 않은 팀은 이 블록을 건너뛰고 다음 예시로 이동하셔도 됩니다. UI에서 동일하게 구성할 수 있습니다.

# Contact Point 리소스 정의 (policy 참조 전에 선언 필요)
resource "grafana_contact_point" "pagerduty_critical" {
  name = "pagerduty-critical"
 
  pagerduty {
    integration_key = var.pagerduty_integration_key
  }
}
 
resource "grafana_contact_point" "slack_general" {
  name = "slack-general"
 
  slack {
    url = var.slack_webhook_url
  }
}
 
# Notification Policy 트리
resource "grafana_notification_policy" "main" {
  group_by      = ["alertname", "cluster"]
  contact_point = grafana_contact_point.slack_general.name
 
  policy {
    matcher {
      label = "severity"
      match = "="
      value = "critical"
    }
    contact_point   = grafana_contact_point.pagerduty_critical.name
    group_wait      = "0s"
    group_interval  = "1m"
    repeat_interval = "30m"
 
    policy {
      matcher {
        label = "team"
        match = "="
        value = "backend"
      }
      contact_point = grafana_contact_point.pagerduty_backend_critical.name
    }
  }
 
  policy {
    matcher {
      label = "severity"
      match = "="
      value = "warning"
    }
    contact_point   = grafana_contact_point.slack_warning.name
    group_wait      = "30s"
    group_interval  = "5m"
    repeat_interval = "4h"
  }
}

이렇게 구성하면 severity=critical, team=backend 알림은 백엔드 전용 PagerDuty 서비스로, severity=critical이지만 팀이 backend가 아닌 알림은 공통 PagerDuty로, severity=warning은 Slack warning 채널로 각각 분기됩니다. 저희 팀은 이 구조로 바꾼 뒤 새벽 Slack 스레드에서 critical을 찾아 헤매는 일이 사라졌습니다.

예시 2: 팀별 우선 분기 + security 팀 특수 처리

언제 이 패턴: 팀마다 알림 처리 방식이 완전히 다를 때, 또는 security처럼 외부 채널과 완전히 분리된 파이프라인이 필요한 팀이 있을 때 적합합니다.

조직에 따라 심각도보다 팀 소유권 기준으로 먼저 분기하고 싶을 수 있습니다.

[Default Policy]
  contact: slack-general
  │
  ├── [team=security]
  │     contact: security-slack          ← security 팀 전용 Slack 채널
  │     Continue matching: OFF           ← 다른 정책과 겹치지 않게
  │     │
  │     └── [severity=critical]
  │           contact: security-pagerduty  ← critical만 추가 에스컬레이션
  │
  ├── [team=backend]
  │     contact: backend-slack
  │     │
  │     └── [severity=critical]
  │           contact: pagerduty-backend
  │
  └── [team=frontend]
        contact: frontend-slack

Continue matching subsequent sibling nodes 옵션을 끄면 team=security 알림이 다른 형제 정책(예: severity 기반 정책)으로 흘러 들어가지 않습니다. 이 옵션의 기본값은 꺼진 상태이므로, 크로스 라우팅이 필요한 경우에만 명시적으로 켜는 것을 권장합니다.

예시 3: Grafana IRM과 연동한 에스컬레이션 체인 구성

언제 이 패턴: critical 알림에 대해 "미응답 시 자동 에스컬레이션"이 필요한 팀, 온콜 스케줄이 있는 팀에 적합합니다.

솔직히 처음 설정할 때 이 연결 고리가 가장 헷갈렸습니다. Grafana Alerting과 IRM이 어떻게 연결되는지 순서대로 따라가 보시면 됩니다.

1단계: IRM 통합 생성 후 웹훅 URL 확인

Grafana Cloud IRM → Integrations → + New Integration → Grafana Alerting에서 통합을 만들면 웹훅 URL이 생성됩니다. 이 URL이 Grafana Alerting과 IRM을 연결하는 브릿지 역할을 합니다.

2단계: IRM 통합을 Contact Point로 등록

Grafana → Alerts & IRM → Alerting → Contact Points에서 + Add contact point를 선택하고, Integration으로 **Grafana OnCall (또는 Grafana IRM)**을 선택한 뒤 1단계에서 받은 웹훅 URL을 입력합니다.

3단계: IRM에서 Escalation Chain 정의

Grafana Cloud IRM → Escalation Chains → + New Escalation Chain에서 이름을 지정하고 단계를 추가합니다:

Step 1: Notify on-call from schedule
        Schedule: backend-primary-schedule
        Notification type: Default
 
Step 2: Wait for 5 minutes
 
Step 3: Notify on-call from schedule
        Schedule: backend-primary-schedule
        Notification type: Important     ← 더 강한 알림 방식 (전화 등)
 
Step 4: Wait for 10 minutes
 
Step 5: Notify on-call from schedule
        Schedule: backend-backup-schedule
        Notification type: Important
 
Step 6: Wait for 15 minutes
 
Step 7: Notify users and teams
        Team: backend-team
 
Step 8: Repeat escalation (max: 5 times)

4단계: IRM 라우팅에서 레이블 조건과 에스컬레이션 체인 연결

IRM → Integration → backend-irm-integration → Routes → + Add Route에서 라우팅 조건을 입력합니다:

Routing condition: {{ labels.severity == "critical" }}
Escalation Chain: backend-critical-chain

여기서 {{ labels.severity == "critical" }} 문법은 IRM 자체 라우팅 DSL로, Jinja2에서 파생된 표현식입니다. Grafana Cloud IRM의 Route 설정 UI에서 직접 입력하는 방식이며, Prometheus 레이블 값을 그대로 참조할 수 있습니다. 붙여 넣기 전에 IRM UI의 "Preview" 기능으로 실제 매칭 여부를 확인해 보는 것을 권장합니다.

IRM의 2단계 라우팅 철학: Grafana 공식 문서에서는 "Grafana Alerting에서 팀·서비스 기준으로 거칠게 라우팅(coarse-grained)하고, IRM에서 심각도별로 세밀하게 에스컬레이션(fine-grained)하라"고 권장합니다. 저도 처음엔 두 곳 모두에 세밀한 조건을 넣어봤는데, 어느 쪽에서 최종 라우팅이 결정됐는지 추적하기가 어려워졌습니다. 역할을 분리하는 게 확실히 낫습니다.

예시 4: Kubernetes 환경에서의 namespace·cluster 기반 라우팅

언제 이 패턴: 멀티 클러스터 또는 멀티 네임스페이스 환경에서, 스테이징/프로덕션 환경별로 에스컬레이션 수위를 다르게 가져가고 싶을 때 적합합니다.

Kubernetes 클러스터를 운영하다 보면 네임스페이스나 클러스터별로 알림 처리를 달리해야 하는 상황이 자주 생깁니다.

groups:
  - name: k8s-pod-alerts
    rules:
      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
        labels:
          severity: critical
          cluster: production
          # namespace 레이블은 메트릭에 이미 포함되어 있으므로
          # Notification Policy 매처에서 직접 사용 가능
        annotations:
          summary: "Pod 재시작 감지: {{ $labels.namespace }}/{{ $labels.pod }}"

동적 레이블 매핑 주의: team: "{{ $labels.namespace }}" 형태로 Alert Rule의 labels 필드에서 동적 값을 생성하는 방식보다는, kube_pod_container_status_restarts_total 메트릭이 이미 namespace 레이블을 포함하고 있으므로 Notification Policy에서 namespace =~ prod-.* 형태의 정규식 매처로 직접 매칭하는 쪽이 더 명확하고 예측 가능합니다.

[Default Policy]
  contact: slack-general
  │
  ├── [cluster=production, severity=critical]
  │     contact: irm-production-critical    ← IRM 에스컬레이션 체인으로
  │     group_by: [cluster, namespace, alertname]
  │     group_wait: 0s
  │
  ├── [cluster=production, severity=warning]
  │     contact: slack-production-warning
  │
  └── [cluster=staging]
        contact: slack-staging              ← 스테이징은 Slack으로만

cluster=production + severity=critical 조합이 매칭되면 IRM으로 넘어가 당직 엔지니어에게 에스컬레이션됩니다. 스테이징 환경 알림은 Slack 알림으로만 처리해 새벽에 전화가 오는 일을 막을 수 있습니다.

Notification Policy의 실제 구조를 파일로 버전 관리하고 싶다면 GET /api/v1/provisioning/policies 엔드포인트를 호출하면 전체 트리가 JSON으로 반환됩니다. 형태는 아래와 같습니다:

{
  "receiver": "slack-general",
  "group_by": ["alertname", "cluster"],
  "routes": [
    {
      "receiver": "irm-production-critical",
      "matchers": ["cluster=\"production\"", "severity=\"critical\""],
      "group_by": ["cluster", "namespace", "alertname"],
      "group_wait": "0s"
    },
    {
      "receiver": "slack-staging",
      "matchers": ["cluster=\"staging\""]
    }
  ]
}

장단점 분석

팀에서 실제로 겪었던 부분 위주로 정리했습니다.

장점

단점 및 주의사항

실무에서 가장 흔한 실수

1. 레이블 없이 Alert Rule을 만드는 것: 레이블이 없으면 Notification Policy에서 아무것도 매칭되지 않아 모든 알림이 Default Policy로 떨어집니다. Alert Rule을 만들 때 severity와 team 레이블을 함께 정의하는 습관을 들이는 것이 좋습니다.

2. Continue matching 옵션을 무분별하게 켜두는 것: 이 옵션을 켜면 하나의 알림이 여러 Contact Point로 동시에 전송됩니다. 의도하지 않은 중복 알림이 발생할 수 있으므로, 명확한 목적이 있을 때만 켜는 것을 권장합니다.

3. IRM 라우팅과 Alerting 라우팅을 이중으로 복잡하게 만드는 것: Grafana Alerting에서 팀 단위로 거칠게 분기하고, IRM에서 심각도별로 세밀하게 처리하는 역할 분리를 지키는 것이 좋습니다. 두 곳에 모두 복잡한 조건을 넣으면 어느 쪽에서 실제 라우팅이 결정되는지 파악하기 어려워집니다.

마치며

Grafana Alerting의 Contact Point·Notification Policy 라우팅 트리와 IRM 에스컬레이션 체인은, 알림이 발생한 순간부터 담당자가 응답하는 순간까지의 전체 흐름을 코드처럼 선언적으로 정의할 수 있게 해줍니다.

한 가지 경험에서 나온 팁을 드리자면, 처음부터 완벽한 트리를 설계하려고 하면 오히려 막히게 됩니다. 가장 고통스러운 부분 하나만 먼저 해결한다는 마음으로 시작하는 게 실제로 더 빠릅니다. 저도 처음엔 전체 조직 라우팅 구조를 한 번에 그리려다 아무것도 못 바꾼 채 두 달을 흘려보냈습니다. 아직 모든 알림이 하나의 채널로 쏟아지고 있는 환경이라면, 아래 순서대로 하나씩 시도해 보시면 좋습니다.

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

1. 레이블 정의부터 시작: 기존 Alert Rule에 severity: critical | warning | info와 team: [팀명] 레이블을 추가합니다. 전체 Alert Rule 목록을 열고 레이블이 없는 것부터 하나씩 채워나가는 것으로 충분합니다.

2. Notification Policy 트리 구성: Alerts & IRM → Alerting → Notification Policies에서 Default Policy 아래에 [severity=critical] 자식 정책을 하나 만들고, 별도 Contact Point(Slack의 #alerts-critical 채널 등)에 연결해 봅니다. 이것만으로도 critical 알림이 즉시 분리됩니다.

3. IRM 에스컬레이션 체인 연결: Grafana Cloud IRM에서 Integrations → Grafana Alerting 통합을 만들고, 웹훅 URL을 Contact Point로 등록합니다. "5분 대기 → 백업 담당자 호출" 두 스텝짜리 간단한 Escalation Chain 하나를 만들어 critical 라우트에 연결해 보시면, 에스컬레이션이 어떻게 작동하는지 바로 체감할 수 있습니다.

참고 자료

먼저 읽어야 할 필수 문서:

• Notification Policies | Grafana 공식 문서 — 라우팅 트리 개념을 가장 잘 설명하는 공식 레퍼런스
• Best Practices for Alert Routing | Grafana Cloud IRM 문서 — coarse/fine-grained 분리 철학이 여기서 나옴
• Best Practices for Escalation Chains | Grafana Cloud IRM 문서 — 에스컬레이션 체인 설계 모범 사례

추가 참고 자료:

• Configure Notification Policies | Grafana 공식 문서
• Contact Points | Grafana 공식 문서
• Configure Contact Points | Grafana 공식 문서
• Configure Escalation Chains | Grafana Cloud IRM 문서
• Grafana Alerting Integration for Grafana OnCall | Grafana OnCall 문서
• Migrate from Grafana OnCall OSS to Grafana Cloud IRM | Grafana Cloud 문서
• Grafana OnCall OSS Archival Notice | Grafana OnCall 문서
• Attach the Schedule to the Escalation Chain | Grafana Labs Learning Path