Alerts 시작하기
이 가이드는 알림 채널 설정부터 Alert 규칙 정의까지, 첫 번째 Alert를 설정하는 과정을 안내합니다.
사전 요구사항
- 클러스터에 Wave가 설치되어 실행 중이어야 합니다
- Wave 웹 콘솔에 접근 권한이 있어야 합니다
- Alert를 생성할 수 있는 관리자 권한이 있어야 합니다
- 알림을 받을 대상 (Slack workspace 또는 HTTP endpoint)
빠른 시작 개요
Alert 설정은 두 단계로 진행됩니다.
- Alert 채널 생성 - 알림을 보낼 위치 정의
- Alert 규칙 생성 - 알림을 트리거할 조건 정의
모범 사례: 채널을 먼저 만들고 Alert 규칙에서 참조하세요. 하나의 채널은 여러 Alert에서 재사용할 수 있습니다.
1단계: Alerts 페이지 접속
Alerts로 이동

- 메뉴에서 Alerts를 선택합니다
- Alerts 페이지가 열리며 두 개의 탭이 나타납니다.
- Alerts - Alert 규칙 관리
- Channels - Alert 채널 관리

- 여러 클러스터를 사용하는 경우 올바른 클러스터 컨텍스트를 설정합니다
2단계: Alert 채널 생성
Alert 채널은 알림을 보낼 위치를 정의합니다. Alert 규칙을 설정하기 전에 채널을 최소 하나 이상 생성해야 합니다.
채널 유형 선택

