คำขอ HTTP

งาน HTTP จะแสดงว่าเว็บไซต์หรือเว็บเซอร์วิสเปิดได้ตามที่คุณคาดหวังในงานปกติหรือไม่

เมื่อไหร่ควรใช้

  • เมื่อต้องการตรวจสอบหน้าของเว็บไซต์, แดชบอร์ดส่วนตัว หรือ health endpoint
  • เมื่อต้องการตรวจสอบไม่เพียงแค่การเข้าถึงเซิร์ฟเวอร์ แต่ยังรวมถึง HTTP response ที่ถูกต้อง
  • เมื่อต้องการเห็นความล้มเหลวจากมุมมองของผู้ใช้ ไม่ใช่แค่พอร์ตที่เปิดอยู่

เมื่อไหร่ควรเลือกประเภทอื่น

  • หากต้องการตรวจสอบเพียงการเข้าถึงเครือข่ายพื้นฐานของเซิร์ฟเวอร์ มักใช้ Ping ก็พอ
  • หากสนใจเฉพาะวันหมดอายุของใบรับรอง SSL จะเหมาะกว่า
  • หากการตรวจสอบต้องรอสัญญาณจากกระบวนการภายนอก ให้ใช้ «เหตุการณ์ภายนอก»
โปรดทราบ: สำหรับการตรวจสอบหลัก ควรเลือก URL ที่สะท้อนสถานะการทำงานจริงของเซอร์วิส ไม่ใช่หน้าสุ่มที่อาจเปลี่ยนแปลงจากระบบล็อกอิน, โฆษณา หรือการปรับแต่งส่วนบุคคล

ฟิลด์ทั่วไปของฟอร์ม

ฟิลด์ ความหมาย ควรใส่อะไร ตัวอย่าง
เปิดใช้งานงาน กำหนดว่าการตรวจสอบจะเริ่มทันทีหลังบันทึกหรือไม่ ทิ้งงานให้เปิดใช้งาน หากต้องการเริ่มตรวจสอบทันที เปิดใช้งาน
ชื่อ ชื่อการตรวจสอบในรายการและการแจ้งเตือน ระบุสิ่งที่กำลังตรวจสอบ หน้าหลัก example.com
กลุ่ม ช่วยจัดงานให้อยู่ในโปรเจกต์หรือหมวดหมู่ เลือกกลุ่มหากต้องการให้งานของโปรเจกต์อยู่ด้วยกัน เว็บไซต์ example.com
ช่วงเวลา ความถี่ในการทำ HTTP check เลือกช่วงตามความสำคัญของหน้าเว็บหรือเซอร์วิส 5 นาที
ช่องทางการแจ้งเตือน ส่งข้อความปัญหาและการกู้คืนไปที่ไหน เลือกช่องที่คุณอ่านการแจ้งเตือนจริงๆ Telegram และ email
รายงาน สรุปรายงานตามรอบของงาน เปิดใช้งานหากต้องการภาพรวมโดยไม่ต้องเข้าหน้าจอด้วยตัวเอง รายงานรายสัปดาห์

ฟิลด์การตรวจสอบ HTTP

