---
title: "Prometheus Alertmanager 전화 알림: 정말 급한 것에만 울리게 하기"
description: "Alertmanager에는 음성 리시버가 없습니다. critical 등급일 때만 Prometheus 알림을 전화로 바꾸는 방법: webhook 설정, 조건, 그리고 Watchdog 함정."
date: 2026-09-04
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Prometheus
  - Alertmanager
  - 전화 알림
  - 웹훅 알림
  - Kubernetes
  - 온콜
---

# Prometheus Alertmanager 전화 알림: 정말 급한 것에만 울리게 하기

Alertmanager에는 음성 리시버가 없습니다. Prometheus 알림이 발생했을 때 전화를 받으려면, 구독 유형을 **전화**로 설정한 Echobell 채널을 가리키는 `webhook_configs` 리시버를 추가하세요. 이 글에서는 정확한 YAML, 해결된 알림이 전화를 걸지 못하게 하는 조건, 심각도별 라우팅, 그리고 그대로 두면 네 시간마다 영원히 전화를 울리게 만드는 Watchdog 알림을 다룹니다.

Prometheus는 지난 10년간 구축된 대부분의 인프라에서 사실상 기본 메트릭 스택이며, [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/)는 어려운 부분들을 정말 잘 해냅니다. 알림 중복 제거, 그룹화, 점검 중 무음 처리, 상위 의존성 장애 시 하위 노이즈 억제까지요.

다만 하지 않는 일이 하나 있습니다. 사람을 깨우는 것입니다.

## Alertmanager 혼자서는 왜 전화를 울릴 수 없나

Alertmanager에는 이메일, Slack, PagerDuty, OpsGenie, Discord, Telegram, Pushover, Webex, MS Teams 등 십수 종의 리시버가 있습니다. 하지만 이들 모두가 전달하는 것은 **메시지**이고, 메시지는 무음 스위치, 방해 금지 모드, iOS 집중 모드의 영향을 받습니다. 새벽 3시에는 곧 "알림은 도착했지만 아무 일도 일어나지 않았다"는 뜻입니다.

`voice_configs` 같은 건 없습니다. 사람들이 보통 도달하는 선택지는 이렇습니다.

