채널 조건 - 스마트 알림 필터링

채널 조건은 알림을 언제 보낼지 결정하는 강력한 표현식입니다. 채널에 조건을 설정하면 변수나 HTTP 헤더의 내용을 기준으로 알림을 필터링할 수 있어, 구독자는 관련 있는 알림만 받게 됩니다. 이는 알림 피로를 줄이고 알림 시스템의 신호 대 잡음 비율을 높게 유지하는 데 필수적입니다.

조건은 알림의 문지기라고 생각하면 됩니다. 들어오는 트리거 데이터를 평가해 특정 기준을 충족할 때만 알림을 통과시킵니다.

조건 이해하기

조건은 true 또는 false로 평가되는 표현식입니다. 채널이 트리거되면 다음과 같이 동작합니다.

• 조건이 설정되지 않은 경우(비어 있는 경우) 모든 구독자에게 알림이 전송됩니다.
• 조건이 설정된 경우 표현식이 true로 평가될 때만 알림이 전송됩니다.

조건 작성하기

조건은 템플릿에서 사용하는 {{}} 래퍼 없이 표현식으로 작성합니다. 예를 들면 다음과 같습니다.

status == "active"

이 조건은 status 변수가 "active"일 때만 알림이 전송되도록 허용합니다.

일반적인 사용 사례

다음은 조건을 활용하는 실용적인 예시입니다.

기본 변수 확인

amount > 100

"amount" 변수가 100보다 클 때만 알림을 보냅니다.

message != ""

"message" 변수가 비어 있지 않을 때만 알림을 보냅니다.

isUrgent == true

"isUrgent" 변수가 true일 때만 알림을 보냅니다.

HTTP 헤더 확인

특수 변수 header를 사용해 HTTP 헤더에 접근할 수 있습니다.

header["x-webhook-source"] == "grafana"

사용자 지정 소스 헤더가 "grafana"와 정확히 일치할 때만 알림을 보냅니다.

header["content-type"] == "application/json"

콘텐츠 유형이 JSON일 때만 알림을 보냅니다.

header["x-priority"] == "high"

사용자 지정 우선순위 헤더가 "high"로 설정된 경우에만 알림을 보냅니다.

복합 조건

논리 연산자를 사용해 여러 조건을 결합할 수 있습니다.

(temperature > 30 || pressure > 100) && status == "monitoring"

온도가 30을 넘거나 압력이 100을 넘으면서 상태가 "monitoring"일 때만 알림을 보냅니다.

environment == "production" && (errorLevel == "critical" || errorLevel == "high")

프로덕션 환경에서 critical 또는 high 수준의 오류가 발생한 경우에만 알림을 보냅니다.

지원되는 연산자

조건식에서는 다음 연산자를 사용할 수 있습니다.

조건 변수

Webhook으로 채널이 트리거되면 다음 값에 접근할 수 있습니다.

1. URL의 쿼리 파라미터
2. POST 요청의 JSON 본문
3. header 객체를 통한 HTTP 헤더

이메일 트리거의 경우 다음 값에 접근할 수 있습니다.

• from: 이메일 발신자 주소
• to: 수신자 주소
• subject: 이메일 제목
• text: 일반 텍스트 본문 내용
• html: HTML 본문 내용

시스템 시간 변수(UTC)

이 읽기 전용 변수들은 조건과 템플릿 양쪽에서 항상 사용할 수 있습니다. 모든 값은 UTC 기준으로 계산됩니다.

다음 값들은 플랫한 형태로 직접 주입되므로 이름만으로 사용할 수 있습니다.

• year: 네 자리 연도(숫자)
• month: 월 번호 1–12
• dayOfMonth: 일 1–31
• dayOfWeek: 요일 0–6(일요일 = 0)
• hour: 시 0–23
• minute: 분 0–59
• second: 초 0–59
• date: YYYY-MM-DD 형식 문자열
• time: HH:mm:ss 형식 문자열
• iso: 현재 시각의 ISO‑8601 문자열(예: 2025-05-06T12:34:56.789Z)

다음 값들은 sys. 네임스페이스에서만 사용할 수 있으며, 플랫한 이름으로는 주입되지 않습니다.

• sys.timezone: 상수 문자열 "UTC"
• sys.now: 현재 시각의 ISO‑8601 문자열(iso와 같은 값)
• sys.epochMs: Unix epoch 이후 경과한 밀리초(숫자)
• sys.epochSeconds: Unix epoch 이후 경과한 초(숫자)
• sys.monthName: 월 이름 January–December
• sys.dayOfWeekName: 요일 이름 Sunday–Saturday

