แจ้งเตือนแบบโทรเข้าจาก Sentry สำหรับข้อผิดพลาดร้ายแรง

สารบัญ

• ทำไม Sentry ถึงทำให้โทรศัพท์ดังเองไม่ได้
• สิ่งที่ต้องมี
• ขั้นที่ 1 — สร้างช่องที่ดัง
• ขั้นที่ 2 — สร้าง internal integration ใน Sentry
• ขั้นที่ 3 — เพิ่มตัวเชื่อมต่อเป็นแอ็กชันของกฎ
• ขั้นที่ 4 — รู้ว่าอะไรมาถึงจริง ๆ
• ขั้นที่ 5 — กรองให้เหลือเฉพาะสิ่งที่คู่ควรกับสายโทรเข้า
• ขั้นที่ 6 — เปิดประตูที่เงียบกว่าให้คำเตือน
• ให้ดังเฉพาะนอกเวลาทำงาน
• กับดักสองข้อ
• ขนาดข้อมูล พายุข้อผิดพลาด และการตัดข้อความ
• แชร์กับทีม
• สิ่งที่การตั้งค่านี้ไม่ได้ให้
• การแก้ปัญหา
• คำถามที่พบบ่อย
• Sentry โทรออกเองได้ไหม
• การแจ้งเตือนจาก Sentry ทะลุโหมดห้ามรบกวนไหม
• ต้องใช้แพ็กเกจ Sentry แบบเสียเงินไหมถึงจะใช้เว็บฮุกได้
• ทำไมตัวแปรในเทมเพลตถึงว่าง
• จะแจ้งเตือนเฉพาะสภาพแวดล้อมเดียวได้อย่างไร
• ให้สองคนรับสายจากข้อผิดพลาดเดียวกันได้ไหม
• ควรกรองที่ Sentry หรือที่ Echobell
• สรุป
• บทความที่เกี่ยวข้อง

Sentry โทรหาคุณไม่ได้ มันส่งอีเมลได้ โพสต์ลง Slack ได้ หรือส่งต่อการแจ้งเตือนให้ PagerDuty ได้ แต่ไม่มีแอ็กชันเสียงในตัว วิธีได้สิ่งนี้มาโดยไม่ต้องซื้อแพลตฟอร์มจัดการเหตุการณ์ คือส่ง issue alert ของ Sentry ไปยังเว็บฮุกที่ "ดัง" นั่นคือสร้าง internal integration ชี้ไปที่ช่องแบบโทรเข้าของ Echobell แล้ววางตัวกรองไว้ข้างหน้า เพื่อให้ผ่านเฉพาะข้อผิดพลาดที่ทำให้โปรดักชันพังจริง ๆ

คู่มือนี้ครอบคลุมเส้นทางทั้งหมด: ตัวเชื่อมต่อ กฎการแจ้งเตือน ข้อมูลที่ Sentry ส่งมาจริง เทมเพลตที่อ่านข้อมูลนั้น และกับดักสองข้อที่ทำให้คนล้มเลิกกลางทาง

ทำไม Sentry ถึงทำให้โทรศัพท์ดังเองไม่ได้

แอ็กชันของ issue alert ใน Sentry ครอบคลุมการแจ้งเตือน (อีเมล, Slack, Discord, Microsoft Teams) การสร้างทิกเก็ต (Jira, GitHub, Azure DevOps) และการส่งต่อให้ผลิตภัณฑ์เพจจิง (PagerDuty, Opsgenie) ทุกทางจบลงที่หน้าจอที่คุณต้องกำลังมองอยู่ หรือที่นั่งแบบเสียเงินบนอีกแพลตฟอร์มหนึ่ง

ตอนบ่ายสองก็ไม่มีปัญหา แต่ตอนตีสาม ข้อความใน Slack แทบไม่ต่างจากความเงียบ และการแจ้งเตือนแบบพุชก็แพ้โหมดห้ามรบกวน สำหรับข้อผิดพลาดกลุ่มเล็ก ๆ ที่ช้าไปสองชั่วโมงแล้วเสียเงินจริง — หน้าชำระเงินคืนค่า 500, การยืนยันตัวตนปฏิเสธทุกการล็อกอิน, เวิร์กเกอร์ทิ้งงานเงียบ ๆ — คุณต้องการอุปกรณ์ที่ดัง

