การตรวจสอบเอ็นด์พอยต์

Endpoint คืออะไร?

Endpoint คือทุกอย่างที่สามารถระบุตำแหน่งได้บนอินเทอร์เน็ตและสามารถร้องขอเพื่อตรวจสอบการเข้าถึงได้ กรณีคลาสสิกคือ URL ของหน้าเว็บ — แต่องค์ประกอบในโครงสร้างพื้นฐานยุคใหม่ที่คุณต้องดูแลมีความหลากหลายมากขึ้น: REST API, endpoint ของ GraphQL, เซิร์ฟเวอร์อีเมล, listener ของฐานข้อมูล, คิวข้อความ, port สำหรับตรวจสอบสุขภาพของ container, แผงควบคุมภายใน, ผู้รับ webhook DiagnoSEO Uptime Monitoring จัดการทุกอย่างแบบเดียวกัน: คุณกำหนดว่า "สุขภาพดี" สำหรับ endpoint นั้นหมายถึงอะไร ตั้งเวลาการตรวจสอบ แล้วรับการแจ้งเตือนเมื่อเกิดปัญหา

หน้านี้อธิบายประเภท endpoint แต่ละประเภทที่เครื่องมือรองรับ ว่าแต่ละประเภทเหมาะกับกรณีใด และสัญญาณที่ได้รับจากการตรวจสอบเป็นอย่างไร

Endpoint HTTP / HTTPS (หน้าเว็บไซต์)

กรณีเริ่มต้นทั่วไป คุณป้อน https://example.com แล้วตัวตรวจสอบจะส่งคำขอ GET ตามช่วงเวลาที่กำหนด (1 นาที, 5, 10, 30, หรือ 60 นาทีขึ้นอยู่กับแผนบริการ) การตรวจสอบที่สำเร็จหมายถึงมีการเชื่อมต่อ TCP, TLS handshake สำเร็จ (สำหรับ HTTPS), ได้รับการตอบกลับ HTTP ด้วยรหัสสถานะที่คาดหวัง (ค่าเริ่มต้น: 2xx หรือ 3xx) และสามารถเลือกคำสำคัญว่าต้องมี (หรือไม่มี) ในเนื้อหาเพื่อตรวจเช็คได้ การตรวจสอบจะบันทึก Time To First Byte, เวลาตอบรับรวม, ขนาดเนื้อหา, chain ของ redirect และชุด headers การตอบกลับทั้งหมด

Endpoint HTTP เหมาะสำหรับ: เว็บไซต์ตลาดออนไลน์, บล็อก, ร้านอีคอมเมิร์ซ, dashboard SaaS, พอร์ทัลเอกสาร — ทุกที่ที่ผู้คนเข้าเยี่ยมชมผ่าน browser

Endpoint API (REST / GraphQL / JSON-RPC)

API ต้องการมากกว่าแค่ "มีการตอบกลับ" — ต้องการ "ตอบกลับ ถูกต้อง" คุณตั้งค่าตัวตรวจสอบโดยกำหนด HTTP method เอง (GET, POST, PUT, DELETE, PATCH), custom headers (token auth, content-type), body ของ request (payload JSON สำหรับ POST/PUT) และ assertion ของ JSON ในการตอบกลับ (data.status ต้องเท่ากับ "ok", result.count ต้องมากกว่า 0, errors[] ต้องว่างเปล่า) API ที่ตอบ HTTP 200 พร้อม payload ที่เสียหายคือปัญหาเลวร้ายที่สุด — ดูเหมือนปกติสำหรับตัวตรวจสอบทั่วไปแต่สร้างปัญหาให้ลูกค้าทุกคน Assertion ของ JSON ทำให้คุณพบปัญหานี้

ดูคู่มือการ monitor API สำหรับรายละเอียดการตั้งค่าและไวยากรณ์ assertion

Endpoint port TCP

สำหรับบริการที่ไม่ใช่ HTTP: SMTP (port 25 / 587 / 465), POP3 (110 / 995), IMAP (143 / 993), listener ฐานข้อมูล (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), port custom ของแอปพลิเคชัน ตัว monitor จะเปิดการเชื่อมต่อ TCP ไปยัง host:port ที่กำหนด และรายงานสำเร็จหากการเชื่อมต่อได้รับการยอมรับภายในระยะเวลา timeout โดยไม่มี handshake บนระดับ protocol — แค่ "service กำลังรับฟังหรือไม่"

นี่คือ monitor ที่เหมาะสมสำหรับบริการทุกอย่างที่อยู่บน TCP ซึ่งคุณห่วงแค่เรื่องการเข้าถึงและไม่ต้องการตรวจระดับ protocol สำหรับการเช็ค banner SMTP หรือเช็คตาม query ฐานข้อมูล โปรดใช้ monitor แบบ heartbeat (บริการของคุณ ping หาเราขณะยังคงปกติ ดู cron-job / heartbeat monitoring)

Endpoint ping (ICMP)

การตรวจสอบการเข้าถึงบน layer 3 ตัว monitor จะส่งคำขอ ICMP echo ไปยัง hostname หรือ IP ปลายทาง รอการตอบกลับ เหมาะกับ router, switch, อุปกรณ์ IoT, และทุกอย่างที่ตอบสนองต่อ ping แม้จะไม่ได้รัน HTTP โปรดทราบว่าผู้ให้บริการคลาวด์หลายราย (AWS, GCP, Azure) ปิด ICMP ตามค่าเริ่มต้นใน security group ถึงแม้โฮสต์ยังปกติ — ใน workload cloud แนะนำให้ใช้ check HTTP หรือ port TCP

Endpoint hostname / DNS