- **PagerDuty / OpsGenie / Splunk On-Call** — 실제로 전화를 걸어주지만, 모두 좌석당 과금이 붙는 완전한 인시던트 관리 플랫폼입니다. 교대 근무와 에스컬레이션 트리가 필요하다면 정답이지만, 전화만 울리면 되는 상황에는 과합니다. (게다가 OpsGenie는 [서비스 종료 수순](/ko/blog/opsgenie-end-of-life-alternatives)에 있어서, 지금 많은 팀이 이 계층을 재검토하고 있습니다.)
- **[Sachet](https://github.com/messagebird/sachet) 같은 SMS 브리지** — 서비스를 하나 더 운영하고, 게이트웨이에 건당 비용을 내지만, SMS는 여전히 메시지로 도착합니다. iOS에서는 발신자가 허용 목록에 있지 않는 한 문자가 집중 모드를 뚫지 못합니다.
- **Twilio 기반 자체 구현** — 작은 웹훅 리시버를 짜고, 번호를 사고, 통화당 비용을 내면, 이제 "전화를 울리는 것"이 유일한 임무인 프로덕션 인프라를 하나 떠안게 됩니다.

범용 **webhook 리시버**가 그 탈출구입니다. 문서화된 JSON을 임의의 URL로 POST해 주며, 필요한 건 그게 전부입니다.

## 준비물

- 실행 중인 Prometheus + Alertmanager, 그리고 `alertmanager.yml`을 수정할 권한
- Echobell 설치 ([App Store](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-alertmanager-phone-call-alerts-ko&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid))
- 10분

이 글은 Alertmanager 0.31을 기준으로 작성했습니다. 웹훅 페이로드는 수년째 `version: "4"`이므로 0.2x 릴리스도 동일하게 동작합니다.

Alertmanager에서 `hook.echobell.one`로 나가는 아웃바운드 HTTPS가 필요하지만, 인터넷에서 접근 가능할 필요는 **없습니다**. 클러스터 내부, VPC 내부, 홈랩의 Alertmanager 모두 문제없이 동작합니다.

## 1단계 — 전화를 걸어주는 채널 만들기

Echobell에서 `Prometheus Critical` 같은 이름으로 채널을 만듭니다. 구독 알림 유형을 **전화**로 설정하세요. 이 설정이 핵심입니다. 전화 유형 알림은 수신 전화 화면으로 도착해 iOS 집중 모드와 방해 금지 모드를 뚫고 울립니다. 푸시 알림은 그렇게 하지 못합니다.

템플릿은 Alertmanager 페이로드를 직접 읽도록 설정합니다.

```
Title: 🔴 {{commonLabels.alertname}} on {{commonLabels.instance}}
Body: {{commonAnnotations.summary}}
{{commonAnnotations.description}}
```

그리고 고급 설정에서 **링크 템플릿**을 지정하면 알림 기록에서 곧바로 그래프로 이동할 수 있습니다.

```
{{alerts[0].generatorURL}}
```

그다음 채널의 **Webhook URL**을 복사합니다.

```
https://hook.echobell.one/t/<channel-token>
```

이 URL은 비밀 정보로 다루세요. 이걸 가진 사람은 누구든 당신의 전화를 울릴 수 있습니다.

## 2단계 — webhook 리시버 추가하기

`alertmanager.yml`에서:

```yaml
route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-critical

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
```

`curl -X POST http://localhost:9093/-/reload` 또는 `SIGHUP`으로 다시 로드합니다.

`send_resolved: false`에 주목하세요. **webhook 리시버의 기본값은 `true`**로, Alertmanager의 다른 대부분 리시버와 반대입니다. 이 줄을 빼면 서비스가 망가졌을 때 전화가 울리고, 스스로 복구됐을 때 또 한 번 울립니다. 바로 그 두 번째 전화가 사람들에게 첫 번째 전화를 무시하도록 가르칩니다. 4단계에서 벨소리 없이 복구 알림을 되찾는 방법을 다룹니다.

## 3단계 — 실제로 무엇이 도착하는지 이해하기

Alertmanager는 알림을 그룹으로 묶은 뒤, 그룹마다 하나씩 POST합니다.

```json
{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighErrorRate\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "echobell-critical",
  "groupLabels": { "alertname": "HighErrorRate" },
  "commonLabels": { "alertname": "HighErrorRate", "severity": "critical" },
  "commonAnnotations": { "summary": "Error rate above 5% for 10m" },
  "externalURL": "http://alertmanager.internal:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighErrorRate", "instance": "api-7d9f:8080" },
      "annotations": { "summary": "Error rate above 5% for 10m" },
      "startsAt": "2026-09-04T02:41:07.351Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "http://prometheus:9090/graph?g0.expr=...",
      "fingerprint": "a1b2c3d4e5f60718"
    }
  ]
}
```

Echobell은 JSON 본문을 그대로 읽으므로 위의 모든 필드를 템플릿과 조건에서 쓸 수 있습니다. 중첩 접근은 두 문법 모두 동작합니다 — `{{commonLabels.severity}}` 또는 `{{alerts[0].labels["instance"]}}`.

이 페이로드의 두 가지 성질이 이후 모든 것을 좌우합니다.

**최상위 `status`는 그룹 내 알림 중 하나라도 발생 중이면 `firing`입니다.** 그룹의 모든 알림이 해결되어야 비로소 `resolved`가 됩니다. 그래서 필터 기준으로 삼기에 깔끔합니다.

**`commonLabels`에는 그룹 내 모든 알림이 공유하는 레이블만 담깁니다.** 이것이 가장 흔한 함정입니다. `group_by`가 넓어서 한 번의 웹훅이 서로 다른 인스턴스 세 곳의 `HighErrorRate`를 담고 있다면 `commonLabels.instance`는 존재하지 않고, `{{commonLabels.instance}}`는 빈 문자열로 렌더링됩니다. 아래에 이를 다루는 별도 절이 있습니다.

## 4단계 — 복구는 조용한 푸시로 보내기

무언가 복구됐다는 사실은 여전히 알고 싶습니다. 다만 그것 때문에 전화를 받고 싶지 않을 뿐입니다. `Prometheus Recovered`라는 두 번째 Echobell 채널을 만들고 알림 유형을 **일반**으로 설정한 뒤 이 템플릿을 넣습니다.

```
Title: ✅ {{commonLabels.alertname}} resolved
Body: {{commonAnnotations.summary}}
```

그리고 고급 설정에 이 **조건**을 넣습니다.

```
status == "resolved"
```

조건은 무엇이든 전달되기 전에 평가되는 표현식입니다. 표현식이 거짓이면 Echobell은 요청을 수락하되 아무것도 보내지 않습니다.

그다음 같은 리시버가 두 채널을 모두 가리키게 합니다. 하나의 리시버는 여러 개의 `webhook_configs`를 가질 수 있습니다.

```yaml
receivers:
  - name: echobell-critical
    webhook_configs:
      # 전화를 울린다. 발생 시에만.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # 조용한 푸시. 채널 조건이 firing 쪽을 걸러낸다.
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true
```

복구 채널은 firing과 resolved 페이로드를 모두 받고 firing 쪽을 버립니다. 결과적으로 장애에는 전화가 울리고, 복구는 아침에 읽을 푸시로 도착합니다.

## 5단계 — 전부가 아니라 심각도별로 라우팅하기

모든 알림을 전화 채널로 보내는 catch-all 라우트는 무시당하는 전화를 대량 생산하는 기계입니다. 라우팅 트리가 있어야 할 자리인 Alertmanager에서 심각도로 나누세요.

```yaml
route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-warning

  routes:
    # Watchdog은 절대 사람에게 도달하지 않는다. 6단계 참고.
    - matchers:
        - alertname = "Watchdog"
      receiver: "null"

    - matchers:
        - severity = "critical"
      receiver: echobell-critical
      group_wait: 10s
      repeat_interval: 1h

receivers:
  - name: "null"

  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false

  - name: echobell-warning
    webhook_configs:
      - url: "https://hook.echobell.one/t/<normal-channel-token>"
        send_resolved: true
```

라우트는 위에서 아래로 평가되며 **처음 일치한 것이 이깁니다** — `continue`의 기본값은 `false`입니다. 따라서 순서가 중요합니다. `Watchdog` 라우트는 그것을 삼켜버릴 수 있는 규칙보다 위에 있어야 합니다.

채널 하나만 두고 Echobell 쪽에서 필터링하고 싶다면, 동등한 조건은 이렇습니다.

```
status == "firing" && commonLabels.severity == "critical"
```

보통은 Alertmanager 쪽이 낫습니다. 거기서는 `severity`가 `group_wait`와 `repeat_interval`까지 함께 제어하기 때문입니다. Echobell 쪽이 나은 경우는 오늘 안에 설정 변경을 머지할 수 없을 때입니다.

## 6단계 — Watchdog 함정

[kube-prometheus-stack](https://github.com/prometheus-operator/kube-prometheus)을 쓴다면 표현식이 `vector(1)`인 `Watchdog` 알림이 있습니다. 이 알림은 **항상 발생하도록 설계되어 있습니다**. Prometheus 자체가 멈췄다는 사실을 외부 시스템이 알아차릴 수 있게 하려고 존재하기 때문입니다. 기본 설정은 이것을 `null` 리시버로 라우팅합니다.

이것을 제외하지 않은 채 catch-all 라우트를 전화 채널로 향하게 하면, Watchdog은 `repeat_interval`마다, 영원히, 그것도 즉시부터 당신에게 전화를 겁니다. 사람들이 "전화 알림은 못 쓰겠다"고 결론짓는 1순위 원인이 바로 이것입니다.

5단계의 `null` 라우트를 그대로 두세요. 그리고 선택적으로, 그것으로 유용한 일을 하십시오. Watchdog을 진짜 데드맨 스위치로 바꾸는 것입니다.

```yaml
    - matchers:
        - alertname = "Watchdog"
      receiver: deadmansswitch
      group_wait: 0s
      group_interval: 1m
      repeat_interval: 50s

receivers:
  - name: deadmansswitch
    webhook_configs:
      - url: "https://hc-ping.com/<your-check-uuid>"
        send_resolved: false
```

Echobell 자체는 데드맨 스위치가 될 수 없습니다. 요청이 **도착할 때** 알리는 것이지, 요청이 끊겼을 때 알리는 것이 아니기 때문입니다. 그러니 Watchdog 핑은 침묵 감지를 위해 만들어진 서비스([Healthchecks.io](https://healthchecks.io), Cronitor, Dead Man's Snitch)로 보내고, **그 서비스**의 "체크 다운" 웹훅을 Echobell 전화 채널로 향하게 하세요. 이제 전화가 울린다는 것은 "모니터링 자체가 죽었다"는 뜻이 됩니다. 가장 깨어나고 싶은 알림이자, 아무도 설정하지 않는 알림입니다.

## 양치기 소년이 되지 않도록 조정하기

Alertmanager의 세 가지 설정이 대부분의 일을 하고, Prometheus에 하나가 더 있습니다.

| 설정 | 위치 | 역할 |
| --- | --- | --- |
| `for:` | 알림 규칙 | 실제로 발생하기까지 조건이 유지되어야 하는 시간. 2초짜리 순간 장애에 대한 1차 방어선. |
| `group_wait` | 라우트 | 첫 알림 전에 다른 알림을 기다리는 시간. 기본 30s이며 critical은 `10s`로 낮춥니다. |
| `group_interval` | 라우트 | 기존 그룹의 **새** 알림에 대해 통지하기까지의 최소 간격. 기본 5m. |
| `repeat_interval` | 라우트 | 해결되지 않은 알림을 다시 통지하는 주기. **기본 4h** — 즉 야간 장애는 03:00에 전화하고 07:00에 또 겁니다. |

고민할 가치가 있는 건 `repeat_interval`입니다. 네 시간은 무언가를 망가진 채 두기엔 길고, 20분은 결국 채널을 꺼버리게 만드는 장치입니다. critical에 한 시간 정도가 합리적인 출발점입니다.

받지 못한 전화를 다음 `repeat_interval`까지 기다리지 않고 즉시 재시도하게 하려면, Echobell 앱 설정에서 **실패한 통화 재시도**를 켜세요.

## 업무 시간 외에만 울리게 하기

업무 시간에는 이미 대시보드를 보고 있을 가능성이 큽니다. Echobell의 시스템 시간 변수(모두 UTC)를 쓰면 Alertmanager에 두 번째 라우트를 만들지 않고도 채널이 시간대별로 다르게 동작하게 할 수 있습니다.

```
status == "firing" && (hour >= 17 || hour < 9)
```

이렇게 하면 UTC 09:00–17:00 밖에서만 전화가 옵니다. 낮 시간 푸시용으로는 일반 유형의 두 번째 채널을 반대 구간에 맞춥니다.

```
status == "firing" && hour >= 9 && hour < 17
```

`dayOfWeek >= 1 && dayOfWeek <= 5`를 추가하면 주말도 업무 시간 외로 취급됩니다. 이 값들은 항상 UTC로 계산되므로 자신의 시간대만큼 보정하세요. 더 자세한 내용은 [Echobell에서 UTC 조건으로 시간 구간 알림 만들기](/ko/blog/time-window-notifications-using-utc-conditions)를 참고하세요.

## `commonLabels`가 비는 문제 다루기

그룹에 여러 인스턴스의 알림이 섞이면 `commonLabels.instance`가 사라지고 알림 제목이 `🔴 HighErrorRate on `가 되어 버립니다.

권장 순서대로 세 가지 해법이 있습니다.

1. **해당 레이블을 `group_by`에 넣기.** `group_by`에 `instance`가 포함되면 그룹 내 모든 알림이 이를 공유하므로 `commonLabels.instance`가 항상 존재합니다. 대가는 알림 수 증가입니다. 알림 이름당 하나가 아니라 인스턴스당 하나가 됩니다.
2. **첫 번째 알림을 대신 읽기.** `{{alerts[0].labels.instance}}`는 언제나 값이 있습니다. 다만 여럿 중 하나일 뿐이니 개수와 함께 쓰세요: `{{alerts[0].labels.instance}} (총 {{alerts.length}}건)`.
3. **비어 있어도 읽히도록 레이블을 설계하기.** Echobell에는 기본값 연산자가 없습니다 — `{{a || "unknown"}}`은 대체값이 아니라 리터럴 `true`를 렌더링합니다 — 그러니 `Instance: {{commonLabels.instance}}`를 한 줄로 따로 두어, 빈 값이 문장을 깨뜨리는 대신 명백히 비어 보이게 하세요.

## 페이로드를 작게 유지하기

파드 100개를 아우르는 그룹은 큰 JSON 본문을 만들고, Echobell은 1 MiB를 넘는 트리거 본문을 HTTP 413으로 거부합니다. Alertmanager에서 상한을 두세요.

```yaml
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
        max_alerts: 20
```

그러면 Alertmanager는 최대 20건만 보내고, 버린 개수를 `truncatedAlerts`에 담습니다. 본문에 표시할 수도 있습니다.

```
Body: {{commonAnnotations.summary}}
Alerts: {{alerts.length}} (+{{truncatedAlerts}}건 잘림)
```

## 팀과 알림 공유하기

Echobell 채널은 구독 링크로 공유할 수 있고, 구독자마다 자신의 알림 유형을 고릅니다. 따라서 같은 라우트로 온콜 엔지니어의 전화는 울리게 하면서 나머지 사람들에게는 일반 푸시로 도착하게 할 수 있습니다. 좌석당 과금도, Alertmanager의 추가 라우팅 규칙도 필요 없습니다.

이는 애초에 많은 팀이 Prometheus를 자체 호스팅하는 이유와도 잘 맞습니다. 메트릭과 알림 규칙은 여러분의 인프라에 남고, Echobell은 알림 내용과 기록을 서버가 아니라 기기에 보관합니다.

## 이 구성이 제공하지 않는 것

경계를 솔직히 밝혀 두면 나중에 잘못된 마이그레이션을 피할 수 있습니다. Echobell은 전달 계층이지 인시던트 관리 플랫폼이 아닙니다. 다음은 없습니다.

- 온콜 교대 일정이나 follow-the-sun 인수인계
- 첫 담당자가 받지 않으면 두 번째 사람을 호출하는 에스컬레이션 트리
- 인시던트 타임라인, 확인(ack) 추적, 포스트모템 도구

팀에 이런 것들이 필요하다면 PagerDuty나 Grafana Cloud IRM 같은 제품이 필요합니다. 여기서 다룬 것은 Alertmanager가 열어 둔 구체적인 빈틈, 즉 발생한 알림을 실제로 울리는 전화로 바꾸는 일뿐입니다. 1인 운영자, 소규모 팀, 홈랩에는 대개 그것이 요구사항의 전부입니다.

## 문제 해결

**아무것도 도착하지 않습니다.** 먼저 Alertmanager 자체 로그(`level=error component=dispatcher`)를 확인한 뒤, 라우트가 실제로 해당 리시버로 해석되는지 확인하세요. `amtool config routes test severity=critical alertname=HighErrorRate`를 쓰면 실제 알림이 발생하기를 기다리지 않고도 어느 리시버로 떨어질지 알 수 있습니다.

**Echobell이 HTTP 404를 반환합니다.** 채널 토큰이 틀렸거나 채널이 삭제되었습니다. 알 수 없는 토큰은 404이며, 조용한 성공이 아닙니다.

**Echobell이 200과 `"notificationTriggered": false`를 반환합니다.** 조건이 거짓으로 평가되었습니다. 응답 본문에는 `"conditionsMet": false`도 함께 담기며, "조건이 잘못됐다"와 "웹훅이 아예 안 왔다"를 가장 빠르게 구분하는 방법입니다. Alertmanager가 실제로 보낸 값과 대조해 `status == "firing"`을 확인하세요. `alerts[0].status`가 아니라 최상위 status입니다.

**HTTP 413.** 페이로드가 1 MiB를 넘었습니다. 위처럼 `max_alerts`를 설정하세요.

**HTTP 405.** 채널에 **POST Only**가 켜져 있는데 무언가가 GET을 보냈습니다. Alertmanager는 POST를 쓰므로, 보통 브라우저에서 URL을 테스트했다는 뜻입니다.

**제목 중간이 비어 있습니다.** 해당 그룹의 `commonLabels`에 그 레이블이 없었습니다. 위 절을 참고하세요.

**울리지는 않는데 알림은 옵니다.** 구독의 알림 유형이 전화가 아니라 일반 또는 시간 민감으로 되어 있습니다. 알림 유형은 구독자별로 선택하므로, 울리지 않는 기기에서 확인하세요.

**프로덕션을 건드리지 않고 테스트하기.** `expr: vector(1)`, 고유한 `alertname`, `severity: critical`을 가진 규칙을 추가해 한 번 발생시킨 뒤 삭제하세요. 또는 직접 하나 보내도 됩니다.

```bash
curl -X POST http://localhost:9093/api/v2/alerts -H 'Content-Type: application/json' -d '[
  {"labels":{"alertname":"EchobellTest","severity":"critical"},
   "annotations":{"summary":"Testing the phone call path"}}
]'
```

## 자주 묻는 질문

### Prometheus Alertmanager가 자체적으로 전화를 걸 수 있나요?

걸 수 없습니다. Alertmanager에는 이메일, Slack, PagerDuty, OpsGenie 등 많은 리시버가 있지만 음성 리시버도 SMS 리시버도 없습니다. 전화를 걸려면 범용 webhook 리시버를 Echobell처럼 통화가 가능한 서비스로 라우팅하거나, 인시던트 관리 플랫폼에 비용을 지불해야 합니다.

### 전화 알림이 방해 금지 모드를 뚫나요?

뚫습니다. Echobell의 전화 알림 유형은 수신 전화로 표시되며, iOS 집중 모드와 방해 금지 모드를 통과해 울립니다. 자세한 내용과 관련 설정은 [iOS 집중 모드를 뚫고 중요 알림을 받는 방법](/ko/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)을 참고하세요.

### 방화벽 뒤나 Kubernetes 안의 Alertmanager에서도 되나요?

됩니다. 이 웹훅은 Alertmanager에서 나가는 아웃바운드 HTTPS 요청이므로 `hook.echobell.one`에 도달할 수만 있으면 됩니다. Alertmanager에 공인 주소나 인그레스는 필요 없습니다.

### 알림이 해결될 때 전화가 오지 않게 하려면?

전화 채널을 가리키는 webhook 설정에 `send_resolved: false`를 지정하세요. webhook 리시버는 Alertmanager의 다른 대부분 리시버와 달리 기본값이 `true`이므로, 옵트인이 아니라 옵트아웃입니다. 그래도 복구 소식을 조용히 받고 싶다면 `status == "resolved"` 조건을 가진 두 번째 채널을 추가하세요.

### 왜 같은 알림으로 네 시간마다 전화가 울리나요?

`repeat_interval` 때문이며 기본값은 `4h`입니다. Alertmanager는 여전히 발생 중인 알림을 이 주기로 다시 통지합니다. 라우트별로 설정하세요. critical에 `1h`가 흔한 선택입니다. catch-all 라우트를 추가한 직후부터 전화가 시작됐다면, 범인은 항상 발생하는 `Watchdog` 알림일 가능성이 높습니다. 6단계를 보세요.

### 같은 알림으로 여러 사람에게 전화할 수 있나요?

가능합니다. 채널을 동료와 공유하면 구독자마다 알림 유형을 고릅니다. 전화 채널을 구독한 모든 사람에게 전화가 가며, 좌석당 비용도 없습니다.

### 심각도 필터링은 Alertmanager와 Echobell 조건 중 어디서 해야 하나요?

Alertmanager를 우선하세요. 거기서 라우팅하면 심각도별로 `group_wait`와 `repeat_interval`까지 설정할 수 있고, 라우팅 트리가 나머지 설정과 함께 버전 관리에 남습니다. Echobell 조건은 Alertmanager 설정을 바꿀 수 없을 때, 또는 Alertmanager에 개념 자체가 없는 필터(예: 하루 중 시간대)에 쓰세요.

## 마무리

구성은 리시버 하나, `send_resolved: false` 한 줄, 그리고 `severity: critical`이 아닌 모든 것을 전화 채널에서 떼어놓는 라우팅 트리가 전부입니다. 기존 알림 규칙, 그룹화, 무음 처리, 억제 설정은 그대로 두면서, "Prometheus가 알아챘다"와 "사람이 알아챘다" 사이의 틈을 메워줍니다.

[iPhone용 Echobell 내려받기](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-alertmanager-phone-call-alerts-ko&mt=8) 또는 [Google Play에서 받기](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) 후, 정말 중요한 일을 이 경로에 맡기기 전에 위의 `EchobellTest` 알림을 한 번 발생시켜 보세요.

---

## 관련 글

- [Prometheus 연동 문서](/ko/docs/developer/prometheus)
- [채널 조건 레퍼런스](/ko/docs/conditions)
- [Echobell로 Grafana 알림을 전화 알림으로 받기](/ko/blog/grafana-call-notification)
- [Uptime Kuma 전화 알림: 장애가 나면 휴대폰이 울리게 만들기](/ko/blog/uptime-kuma-phone-call-alerts)
- [알림 피로는 실재합니다: 현명한 개발자는 이렇게 해결합니다](/ko/blog/fix-alert-fatigue-developer-guide)