เว็บฮุกคือรอยต่อนั้น Sentry เรียกปลายทาง HTTPS ใด ๆ เป็นแอ็กชันของกฎแจ้งเตือนได้ ส่วน Echobell เปลี่ยนคำขอ HTTP นั้นให้เป็นการแจ้งเตือนแบบสายเรียกเข้าที่ทะลุโหมดโฟกัสของ iOS

สิ่งที่ต้องมี

• องค์กรใน Sentry ที่คุณเข้าถึง Settings → Developer Settings ได้ (owner หรือ manager)
• ติดตั้ง Echobell แล้ว (App Store / Google Play)
• เวลาห้านาที

ฝั่งคุณไม่ต้องมีอะไรที่เข้าถึงได้จากอินเทอร์เน็ตเลย Sentry เป็นฝ่ายยิงคำขาออก คุณแค่รับ

ขั้นที่ 1 — สร้างช่องที่ดัง

ใน Echobell สร้างช่องใหม่แล้วตั้งประเภทการแจ้งเตือนเป็น โทรเข้า (Calling) นี่คือหัวใจของทั้งหมด: ช่องแบบโทรเข้าทำงานเหมือนสายเรียกเข้า ไม่ใช่การแจ้งเตือนแบบพุช จึงทะลุโหมดโฟกัสและห้ามรบกวนได้

ใส่เทมเพลตที่อ่านแล้วเข้าใจตอนตีสาม ข้อมูลของ Sentry ซ้อนกันหลายชั้น เส้นทางของตัวแปรจึงยาวกว่าปกติ:

หัวเรื่อง: {{data.event.level}}: {{data.event.metadata.type}}
เนื้อหา: {{data.event.title}} — {{data.event.culprit}}

ตั้ง เทมเพลตลิงก์ ในการตั้งค่าขั้นสูง เพื่อให้แตะการแจ้งเตือนแล้วเปิด issue ได้ทันที:

{{data.event.web_url}}

คัดลอก URL เว็บฮุกจากหน้ารายละเอียดช่อง หน้าตาเป็นแบบนี้:

https://hook.echobell.one/t/<channel-token>

ขั้นที่ 2 — สร้าง internal integration ใน Sentry

Sentry เปิดให้ใช้เว็บฮุกเป็นแอ็กชันของกฎแจ้งเตือนผ่าน integration เท่านั้น คุณจึงต้องสร้างขึ้นมาหนึ่งอัน มันเป็นแค่ฟอร์ม ไม่ใช่เซอร์วิส — ไม่ต้องเขียนโค้ดสักบรรทัด

1. ไปที่ Settings → Developer Settings → Custom Integrations
2. Create New Integration → Internal Integration
3. Name: Echobell (ชื่อนี้คือสิ่งที่คุณจะเลือกในกฎแจ้งเตือน)
4. Webhook URL: URL ของช่องจากขั้นที่ 1
5. เปิด สวิตช์ Alert Rule Action
6. Permissions: Issue & Event → Read ก็พอ
7. ใต้หัวข้อ Webhooks ให้ปล่อยช่องติ๊ก ทั้งหมดว่างไว้ — ดูกับดักด้านล่าง
8. บันทึก

internal integration ใช้ได้เฉพาะในองค์กรของคุณและติดตั้งตัวเอง โทเคนที่มันสร้างขึ้นไม่จำเป็นต้องใช้ในการตั้งค่านี้เลย

ขั้นที่ 3 — เพิ่มตัวเชื่อมต่อเป็นแอ็กชันของกฎ

ไปที่ Alerts → Create Alert → Issue Alert หรือแก้กฎเดิมที่มีอยู่

ใต้ Then perform these actions เพิ่ม Send a notification via an integration แล้วเลือก Echobell

ตั้ง Action interval — ตัวจำกัดแบบ "ถ้าการแจ้งเตือนนี้ทำงานมากกว่าหนึ่งครั้ง" — ไว้อย่างน้อย 30 minutes ค่าเริ่มต้นคือส่งทุกครั้งที่ทำงาน และข้อผิดพลาดที่ยิง 400 ครั้งต่อนาทีจะโทรหาคุณไปเรื่อย ๆ จนกว่าคุณจะปิดมันทิ้ง

บันทึกแล้วกดทดสอบกฎ เพื่อเห็นข้อมูลจริงมาถึงก่อนจะไว้ใจเส้นทางนี้

ขั้นที่ 4 — รู้ว่าอะไรมาถึงจริง ๆ

