한눈에 보기
- ‘사용자가 먼저 알기 전에’ 장애를 잡는 Azure Monitor 알림 설정 흐름을 정리합니다.
- 핵심은 메트릭 알림(빠름)과 로그(KQL) 알림(유연함)을 목적에 맞게 쓰는 것.
- 알림 규칙 + 액션 그룹(메일·웹훅)으로 즉시 통보받습니다.
모니터링의 목적은 ‘대시보드를 들여다보는 것’이 아니라 ‘문제가 생겼을 때 먼저 연락받는 것’입니다. Azure Monitor는 메트릭과 로그 두 축으로 알림을 만듭니다.
메트릭 알림 vs 로그(KQL) 알림
| 구분 | 메트릭 알림 | 로그(KQL) 알림 |
|---|---|---|
| 속도 | 빠름(거의 실시간) | 쿼리 주기마다 |
| 유연성 | 정해진 메트릭 | KQL로 자유롭게 |
| 예시 | CPU>80%, 응답시간 | 5분간 5xx 100건 초과 |
| 적합 | 리소스 상태 | 로그 패턴·복합 조건 |
로그 알림용 KQL 예시
최근 5분간 HTTP 5xx 응답이 임계치를 넘으면 알리는 쿼리입니다. 이 결과 건수를 알림 규칙의 조건으로 씁니다.
// 최근 5분 5xx 응답 집계 (App 로그 예시)
AppRequests
| where TimeGenerated > ago(5m)
| where ResultCode >= 500
| summarize errors = count() by bin(TimeGenerated, 1m)알림을 ‘받는’ 곳: 액션 그룹
알림 규칙이 켜져도 받을 사람이 없으면 소용없습니다. 액션 그룹에 이메일·SMS·웹훅(슬랙/Teams 연동)을 등록하고 규칙에 연결하세요.
# 이메일 수신 액션 그룹 생성
az monitor action-group create -g <RG> -n ops-email \
--short-name ops --action email admin admin@example.com흔한 실수
- 임계치를 너무 민감하게 — 알림 폭주로 결국 무시하게 됩니다(알림 피로).
- 액션 그룹 미연결 — 규칙은 있는데 아무도 못 받습니다.
- 로그 알림 주기를 너무 길게 — 장애 인지가 늦어집니다. 중요 신호는 메트릭 알림 병행.
자주 묻는 질문(FAQ)
- Q. 메트릭과 로그 알림 중 뭘 먼저? A. CPU·가용성 같은 기본 상태는 메트릭, 복합·패턴 조건은 로그(KQL).
- Q. 슬랙으로 받고 싶어요. A. 액션 그룹의 웹훅으로 슬랙/Teams 수신 엔드포인트를 연결하면 됩니다.
- Q. 비용이 드나요? A. 로그 수집·보존과 일부 알림 평가에 비용이 있습니다. 보존 기간을 적절히 설정하세요.
마치며
기본 상태는 메트릭 알림, 복잡한 조건은 KQL 로그 알림, 그리고 반드시 액션 그룹으로 받을 사람을 연결하세요. ‘사용자보다 먼저 아는’ 운영의 출발점입니다.