ฟิลด์ ความหมาย ควรใส่อะไร ตัวอย่าง
เมธอด HTTP request ที่จะถูกส่ง โดยปกติ GET ก็พอ เมธอดอื่นใช้เมื่อ endpoint ต้องการเฉพาะ GET
URL ที่อยู่เต็มของหน้าเว็บหรือ endpoint ที่ต้องตรวจสอบ ระบุ URL เต็มพร้อม scheme และโดเมน https://example.com/health
ไทม์เอ้าท์ รอการตอบสนองนานแค่ไหนก่อนถือว่าไม่สามารถเข้าถึงได้ เลือกค่าที่สูงกว่าระยะเวลาตอบสนองปกติของเซอร์วิสเล็กน้อย 30 วินาที
คำสำคัญ การตรวจสอบเนื้อหาการตอบสนองเพิ่มเติม ระบุข้อความที่ต้องมีใน response OK
การตั้งค่าขั้นสูง เปิดฟิลด์ HTTP เพิ่มเติม เปิดเฉพาะเมื่อต้องการ header, body request หรือรายการ status code ที่ประสบความสำเร็จเอง เปิดใช้งาน
ส่วนหัว HTTP header เพิ่มเติมของ request เพิ่มเฉพาะ header ที่ API ของคุณต้องการจริงๆ Authorization: Bearer <token>
Accept: application/json
เนื้อหา Body ของ HTTP request สำหรับ POST, PUT หรือ PATCH กรอกเมื่อ endpoint รอ JSON หรือ body อื่น {"event":"healthcheck"}
รหัสตอบสนองที่ประสบความสำเร็จ HTTP code ไหนถือเป็นผลลัพธ์ปกติ ทิ้งช่วงมาตรฐานไว้ หรือกำหนด code และช่วงเอง 200-299, 301
อนุญาตใบรับรองที่ลงนามด้วยตนเอง ไม่ถือว่าเป็นข้อผิดพลาดใบรับรองที่เบราว์เซอร์ไม่เชื่อถือ เปิดใช้งานสำหรับบริการภายในโดย HTTPS ด้วยใบรับรองของคุณเอง ปิดใช้งาน
จุดตรวจสอบที่อนุญาต การตรวจสอบจะมาจุดไหน ทิ้งทุกจุดไว้ หากไม่ต้องการสถานการณ์พิเศษตามภูมิภาคหรือเครือข่าย ทุกจุดตรวจสอบ

เมื่อไหร่จะมีสัญญาณเตือน

  • เว็บไซต์หรือ endpoint ไม่ตอบสนองทันเวลา
  • เซิร์ฟเวอร์ส่ง code ที่ไม่อยู่ในรายการที่ประสบความสำเร็จ
  • การตอบสนองไม่มีข้อความที่กำหนด หากระบุคำสำคัญ
  • สำหรับที่อยู่โดย HTTPS ไม่สามารถสร้างการเชื่อมต่อที่ปลอดภัยได้: ใบรับรองหมดอายุ ไม่เชื่อถือ หรือออกให้ชื่ออื่น สาเหตุของการตรวจสอบจะระบุว่ามีปัญหาอะไรแน่นอน
กำลังตรวจสอบบริการภายใน? หากโปรแกรมทำงานโดย HTTPS ด้วยใบรับรองที่ลงนามด้วยตนเอง เปิดใช้งาน «การตั้งค่าขั้นสูง» และทำเครื่องหมาย «อนุญาตใบรับรองที่ลงนามด้วยตนเอง» — มิฉะนั้นการตรวจสอบจะล้มเหลวเนื่องจากการไม่เชื่อถือใบรับรอง แม้ว่าเซอร์วิสตัวเองจะตอบสนองได้ปกติ

การตั้งค่าการแจ้งเตือน

สำหรับแต่ละช่องทางการแจ้งเตือนในงาน สามารถกำหนดพารามิเตอร์เพิ่มเติมได้ พารามิเตอร์เหล่านี้ใช้เฉพาะกับเหตุการณ์ DOWN

พารามิเตอร์ ทำอะไร
เปิดใช้งาน อนุญาตหรือห้ามส่งการแจ้งเตือนช่องนี้สำหรับงานนี้
เลื่อน PRO ชักการแจ้งเตือน DOWN ครั้งแรกตามเวลาที่เลือก (สูงสุด 12 ชั่วโมง) สะดวกสำหรับหลีกเลี่ยงการแจ้งเตือนจากความล้มเหลวชั่วคราว
ทำซ้ำหลัง PRO ทำซ้ำการแจ้งเตือนเป็นระยะขณะที่งานยังคงสถานะ DOWN (สูงสุด 1 ชั่วโมงระหว่างการทำซ้ำ) เหมาะสำหรับกรณีที่สำคัญไม่ให้พลาดการขัดข้องยืดเยื้อ
พารามิเตอร์ «เลื่อน» และ «ทำซ้ำ» ไม่มีผลต่อเหตุการณ์ UP และการแจ้งเตือนการกู้คืน
ไปยังรายการประเภทงาน