เงื่อนไขของช่อง - การกรองการแจ้งเตือนอย่างชาญฉลาด

เงื่อนไขของช่องคือนิพจน์อันทรงพลังที่กำหนดว่าควรส่งการแจ้งเตือนเมื่อใด เมื่อคุณตั้งเงื่อนไขให้กับช่อง คุณจะกรองการแจ้งเตือนตามเนื้อหาของตัวแปรหรือเฮดเดอร์ 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"

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

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

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

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

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

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

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

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

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

เมื่อช่องถูกทริกเกอร์ผ่าน 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"

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

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

เงื่อนไข (กรองว่าทริกเกอร์ใดจะส่งการแจ้งเตือน):

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 ทำอะไรได้อีกบ้าง

---

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