sys. 네임스페이스는 모든 플랫 값도 그대로 제공합니다(예: sys.year, sys.hour).

예시:

// Weekdays during 09:00–17:00 UTC
hour >= 9 && hour < 17 && dayOfWeek >= 1 && dayOfWeek <= 5

// Weekends only
dayOfWeek == 0 || dayOfWeek == 6

// First day of month at top of hour
dayOfMonth == 1 && minute == 0

모범 사례

단순하게 시작하기

기본 조건부터 시작해 필요에 따라 복잡도를 높이세요.

1단계: 단일 조건으로 시작합니다

temperature > 30

2단계: 논리 연산자를 추가합니다

temperature > 30 && location == "server-room"

3단계: 중첩된 논리를 추가합니다

(temperature > 30 || humidity > 80) && location == "server-room" && status == "monitoring"

철저하게 테스트하기

다양한 입력값으로 조건을 테스트해 예상대로 동작하는지 확인하세요.

1. 정상적인 값으로 테스트 - 예상되는 상황에서 조건이 동작하는지 확인합니다
2. 경계값 테스트 - 임계값과 정확히 같을 때는 어떻게 되나요?
3. 변수가 없는 경우 테스트 - 데이터가 없을 때 조건은 어떻게 처리되나요?
4. 예상치 못한 타입 테스트 - 숫자가 문자열로 전달되면 어떻게 되나요?
5. 테스트용 Webhook 사용 - 여러 데이터 조합으로 테스트 트리거를 보내 보세요

조건 문서화하기

복잡한 조건을 설명하려면 채널의 메모 필드에 주석을 추가하세요.

Channel Note:
Condition: (cpu > 80 && memory > 90) || diskSpace < 10

This condition triggers alerts when:
- Both CPU is above 80% AND memory is above 90%
- OR when disk space drops below 10GB

이렇게 하면 팀원들이 표현식을 일일이 해석하지 않고도 알림 로직을 이해할 수 있습니다.

경계 상황 고려하기

변수 누락이나 예상치 못한 값에 대비하세요.

• 변수 누락: 정의되지 않은 변수는 빈 값 또는 false로 평가되므로, 로직이 이를 처리할 수 있어야 합니다
• 숫자 비교: <, >, <=, >=는 양쪽 피연산자를 모두 Number()로 변환하므로 사전순이 아니라 숫자로 비교합니다. "100" > "20"은 사전순이 아니라 100 > 20이므로 true입니다.
• 숫자가 아닌 값: <, >, <=, >= 비교에서 어느 한쪽이라도 숫자가 아니면 Number()가 NaN을 만들어 비교 결과는 항상 false가 됩니다.
• 동등 비교와 대소 비교: ==와 !=는 느슨한 동등 비교를 사용하지만(그래서 count == "5"는 숫자 5와 일치합니다), 대소 비교 연산자는 항상 숫자로 비교합니다.
• 대소문자 구분: status == "Active"는 status == "active"와 다릅니다

알림 폭주 방지하기

일시적인 문제로 알림이 연달아 쏟아지지 않도록 조건을 활용하세요.

errorCount > 5    # Not just errorCount > 0
cpuUsage > 90     # Not cpuUsage > 50
failureRate > 0.1 # Not just hasFailures

적절한 임계값과 함께 사용하면 중요한 이벤트를 놓치지 않으면서 잡음을 줄일 수 있습니다.

업무 시간 필터링 활용하기

심각도와 시간 기반 조건을 결합하세요.

severity == "critical" || (severity == "high" && hour >= 9 && hour < 17)

이렇게 하면 critical 알림은 24시간 내내 전송되고, 우선순위가 높은 알림은 업무 시간에만 전송됩니다.

헤더 검사 활용하기

스팸이나 허가되지 않은 트리거를 막으려면 Webhook 출처를 검증하세요.

header["x-webhook-source"] == "grafana" || header["x-webhook-source"] == "prometheus"

요청 출처를 확인함으로써 보안 계층을 하나 더 추가할 수 있습니다.

실제 활용 예시

서버 모니터링 - 단계적 알림

# Only alert when CPU is consistently high, not transient spikes
cpu > 80 && duration >= 300

이커머스 - 고액 주문

