---
title: เงื่อนไขของช่อง - การกรองการแจ้งเตือนอย่างชาญฉลาด
sidebarTitle: เงื่อนไข
description: "กรองการแจ้งเตือนของ Echobell ด้วยนิพจน์แบบมีเงื่อนไข: ตัวดำเนินการ กฎอิงเวลา และแนวปฏิบัติที่ดีเพื่อลดความล้าจากการแจ้งเตือน"
---

# เงื่อนไขของช่อง

เงื่อนไขของช่องคือนิพจน์อันทรงพลังที่กำหนดว่าควรส่งการแจ้งเตือนเมื่อใด เมื่อคุณตั้งเงื่อนไขให้กับช่อง คุณจะกรองการแจ้งเตือนตามเนื้อหาของตัวแปรหรือเฮดเดอร์ HTTP ได้ ทำให้ผู้ติดตามได้รับเฉพาะการแจ้งเตือนที่เกี่ยวข้องเท่านั้น สิ่งนี้จำเป็นอย่างยิ่งต่อการลดความล้าจากการแจ้งเตือนและรักษาอัตราส่วนสัญญาณต่อสัญญาณรบกวนให้สูงในระบบแจ้งเตือนของคุณ

ลองนึกภาพว่าเงื่อนไขคือผู้เฝ้าประตูของการแจ้งเตือนของคุณ มันจะประเมินข้อมูลของทริกเกอร์ที่เข้ามา และปล่อยการแจ้งเตือนผ่านไปเฉพาะเมื่อเข้าเกณฑ์ที่กำหนดไว้เท่านั้น

## ทำความเข้าใจเงื่อนไข

เงื่อนไขคือนิพจน์ที่ให้ผลลัพธ์เป็น `true` หรือ `false` เมื่อช่องถูกทริกเกอร์:

- หาก **ไม่ได้ตั้ง** เงื่อนไขไว้ (เว้นว่าง) ระบบจะส่งการแจ้งเตือนไปยังผู้ติดตามทุกคน
- หาก **ตั้ง** เงื่อนไขไว้ ระบบจะส่งการแจ้งเตือนเฉพาะเมื่อนิพจน์นั้นให้ผลลัพธ์เป็น `true` เท่านั้น

## การเขียนเงื่อนไข

เงื่อนไขเขียนเป็นนิพจน์โดยไม่ต้องมีวงเล็บ `{{}}` ครอบแบบที่ใช้ในเทมเพลต ตัวอย่างเช่น:

```
status == "active"
```

เงื่อนไขนี้จะอนุญาตให้ส่งการแจ้งเตือนได้เฉพาะเมื่อตัวแปร `status` มีค่าเท่ากับ "active"

## กรณีใช้งานที่พบบ่อย

นี่คือตัวอย่างการใช้เงื่อนไขในทางปฏิบัติ:

### การตรวจสอบตัวแปรพื้นฐาน

```
amount > 100
```

แจ้งเตือนเฉพาะเมื่อตัวแปร "amount" มีค่ามากกว่า 100

```
message != ""
```

แจ้งเตือนเฉพาะเมื่อตัวแปร "message" ไม่ว่างเปล่า

```
isUrgent == true
```

แจ้งเตือนเฉพาะเมื่อตัวแปร "isUrgent" เป็นจริง

### การตรวจสอบเฮดเดอร์ HTTP

คุณเข้าถึงเฮดเดอร์ HTTP ได้ด้วยตัวแปรพิเศษ `header`:

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

แจ้งเตือนเฉพาะเมื่อเฮดเดอร์ระบุแหล่งที่มาแบบกำหนดเองตรงกับ "grafana" พอดี

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

แจ้งเตือนเฉพาะเมื่อชนิดของเนื้อหาเป็น JSON

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

แจ้งเตือนเฉพาะเมื่อเฮดเดอร์ระบุลำดับความสำคัญแบบกำหนดเองถูกตั้งเป็น "high"

<Callout type="info">คีย์ทั้งหมดในเฮดเดอร์เป็นตัวพิมพ์เล็ก</Callout>

### เงื่อนไขที่ซับซ้อน

คุณรวมหลายเงื่อนไขเข้าด้วยกันได้ด้วยตัวดำเนินการทางตรรกะ:

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