Channels 탭으로 이동해 Create를 클릭합니다. 세 가지 채널 유형 중에서 선택합니다.
HTTP Webhook - 범용 webhook, PagerDuty, 커스텀 API용
- URL: webhook endpoint 주소
- Method: POST (기본값), PUT, PATCH, DELETE
- Headers (선택 사항):
Authorization: Bearer <token>와 같은 인증 헤더 - Proxy (선택 사항): 엔터프라이즈 네트워크용 HTTP 프록시 URL
Slack Webhook - 간단한 Slack 연동
- Webhook URL: Slack incoming webhook URL (Slack App 설정에서 발급)
- Proxy (선택 사항): HTTP 프록시 URL
Slack Web API - 고급 Slack 기능
- Token:
xoxb-로 시작하는 Bot token - Channel: Channel ID (예:
C1234567890) 또는 이름 (예:#alerts) - Proxy (선택 사항): HTTP 프록시 URL
HTTP Webhook 설정 예시
{
"name": "PagerDuty Production",
"type": "http",
"data": {
"url": "https://events.pagerduty.com/v2/enqueue",
"method": "POST",
"headers": {
"Authorization": "Token token=your-integration-key",
"Content-Type": "application/json"
}
}
}Slack Webhook 설정 예시
{
"name": "Team Dev Channel",
"type": "slack_webhook",
"data": {
"webhook_url": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXX"
}
}채널 테스트
저장하기 전에 Test를 클릭해 다음을 확인합니다.
- 네트워크 연결
- 인증 유효성
- endpoint 가용성
테스트는 샘플 알림을 전송하고 응답을 표시합니다. 오류가 있으면 진행하기 전에 수정하세요.
채널 저장
테스트가 성공하면 Save를 클릭해 채널을 생성합니다. 이제 채널 목록에 표시되며 Alert 규칙에서 참조할 수 있습니다.
3단계: Alert 규칙 생성
Alert 규칙은 무엇을 모니터링하고 언제 알림을 보낼지 정의합니다.
Alerts 탭으로 이동

Alerts 탭으로 전환하고 Create를 클릭합니다.
기본 설정

Title - Alert 이름을 명확하게 작성합니다
- 좋은 예: "Production CPU Over 80% for 5min"
- 피해야 할 예: "Alert 1" 또는 "Test"
Event Type - 모니터링할 이벤트를 선택합니다.
deployment_workload_metrics- 시간에 따른 CPU/메모리 지표deployment_scheduling_phase- START/END 라이프사이클 이벤트autopilot_logs_missing- 로그 누락 감지pending_pod_duration-Pending상태에 묶여 있는 Pod (Wave 3.4.0+)pod_container_failure-CrashLoopBackOff등 컨테이너 장애 전환 (3.4.0+)pv_usage- PVC 용량 임계값 (3.4.0+)smart_sizing_recommendation- Smart Sizing 추천과 현재 request의 차이 (3.4.0+)oom_kill_risk- kill이 일어나기 전 실시간 OOM-kill 위험 (3.4.0+)
각 이벤트 유형의 규칙 변수, 지원 대상 유형, 예시 규칙은 Alert CRD 레퍼런스를 참고하세요.
이벤트 타겟 정의
이 Alert가 모니터링할 리소스를 선택합니다.
None - Alert 비활성화 (삭제하지 않고 일시적으로 끌 때 유용)
All - 해당 유형의 모든 리소스 모니터링
{
"all": {
"resource_type": "deployment"
}
}Specific - 선택한 리소스만 모니터링
{
"specific": [
{
"resource_type": "deployment",
"namespace": "production",
"name": "web-app"
},
{
"resource_type": "deployment",
"namespace": "production",
"name": "api-server"
}
]
}규칙 표현식 작성
규칙 표현식은 true(Alert 트리거) 또는 false(Alert 없음)로 평가되는 JavaScript 표현식입니다.
예시 1: CPU Alert
${evaluation_period_minutes} >= 5 && ${max(cpu_utilization_arr)} >= 80CPU가 80%를 5분 이상 초과하면 트리거됩니다.
예시 2: 메모리 Alert
${evaluation_period_minutes} >= 10 && ${avg(memory_utilization_arr)} >= 85평균 메모리 사용률이 10분간 85%를 초과하면 트리거됩니다.
예시 3: 복합 Alert
${evaluation_period_minutes} >= 5 &&
(${max(cpu_utilization_arr)} >= 90 || ${avg(memory_utilization_arr)} >= 90)CPU 또는 메모리가 5분 이상 90%를 초과하면 트리거됩니다.
예시 4: 배포 이벤트
${phase} == "START"배포가 시작되면 트리거됩니다.
예시 5: Autopilot 로그
${missing_duration_minutes} >= 3Autopilot 로그가 3분 이상 누락되면 트리거됩니다.
확인 간격 설정
Event Rule Check Interval (minutes) - 규칙을 평가할 주기
1- 매분 확인 (기본값, 프로덕션에 권장)5- 5분마다 확인 (덜 중요한 Alert용)15- 15분마다 확인 (백그라운드 모니터링용)
간격을 짧게(1분) 설정하면 알림 속도는 빨라지지만 시스템 부하가 늘어납니다. 대부분의 프로덕션 환경에서는 1~5분이 적당합니다.
Alert 메시지 설정
Alert가 트리거될 때 전송할 메시지를 하나 이상 추가합니다. 각 메시지는 다음을 포함합니다.
- Alert 채널 참조 (2단계에서 생성)
- 변수 보간이 포함된 템플릿
메시지 템플릿 예시:
🔴 ${alert_title}
**Workload**: ${namespace}/${workload_name}
**CPU Usage**: ${max(cpu_utilization_arr)}%
**Memory Usage**: ${avg(memory_utilization_arr)}%
**Duration**: ${evaluation_period_minutes} minutes
**Time**: ${alert_time}
[View in Console](https://your-console/app/k8s/workloads)사용 가능한 변수 (이벤트 유형에 따라 다름):
${alert_title}- Alert 규칙 제목${alert_time}- 트리거 타임스탬프${namespace}- 리소스 namespace${workload_name}- 워크로드 이름${max(cpu_utilization_arr)}- 배열의 최대 CPU 값${avg(memory_utilization_arr)}- 배열의 평균 메모리 값${phase}- 배포 단계 (START/END)${deployment_count}- 배포 수${missing_duration_minutes}- 로그 공백 기간
규칙 검증
저장하기 전에 Validate 버튼으로 다음을 확인합니다.
- JavaScript 구문 확인
- 필드 사용이 이벤트 유형과 일치하는지 확인
- 렌더링된 메시지 템플릿 미리보기
검증 오류가 있으면 진행하기 전에 수정하세요.
Alert 저장
Save를 클릭해 Alert 규칙을 생성합니다. 설정한 확인 간격에 따라 즉시 평가가 시작됩니다.
4단계: Alert 실행 모니터링
Alert를 생성한 후에는 실행 내역을 모니터링해 정상 동작하는지 확인합니다.
Alert 로그 확인

- Alerts 탭으로 이동합니다
- 목록에서 Alert를 찾습니다
- Logs 버튼을 클릭합니다

Alert 로그 페이지에는 다음이 표시됩니다.
- Timestamp - Alert가 트리거된 시각
- Alert Title - 실행된 Alert
- Channel - 알림이 전송된 위치
- Status - 성공 또는 오류
- Response - endpoint로부터의 HTTP 응답
- Reason - 오류 세부 정보 (실패한 경우)
알림 확인
알림 채널을 확인합니다.
- Slack: 설정한 채널에서 메시지 확인
- HTTP Webhook: 대상 시스템에서 수신된 이벤트 확인
- PagerDuty: 인시던트 생성 여부 확인
실패한 Alert 문제 해결
Alert가 트리거되지 않거나 전달에 실패하는 경우 다음을 확인합니다.
Alert가 전혀 트리거되지 않음
- 검증 도구로 규칙 표현식 구문 확인
- 이벤트 타겟이 기존 리소스와 일치하는지 확인
- 확인 간격이 경과했는지 확인 (1~5분 대기)
- 해당 이벤트 유형에서 사용 가능한 필드 검토
알림 전달 실패
- Alert 로그에서 오류 메시지 확인
- 채널 URL이 올바르고 접근 가능한지 확인
- 인증 헤더/토큰이 유효한지 테스트
- 네트워크 연결 확인 (방화벽 뒤에 있다면 프록시 설정 시도)
- HTTP 응답 코드 검토 (401 = 인증 오류, 404 = 잘못된 URL, 500 = 서버 오류)
Alert가 너무 많음
- 확인 간격을 늘려 빈도 줄이기
- 규칙 표현식의 임계값 조정
- 평가 기간 조건 추가 (예: 5분 이상 지속되어야 함)
Alert가 너무 적음
- 더 많은 경우를 포착하도록 임계값 낮추기
- 평가 기간 조건 완화
- 이벤트 타겟에 의도한 리소스가 포함되어 있는지 확인
설정 예시
프로덕션 높은 CPU Alert
채널: PagerDuty HTTP Webhook
{
"name": "PagerDuty Production",
"type": "http",
"data": {
"url": "https://events.pagerduty.com/v2/enqueue",
"method": "POST",
"headers": {
"Authorization": "Token token=YOUR_KEY",
"Content-Type": "application/json"
}
}
}Alert:
- Title: Production CPU Critical
- Event Type:
deployment_workload_metrics - Targets:
productionnamespace의 모든 배포 (specific) - Rule:
${evaluation_period_minutes} >= 3 && ${max(cpu_utilization_arr)} >= 90 - Interval: 1분
- Message:
🚨 CRITICAL: CPU Alert
Workload: ${namespace}/${workload_name}
CPU: ${max(cpu_utilization_arr)}%
Duration: ${evaluation_period_minutes}min
Action Required: Investigate immediatelySlack으로 배포 알림
채널: Slack Webhook
{
"name": "Deployments Channel",
"type": "slack_webhook",
"data": {
"webhook_url": "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
}
}Alert:
- Title: Staging Deployments
- Event Type:
deployment_scheduling_phase - Targets:
stagingnamespace의 모든 배포 - Rule:
${phase} == "START" || ${phase} == "END" - Interval: 1분
- Message:
📦 Deployment ${phase == "START" ? "Started" : "Ended"}
Count: ${deployment_count} deployment(s)
Namespace: staging
Time: ${alert_time}Autopilot 모니터링
채널: Slack Web API
{
"name": "Autopilot Alerts",
"type": "slack_web_api",
"data": {
"token": "xoxb-your-bot-token",
"channel": "C1234567890"
}
}Alert:
- Title: Autopilot Logs Missing
- Event Type:
autopilot_logs_missing - Targets: 모든 배포
- Rule:
${missing_duration_minutes} >= 5 - Interval: 1분
- Message:
⚠️ Autopilot Logs Missing
Workload: ${namespace}/${workload_name}
Missing for: ${missing_duration_minutes} minutes
Action: Check Autopilot pod health모범 사례
채널 관리
✅ 권장:
- 채널 이름은 구체적으로: "Webhook 1"이 아니라 "PagerDuty Production"처럼
- Alert에 사용하기 전에 채널 테스트
- 여러 Alert에서 채널 재사용
- 인증 정보를 안전하게 문서화
❌ 비권장:
- 채널 이름에 시크릿 하드코딩
- 동일한 대상에 대해 중복 채널 생성
- 프로덕션 알림에 개인 Slack DM 사용
Alert 규칙 설계
✅ 권장:
- 명확하고 구체적인 Alert 제목 사용
- flapping을 방지하기 위해 평가 기간 추가 (예:
>= 5 minutes) - 메시지 템플릿에 컨텍스트 포함 (namespace, 워크로드, 값)
- 보수적인 임계값으로 시작한 뒤 경험에 따라 조정
❌ 비권장:
- 평가 기간 없이 Alert 생성 (Alert 폭주 유발)
- "Alert 1"이나 "Test"처럼 모호한 제목 사용
- 사소한 임계값 위반마다 Alert 발생
- 저장 전 검증 생략
운영 가이드라인
✅ 권장:
- 매주 Alert 로그를 검토해 노이즈가 많은 Alert 파악
- 실제 워크로드 동작에 따라 임계값 조정
- 문제 해결 중에는 삭제 대신 비활성화 (target: None)
- 온콜 팀을 위한 Alert 에스컬레이션 경로 문서화
❌ 비권장:
- 확인 간격을 1분 미만으로 설정 (불필요한 부하)
- Alert가 중복되는 겹치는 Alert 생성
- 로그의 Alert 전달 실패 무시
- 테스트 없이 Alert 설정
다음 단계
첫 번째 Alert를 생성했다면 다음 단계를 진행하세요.
- 24~48시간 모니터링 - Alert 빈도를 관찰하고 임계값 조정
- 채널 추가 - 심각도별로 다른 알림 대상 설정
- Alert 변형 생성 - staging, 개발 클러스터에 유사한 Alert 설정
- Insights와 연동 - Insights 데이터로 Alert 임계값 설정에 참고
- 고급 패턴 학습 - 기술적 심층 분석은 동작 방식 참고
축하합니다! 첫 번째 Wave Alert를 설정했습니다. 이제 클러스터가 자동 알림으로 실시간 모니터링됩니다.