# Only notify for orders above $500 or fraud-flagged orders
orderAmount > 500 || isFraudSuspected == true

개발 - 치명적인 빌드 실패

# Alert only for main branch failures or failed deployments
(branch == "main" || branch == "master") && status == "failed"

IoT - 환경 모니터링

# Temperature extremes outside acceptable range
temperature < 15 || temperature > 28

보안 - 로그인 실패 시도

# Multiple failed logins from same IP in short time
failedAttempts >= 3 && timeSinceFirst < 300

CI/CD - 배포 추적

# Only notify on production deploys or staging failures
(environment == "production") || (environment == "staging" && status == "failed")

트레이딩 - 가격 알림

# Significant price movements beyond threshold
(priceChange > 5 || priceChange < -5) && volume > 1000000

고객 지원 - SLA 위반

# Tickets approaching or exceeding SLA
ticketAge > slaThreshold || priority == "urgent"

자주 쓰는 조건 패턴

임계값 기반 알림

value > threshold
percentage >= 90
count < minimumRequired

상태 기반 필터링

status == "error" || status == "critical"
state != "healthy"
isActive == true

시간대 기반 필터링

# Business hours only (9 AM - 5 PM UTC, Monday-Friday)
hour >= 9 && hour < 17 && dayOfWeek >= 1 && dayOfWeek <= 5

# After hours only
hour < 9 || hour >= 17 || dayOfWeek == 0 || dayOfWeek == 6

# Weekend maintenance windows
(dayOfWeek == 0 || dayOfWeek == 6) && hour >= 2 && hour < 6

다중 요소 조건

# Combine multiple criteria
severity == "high" && environment == "production" && region == "us-east-1"

# Either critical OR production with high severity
severity == "critical" || (severity == "high" && environment == "production")

문자열 매칭

# Exact match (there is no "contains" operator)
status == "error"
errorType == "database"

# String comparison
environment == "production"
username != "test-user"

조건과 템플릿 함께 사용하기

조건과 템플릿은 함께 작동해 스마트하고 상황에 맞는 알림을 만들어 줍니다.

조건(어떤 트리거가 알림을 보낼지 필터링):

temperature > 30 || humidity > 80

템플릿(알림 내용의 형식 지정):

Title: {{location}} Environment Alert
Body: Temp: {{temperature}}°C, Humidity: {{humidity}}%

이렇게 역할을 분리하면 다음과 같은 이점이 있습니다.

1. 조건으로 원치 않는 알림을 필터링합니다
2. 템플릿으로 중요한 알림의 형식을 지정합니다
3. 심각도에 따라 알림 내용을 조정합니다

템플릿 문법과 기능에 대해 더 알아보세요.

조건 디버깅하기

조건이 예상대로 동작하지 않는다면 다음을 확인하세요.

1. 조건을 단순화하세요 - 한 번에 하나의 비교만 테스트합니다
2. 변수 이름을 확인하세요 - 정확히 일치하는지 확인합니다(대소문자를 구분합니다)
3. 데이터 타입을 확인하세요 - 테스트용 Webhook으로 변수 타입을 확인합니다
4. 불리언 로직을 테스트하세요 - 복잡한 조건을 작은 단위로 나눕니다
5. 연산자 우선순위를 검토하세요 - 괄호를 사용해 의도를 명확히 합니다
6. 오타를 확인하세요 - header["Content-Type"]이 아니라 header["content-type"]입니다

관련 문서

• 템플릿 가이드 - 변수로 알림 내용의 형식을 지정합니다
• Webhook 연동 - HTTP 요청으로 변수를 전달합니다
• 이메일 트리거 - 이메일 트리거에서 제공되는 변수
• 시작하기 - 첫 조건부 채널을 설정합니다

다음 단계

이제 조건을 이해했다면 다음을 살펴보세요.

• 스마트 모니터링 알림 만들기 - 인프라 알림 필터링
• CI/CD 알림 설정하기 - 중요한 빌드 이벤트에만 알림 보내기
• 시간 기반 알림 구성하기 - 업무 시간 필터링
• 모든 기능 살펴보기 - Echobell로 할 수 있는 일 알아보기

---

조건을 효과적으로 활용하면 알림 잡음을 줄이고 구독자가 자신에게 관련 있고 실제로 조치할 수 있는 알림만 받도록 할 수 있습니다. 간단한 조건부터 시작해 필요에 맞춰 점차 정교한 필터링 로직으로 발전시켜 보세요.