แจ้งเตือนเฉพาะเมื่ออุณหภูมิเกิน 30 หรือความดันเกิน 100 และสถานะเป็น "monitoring"

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

แจ้งเตือนเฉพาะข้อผิดพลาดระดับวิกฤตหรือระดับสูงในสภาพแวดล้อมการใช้งานจริงเท่านั้น

## ตัวดำเนินการที่รองรับ

นิพจน์เงื่อนไขรองรับตัวดำเนินการต่อไปนี้:

| ตัวดำเนินการ              | คำอธิบาย                 | ตัวอย่าง                                    |
| ------------------------- | ------------------------ | ------------------------------------------- |
| `==`                      | เท่ากับ                  | `status == "active"`                        |
| `!=`                      | ไม่เท่ากับ               | `status != "inactive"`                      |
| `!`                       | นิเสธทางตรรกะ (NOT)      | `!isCompleted`                              |
| `<`                       | น้อยกว่า                 | `count < 10`                                |
| `>`                       | มากกว่า                  | `price > 99.99`                             |
| `<=`                      | น้อยกว่าหรือเท่ากับ      | `battery <= 20`                             |
| `>=`                      | มากกว่าหรือเท่ากับ       | `confidence >= 0.95`                        |
| `&&`                      | และทางตรรกะ (AND)        | `isAdmin && isActive`                       |
| <code>&#124;&#124;</code> | หรือทางตรรกะ (OR)        | <code>isError &#124;&#124; isWarning</code> |

## ตัวแปรที่ใช้ในเงื่อนไข

เมื่อช่องถูกทริกเกอร์ผ่าน webhook คุณเข้าถึงสิ่งเหล่านี้ได้:

1. **พารามิเตอร์ใน query** จาก URL
2. **JSON body** จากคำขอแบบ POST
3. **เฮดเดอร์ HTTP** ผ่านอ็อบเจกต์ `header`

สำหรับทริกเกอร์อีเมล คุณเข้าถึงสิ่งเหล่านี้ได้:

- `from`: ที่อยู่อีเมลของผู้ส่ง
- `to`: ที่อยู่ของผู้รับ
- `subject`: บรรทัดหัวข้อของอีเมล
- `text`: เนื้อหาแบบข้อความล้วน
- `html`: เนื้อหาแบบ HTML

### ตัวแปรเวลาของระบบ (UTC)

ตัวแปรแบบอ่านอย่างเดียวเหล่านี้ใช้ได้เสมอทั้งในเงื่อนไขและเทมเพลต ค่าทั้งหมดคำนวณตามเวลา UTC

ค่าต่อไปนี้ถูกใส่เข้ามาโดยตรง (ระดับบนสุด) และเรียกใช้ด้วยชื่อได้เลย:

- `year`: ปีแบบ 4 หลัก (ตัวเลข)
- `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
```

วิธีนี้ช่วยให้เพื่อนร่วมทีมเข้าใจตรรกะของการแจ้งเตือนโดยไม่ต้องมานั่งแกะนิพจน์

### คำนึงถึงกรณีขอบ
เผื่อไว้สำหรับตัวแปรที่ขาดหายไปหรือค่าที่ไม่คาดคิด:

- **ตัวแปรที่ขาดหายไป**: ตัวแปรที่ไม่ได้นิยามไว้จะถูกประเมินเป็นค่าว่าง/เท็จ ควรตรวจสอบว่าตรรกะของคุณรับมือกับกรณีนี้ได้
- **การเปรียบเทียบเชิงตัวเลข**: `<`, `>`, `<=` และ `>=` จะแปลงตัวถูกดำเนินการ **ทั้งสองฝั่ง** ด้วย `Number()` จึงเปรียบเทียบเชิงตัวเลข ไม่ใช่เชิงลำดับตัวอักษร ดังนั้น `"100" > "20"` จึงเป็น `true` (100 > 20) ไม่ใช่ตามลำดับตัวอักษร
- **ค่าที่ไม่ใช่ตัวเลข**: หากฝั่งใดฝั่งหนึ่งของการเปรียบเทียบ `<`, `>`, `<=` หรือ `>=` ไม่ใช่ตัวเลข `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)
```