จุดนี้คือที่ที่การตั้งค่าส่วนใหญ่พัง เพราะรูปร่างของข้อมูลไม่เหมือนที่เดา Sentry ห่อทุกอย่างไว้:

{
  "action": "triggered",
  "actor": { "id": "sentry", "name": "Sentry", "type": "application" },
  "data": {
    "event": {
      "event_id": "e4874d664c3540c1a32eab185f12c5ab",
      "level": "error",
      "title": "ReferenceError: heck is not defined",
      "culprit": "?(<anonymous>)",
      "platform": "javascript",
      "project": 1,
      "release": null,
      "metadata": { "type": "ReferenceError", "value": "heck is not defined" },
      "tags": [["level", "error"], ["browser", "Chrome 75.0.3770"]],
      "issue_id": "1117540176",
      "issue_url": "https://sentry.io/api/0/issues/1117540176/",
      "web_url": "https://sentry.io/organizations/test-org/issues/1117540176/events/e4874.../"
    },
    "triggered_rule": "Very Important Alert!"
  },
  "installation": { "uuid": "a8e5d2..." }
}

สี่เรื่องที่ควรรู้ก่อนเขียนเทมเพลตแม้แต่บรรทัดเดียว:

• ของที่ใช้ได้จริงอยู่ใต้ data.event ทั้งหมด {{title}} จะไม่แสดงอะไรเลย ส่วน {{data.event.title}} จึงจะได้ข้อความข้อผิดพลาด
• data.event.project เป็น ID ตัวเลข ไม่ใช่ slug ถ้าอยากให้ชื่อโปรเจกต์อ่านออกในการแจ้งเตือน ให้พิมพ์เป็นข้อความตรง ๆ ในเทมเพลตหัวเรื่อง และใช้หนึ่งช่องต่อหนึ่งโปรเจกต์
• ไม่มีฟิลด์ environment สภาพแวดล้อมมาในรูปคู่ ["environment", "production"] ภายใน data.event.tags และตำแหน่งในอาร์เรย์ไม่คงที่ — อย่าอ้างอิงด้วยดัชนี ให้กรองสภาพแวดล้อมในกฎของ Sentry แทน (ขั้นที่ 5)
• data.triggered_rule คือชื่อกฎ มีประโยชน์ในเนื้อหาเมื่อช่องเดียวรองรับหลายกฎ

เฮดเดอร์ Sentry-Hook-Resource มีค่าเป็น event_alert สำหรับ issue alert คุณกำหนดให้เงื่อนไขของช่องต้องเจอค่านี้ได้ เพื่อไม่ให้สิ่งอื่นมาทำให้ช่องดัง:

header["sentry-hook-resource"] == "event_alert"

ขั้นที่ 5 — กรองให้เหลือเฉพาะสิ่งที่คู่ควรกับสายโทรเข้า

ช่องแบบโทรเข้าที่ดังทุกครั้งที่มี issue ใหม่ แย่กว่าการไม่มีช่องเลย เพราะภายในหนึ่งสัปดาห์คุณจะปิดเสียงมัน แล้วตอนที่สำคัญจริงมันก็จะไม่ดัง ให้กรองสองจุด

ฝั่ง Sentry ใช้ conditions และ filters ของกฎ:

ฝั่ง Echobell ใช้เงื่อนไขของช่องเป็นตาข่ายนิรภัย สำหรับสิ่งที่ Sentry แสดงออกไม่ได้ หรือการแก้ไขที่วันนี้ยังส่งขึ้นไม่ได้:

data.event.level == "fatal" || data.event.level == "error"

โดยทั่วไปการกรองระดับความรุนแรงในกฎของ Sentry ดีกว่า เพราะการจำกัดความถี่ก็อยู่ที่เดียวกัน ส่วนการกรองใน Echobell ดีกว่าเมื่อคุณอยากได้ความเร่งด่วนสองระดับจากกฎเดียว

ขั้นที่ 6 — เปิดประตูที่เงียบกว่าให้คำเตือน

จุดประสงค์ของการแบ่งระดับคือให้สายโทรเข้ายังคงน้ำหนักของมันไว้ สร้างช่อง Echobell ช่องที่สองเป็นประเภท สำคัญตามเวลา (Time Sensitive) เพิ่มกฎ Sentry ข้อที่สองที่เกณฑ์ต่ำลง แล้วชี้ไปยัง internal integration ตัวที่สอง (หนึ่งตัวเชื่อมต่อเก็บได้หนึ่ง URL เว็บฮุก ช่องที่สองจึงต้องมีตัวเชื่อมต่อที่สอง)