การติดตามการแก้ไข DNS เครื่องมือจะตรวจสอบ record A, AAAA, MX, NS, TXT และ CNAME ของโดเมนคุณตามช่วงเวลา ทำ snapshot ของผลลัพธ์ และแจ้งเตือนหากพบการเปลี่ยนแปลง เหมาะสำหรับจับ: การยึด DNS โดยไม่มีสิทธิ์, ความผิดพลาดระหว่างย้ายผู้ให้บริการ DNS, บริการภายนอกที่อัปเดต endpoint โดยไม่แจ้ง (CDN ของคุณเปลี่ยน block IP ตัวอย่างเช่น), MX records ถูกลบจากการพิมพ์ผิด

Monitoring DNS ไม่ใช่เรื่องการเข้าถึง — ผู้ให้บริการ DNS ของคุณแทบจะเชื่อถือได้มากกว่า origin จุดสำคัญคือ ตรวจจับการเปลี่ยนแปลง ดูระบบ monitor การเปลี่ยนแปลงของ DNS สำหรับรายละเอียด

Endpoint ใบรับรอง SSL

ทุก endpoint HTTPS จะได้รับการ monitor SSL อัตโนมัติบน check uptime ของตัวเอง เครื่องมือจะอ่านข้อความรับรอง วิเคราะห์อายุการใช้งานและผู้ออกใบรับรอง พร้อมเตือนที่ 30, 14, 7, 3 และ 1 วันก่อนหมดอายุ ดู system monitor ใบรับรอง SSL สำหรับรายละเอียด

Endpoint วันหมดอายุโดเมน

สำหรับทุก URL ที่ monitor ระบบจะสอบถามข้อมูล WHOIS วันละครั้งและติดตามวันหมดอายุของการลงทะเบียนโดเมน การเตือนจะถูกตั้งไว้ที่ระดับเดียวกับ SSL (30/14/7/3/1 วัน) การต่ออายุล่าช้าอาจเป็นหายนะ — โดเมนจะไม่มีเจ้าของและอาจมีผู้อื่นลงทะเบียนทันทีที่หมดระยะเวลา grace ดู monitor วันหมดอายุโดเมน

การเลือกประเภท endpoint ที่เหมาะสม

หากไม่แน่ใจว่าจะใช้ monitor ชนิดใด แนะนำให้เริ่มด้วย HTTP/HTTPS สำหรับทุกอย่างที่มี UI เว็บ, TCP port สำหรับส่วนอื่น และเพิ่ม check heartbeat ให้กับงาน batch ที่ไม่มีบริการบนเครือข่าย คุณสามารถ monitor เป้าหมายเดียวกันได้หลายแบบ — เช่น check port TCP ที่ 443 จะพบกรณี "server ใช้งานได้แต่ TLS handshake มีปัญหา" ซึ่ง check HTTP บน URL เดียวกันจะ flag ไว้ ขณะที่ heartbeat จาก agent ภายในของคุณยืนยันตรรกะในแอปพลิเคชันทำงานจริง

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

• Endpoint คืออะไร?

  ทุกสิ่งที่สามารถระบุที่อยู่ได้บนอินเทอร์เน็ต: HTTP/HTTPS URL, REST API, port TCP (SMTP, MySQL, แบบกำหนดเอง), hostname สำหรับ ping, DNS records, ใบรับรอง SSL และข้อมูลทะเบียนโดเมน กำหนดหนึ่ง monitor ต่อหนึ่งประเภท endpoint

• ควรใช้ HTTP check หรือ TCP port check ดี?

  HTTP เป็นตัวเลือกเริ่มต้นที่ดีสำหรับบริการเว็บทุกประเภท TCP port เหมาะกับบริการที่ไม่ใช่ HTTP (ฐานข้อมูล, เซิร์ฟเวอร์อีเมล, protocol แบบ custom) เมื่อต้องการเพียง "service รับเชื่อมต่อหรือไม่" ใช้ TCP สำหรับตรวจสอบความพร้อมระดับต่ำ, HTTP สำหรับ "ระบบตอบกลับถูกต้องจริงหรือไม่"

• monitor heartbeat (cron-job) ต่างจากแบบอื่นอย่างไร?

  Heartbeat ทำงานกลับกัน — แทนที่เราจะตรวจสอบบริการของคุณ ให้บริการของคุณ ping หาเราที่ URL ที่กำหนดไว้ หากเราไม่ได้รับ ping ในเวลาที่คาดหมายจะทำการแจ้งเตือน เหมาะกับ cron job, งาน batch และทุกอย่างที่รันตามตารางเวลาโดยไม่มีจุดบริการบนเครือข่ายให้ตรวจ

• URL เดียวสามารถมี monitor หลายตัวได้ไหม?

  ได้ คุณสามารถ monitor เป้าหมายเดียวกันด้วย check หลายรูปแบบ เช่น HTTP check สำหรับความพร้อมใช้งานโดยรวมและ TCP port check ที่ 443 ที่ช่วยจับปัญหา TLS handshake ได้ แต่ละ monitor ทำงานและแจ้งเตือนแยกกันอิสระ

• ต้อง monitor SSL กับโดเมนแยกต่างหากไหม?

  ไม่ — ทุก endpoint HTTPS จะถูก monitor SSL อัตโนมัติบน check uptime ตัวเอง และทุก URL ที่ monitor จะถูกเช็ควันหมดอายุโดเมนทุกวัน ทั้งสองรายการรวมอยู่แล้วโดยไม่ต้อง config เพิ่ม Monitoring โดเมนเป็นแบบต่อโดเมน — monitor หลายตัวสำหรับโดเมนเดียวกันจะใช้ข้อมูล WHOIS ร่วมกัน