เงื่อนไขนี้จะส่งการแจ้งเตือนขั้นวิกฤตตลอด 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"
```

## การใช้เงื่อนไขร่วมกับเทมเพลต

เงื่อนไขและ [เทมเพลต](/docs/template) ทำงานร่วมกันเพื่อสร้างการแจ้งเตือนที่ชาญฉลาดและมีบริบท:

**เงื่อนไข** (กรองว่าทริกเกอร์ใดจะส่งการแจ้งเตือน):
```
temperature > 30 || humidity > 80
```

**เทมเพลต** (จัดรูปแบบเนื้อหาการแจ้งเตือน):
```
Title: {{location}} Environment Alert
Body: Temp: {{temperature}}°C, Humidity: {{humidity}}%
```

การแยกส่วนแบบนี้ช่วยให้คุณ:
1. **กรอง** การแจ้งเตือนที่ไม่ต้องการออกด้วยเงื่อนไข
2. **จัดรูปแบบ** การแจ้งเตือนที่สำคัญด้วยเทมเพลต
3. **ปรับ** เนื้อหาการแจ้งเตือนตามระดับความรุนแรง

เรียนรู้เพิ่มเติมเกี่ยวกับ [ไวยากรณ์และฟีเจอร์ของเทมเพลต](/docs/template)

## การดีบักเงื่อนไข

หากเงื่อนไขทำงานไม่เป็นไปตามที่คาดไว้:

1. **ลดทอนเงื่อนไขให้ง่ายลง** — ทดสอบทีละการเปรียบเทียบ
2. **ตรวจสอบชื่อตัวแปร** — ให้แน่ใจว่าตรงกันทุกตัวอักษร (แยกตัวพิมพ์ใหญ่เล็ก)
3. **ตรวจสอบชนิดข้อมูล** — ใช้ webhook ทดสอบเพื่อยืนยันชนิดของตัวแปร
4. **ทดสอบตรรกะบูลีน** — แยกเงื่อนไขที่ซับซ้อนออกเป็นส่วนย่อย ๆ
5. **ตรวจทานลำดับความสำคัญของตัวดำเนินการ** — ใช้วงเล็บเพื่อระบุเจตนาให้ชัดเจน
6. **ตรวจหาการพิมพ์ผิด** — ต้องเป็น `header["content-type"]` ไม่ใช่ `header["Content-Type"]`

## เอกสารที่เกี่ยวข้อง

- **[คู่มือเทมเพลต](/docs/template)** — จัดรูปแบบเนื้อหาการแจ้งเตือนด้วยตัวแปร
- **[การเชื่อมต่อ Webhook](/docs/webhook)** — ส่งตัวแปรผ่านคำขอ HTTP
- **[ทริกเกอร์อีเมล](/docs/email-trigger)** — ตัวแปรจากทริกเกอร์อีเมล
- **[เริ่มต้นใช้งาน](/docs)** — ตั้งค่าช่องที่ใช้เงื่อนไขช่องแรกของคุณ

## ขั้นตอนถัดไป

เมื่อคุณเข้าใจเรื่องเงื่อนไขแล้ว:

- **[สร้างการแจ้งเตือนมอนิเตอร์อย่างชาญฉลาด](/docs/developer/grafana)** — กรองการแจ้งเตือนจากโครงสร้างพื้นฐาน
- **[ตั้งค่าการแจ้งเตือน CI/CD](/docs/developer/github)** — แจ้งเตือนเฉพาะอีเวนต์บิลด์ที่สำคัญ
- **[ตั้งค่าการแจ้งเตือนตามเวลา](/blog/time-window-notifications-using-utc-conditions)** — กรองตามเวลาทำการ
- **[สำรวจฟีเจอร์ทั้งหมด](/docs/features)** — ค้นพบว่า Echobell ทำอะไรได้อีกบ้าง

---

การใช้เงื่อนไขอย่างมีประสิทธิภาพช่วยลดสัญญาณรบกวนจากการแจ้งเตือน และทำให้ผู้ติดตามได้รับเฉพาะการแจ้งเตือนที่เกี่ยวข้องและนำไปลงมือทำต่อได้จริง เริ่มจากเงื่อนไขง่าย ๆ แล้วค่อย ๆ สร้างตรรกะการกรองที่ซับซ้อนขึ้นเมื่อความต้องการของคุณเปลี่ยนไป