การตั้งค่าที่รอดผ่านสัปดาห์จริง ๆ ได้ หน้าตาประมาณนี้:

ให้ดังเฉพาะนอกเวลาทำงาน

กลางวันคุณก็จ้อง Sentry อยู่แล้ว Echobell มีตัวแปรเวลาระบบแบบ UTC ให้ใช้ในเงื่อนไข ช่องเดียวจึงทำงานต่างกันตามช่วงเวลาได้ โดยไม่ต้องเพิ่มกฎที่สองใน Sentry:

data.event.level == "fatal" && (hour >= 17 || hour < 9)

เพิ่มการตรวจวันในสัปดาห์ด้วย ถ้าวันหยุดของคุณหยุดจริง:

data.event.level == "fatal" && (hour >= 17 || hour < 9 || dayOfWeek == 0 || dayOfWeek == 6)

ทั้งหมดนี้เป็น UTC จึงควรแปลงจากเขตเวลาของคุณก่อนจะล็อกตัวเลข รายการตัวแปรทั้งหมดอยู่ในคู่มืออ้างอิงเงื่อนไข

กับดักสองข้อ

กับดักที่ 1: ติ๊กช่อง Webhooks internal integration มีเส้นทางเว็บฮุกสองเส้นที่แยกจากกัน สวิตช์ Alert Rule Action ทำให้ตัวเชื่อมต่อถูกเลือกได้ในกฎแจ้งเตือน — อันนี้คือสิ่งที่คุณต้องการ ส่วนช่องติ๊ก Webhooks (issue, error, comment) จะสมัครรับ ทุก เหตุการณ์ของทรัพยากรนั้น: ทุกครั้งที่มี issue ถูกสร้าง แก้ไขเสร็จ มอบหมาย เก็บเข้าคลัง หรือถูกเพิกเฉย ทั่วทั้งองค์กร ถ้าติ๊ก issue โทรศัพท์คุณจะดังทุกครั้งที่เพื่อนร่วมทีมปิดงานสักชิ้น ปล่อยว่างไว้ทั้งหมด แล้วจะมีแต่กฎแจ้งเตือนของคุณเท่านั้นที่ยิงเว็บฮุก

กับดักที่ 2: ใช้ปลั๊กอิน Webhooks แบบเก่า ปลั๊กอินระดับโปรเจกต์ตัวเก่า Legacy Integrations → WebHooks ยังอยู่และยังทำงานได้ และดูเหมือนทางลัดเพราะแปะ URL ได้เลยโดยไม่ต้องสร้างตัวเชื่อมต่อ แต่ข้อมูลของมันมีรูปร่างต่างออกไปและแบนกว่า คำขอไม่ถูกลงลายเซ็น และ Sentry เองก็พาการตั้งค่าใหม่ ๆ ออกห่างจากมัน ถ้าคุณใช้ตัวนี้ เทมเพลตของคุณจะต้องใช้เส้นทางตัวแปรคนละแบบกับข้างต้น ให้ใช้ internal integration

ขนาดข้อมูล พายุข้อผิดพลาด และการตัดข้อความ

สามขีดจำกัดที่ควรรู้ก่อนจะมีปัญหาตอนสเกลใหญ่:

• บอดี้ 1 MiB Echobell ปฏิเสธบอดี้ของทริกเกอร์ที่เกิน 1 MiB ด้วย HTTP 413 ข้อมูลจาก Sentry พ่วงสแต็กเทรซเต็มและบริบทของคำขอมาด้วย ปกติจึงอยู่ในระดับหลายสิบกิโลไบต์ แต่เหตุการณ์ที่มีบอดี้คำขอขนาดใหญ่อาจเข้าใกล้ขีดจำกัดได้ ฝั่ง Sentry ไม่มีปุ่มแบบ max_alerts ทางแก้จึงเป็นการล้างบอดี้คำขอขนาดใหญ่ใน beforeSend ของ SDK ซึ่งยังไงก็ควรทำอยู่แล้วด้วยเหตุผลด้านความเป็นส่วนตัว
• 120 คำขอต่อนาทีต่อโทเคน เกินกว่านั้นทริกเกอร์จะตอบ 429 พร้อม RATE_LIMIT_EXCEEDED และ Retry-After สิ่งที่ทำให้คุณอยู่ใต้เพดานคือ action interval ของ Sentry ซึ่ง 30 minutes นั้นเหลือเฟือ
• เนื้อหาการแจ้งเตือน 1500 ไบต์ ที่ยาวกว่านั้นจะถูกตัดก่อนถึงเครื่อง data.event.title บวก culprit พอดีสบาย ๆ แต่การเทค่า data.event.exception ทั้งก้อนลงไปไม่พอ และบนหน้าจอล็อกก็อ่านไม่รู้เรื่องอยู่ดี เก็บรายละเอียดไว้หลังเทมเพลตลิงก์

แชร์กับทีม

ช่องของ Echobell ให้หลายคนสมัครรับได้ และผู้สมัครแต่ละคนเลือกประเภทการแจ้งเตือนของตัวเอง กฎ Sentry ข้อเดียวจึงทำให้โทรศัพท์ของคนที่เข้าเวรดัง ขณะที่คนอื่นได้เป็นพุชธรรมดา — ไม่มีค่าใช้จ่ายรายหัว ไม่ต้องตั้งค่าตารางเวร

แต่มันไม่ใช่นโยบายการยกระดับ ไม่มี "ถ้าไม่มีใครรับใน 5 นาทีให้โทรหาคนถัดไป" ถ้าคุณต้องการแบบนั้น คุณต้องใช้แพลตฟอร์มออนคอลจริงจัง ส่วน Echobell ดูแลชั้นการส่งมอบที่อยู่ข้างใต้

สิ่งที่การตั้งค่านี้ไม่ได้ให้

พูดตรง ๆ ดีกว่า:

• ไม่มีการตอบรับ (ack) การรับสายไม่ได้บอกอะไร Sentry และไม่ได้หยุดโทรศัพท์ของผู้สมัครรับคนอื่น
• ไม่มีตารางเวรหรือการยกระดับ ทุกคนที่สมัครรับได้เหมือนกันหมด หรือไม่ได้เลย
• ไม่มีการตัดซ้ำนอกเหนือจากที่ Sentry ทำ การจัดกลุ่มและการจำกัดความถี่เกิดในกฎของ Sentry ส่วน Echobell ส่งสิ่งที่มาถึง
• ไม่มีการซิงก์สองทาง การปิด issue ใน Sentry ไม่ได้ล้างอะไรบนโทรศัพท์ของคุณ

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

การแก้ปัญหา

กฎทำงานแต่ไม่มีอะไรมาถึง ตรวจว่า Alert Rule Action เปิดอยู่ในตัวเชื่อมต่อหรือไม่ ถ้าปิดอยู่ ตัวเชื่อมต่อจะไม่โผล่ในรายการแอ็กชันของกฎเลย และกฎที่บันทึกไว้ก่อนคุณเปิดสวิตช์จะยังเก็บแอ็กชันเก่าค้างไว้

การแจ้งเตือนมาถึงแต่ว่างเปล่า เทมเพลตของคุณกำลังอ่านคีย์ชั้นบนสุด Sentry ซ้อนทุกอย่างไว้ใต้ data.event

ดังในเรื่องที่ไม่ได้คาดไว้ ตรวจช่องติ๊ก Webhooks บนตัวเชื่อมต่อก่อน (กับดักที่ 1) จากนั้นดูว่าสภาพแวดล้อมของกฎยังค้างที่ "All Environments" หรือเปล่า

ดังซ้ำ ๆ จากข้อผิดพลาดเดียว เพิ่มค่า action interval ของกฎใน Sentry ส่วนการลองใหม่ของ Echobell เป็นคนละเรื่อง — ลองโทรซ้ำเมื่อสายไม่สำเร็จ ในการตั้งค่าแอปคือการโทรกลับเมื่อคุณพลาดสาย

ไม่เคยได้อะไรเลย แม้แต่การทดสอบ ลองยิงช่องด้วย curl ก่อน เพื่อตัดฝั่ง Echobell ออก:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H 'Content-Type: application/json' \
  -d '{"data":{"event":{"level":"fatal","title":"Test error","culprit":"manual test","metadata":{"type":"TestError"}}}}'

ถ้าอันนี้ดังแต่ Sentry ไม่ดัง ปัญหาอยู่ที่ตัวเชื่อมต่อ ไม่ใช่ที่ช่อง

คำถามที่พบบ่อย

Sentry โทรออกเองได้ไหม

ไม่ได้ แอ็กชันของ issue alert ใน Sentry มีแค่การแจ้งเตือน การสร้างทิกเก็ต และการเชื่อมต่อกับผลิตภัณฑ์เพจจิง การโทรด้วยเสียงต้องอาศัยบริการภายนอก ไม่ว่าจะเป็นแพลตฟอร์มเพจจิงอย่าง PagerDuty หรือตัวรับเว็บฮุกที่ดังได้อย่าง Echobell

การแจ้งเตือนจาก Sentry ทะลุโหมดห้ามรบกวนไหม

เฉพาะเมื่อมาถึงในรูปการแจ้งเตือนแบบสายเรียกเข้าเท่านั้น ช่อง Echobell ประเภทโทรเข้าทำงานเหมือนสายเรียกเข้า ซึ่งโหมดโฟกัสและห้ามรบกวนของ iOS ยอมให้ผ่าน ส่วนพุชธรรมดาจากแอปใดก็ตามนั้นไม่ผ่าน

ต้องใช้แพ็กเกจ Sentry แบบเสียเงินไหมถึงจะใช้เว็บฮุกได้

internal integration และแอ็กชันของกฎแจ้งเตือนใช้ได้ตั้งแต่แพ็กเกจ Developer ขึ้นไป ตัวเว็บฮุกเองไม่มีค่าใช้จ่ายเพิ่ม

ทำไมตัวแปรในเทมเพลตถึงว่าง

เกือบทุกครั้งเป็นเพราะเส้นทางสั้นเกินไป ข้อมูลของการแจ้งเตือนซ้อนอีเวนต์ไว้ใต้ data.event จึงต้องเป็น {{data.event.title}} ไม่ใช่ {{title}} ลองยิงช่องหนึ่งครั้งแล้วดูบอดี้คำขอที่บันทึกไว้ในแอป เพื่อเห็นรูปร่างที่ได้รับจริง

จะแจ้งเตือนเฉพาะสภาพแวดล้อมเดียวได้อย่างไร

ตั้งค่าฟิลด์ Environment บนกฎแจ้งเตือนของ Sentry อย่าพยายามอ่านจาก data.event.tags เพราะเป็นอาร์เรย์ของคู่ [คีย์, ค่า] ที่ไม่รับประกันลำดับ

ให้สองคนรับสายจากข้อผิดพลาดเดียวกันได้ไหม

ได้ แชร์ช่องแล้วให้แต่ละคนสมัครรับด้วยประเภทการแจ้งเตือนที่ต้องการ เนื่องจากไม่มีการตอบรับ ทุกคนที่เลือก "โทรเข้า" จะได้รับสายทั้งหมด

ควรกรองที่ Sentry หรือที่ Echobell

ที่ Sentry เมื่อทำได้ เพราะกฎยังเป็นที่อยู่ของการจำกัดความถี่และขอบเขตสภาพแวดล้อมด้วย ส่วนที่ Echobell เหมาะเมื่อคุณอยากได้ความเร่งด่วนสองระดับจากกฎเดียว เมื่อต้องการช่วงเวลาเฉพาะ หรือเมื่อวันนี้ยังแก้กฎไม่ได้

สรุป

การตั้งค่านี้มีสี่อย่าง: ช่องแบบโทรเข้า, internal integration ที่เปิด Alert Rule Action และไม่ติ๊กช่อง Webhooks, กฎแจ้งเตือนที่แคบพอจะคู่ควรกับสายโทรเข้า และเทมเพลตที่อ่าน data.event ทุกอย่างที่เหลือในหน้านี้ล้วนว่าด้วยการรักษาให้มันแคบพอ เพื่อให้อีกหนึ่งเดือนข้างหน้าเสียงกริ่งนั้นยังมีความหมายอยู่

ดาวน์โหลด Echobell สำหรับ iPhone หรือ รับบน Google Play แล้วยิง curl ด้านบนสักครั้ง ก่อนจะฝากเรื่องสำคัญจริง ๆ ไว้กับเส้นทางนี้

บทความที่เกี่ยวข้อง

• คู่มืออ้างอิงเงื่อนไขของช่อง
• คู่มือการเชื่อมต่อเว็บฮุก
• คู่มือนักพัฒนาเรื่องความล้าจากการแจ้งเตือน
• แจ้งเตือนแบบโทรเข้าจาก Prometheus Alertmanager
• ทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนสำคัญ