Ping monitoring ใช้ทำอะไร?

ตรวจสอบการเข้าถึงในระดับเลเยอร์ 3 — host ตอบสนองต่อ ICMP echo หรือไม่ เหมาะกับ router, switch, อุปกรณ์ IoT, โครงสร้างพื้นฐานภายใน และทุกอย่างที่ไม่ได้ run ด้วย HTTP แต่ควรจะออนไลน์และเข้าถึงได้

ทำไม server AWS/cloud ของฉันไม่ผ่านการตรวจ ping?

ผู้ให้บริการคลาวด์ส่วนใหญ่บล็อก ICMP เป็นค่าเริ่มต้นที่ security-group หรือ firewall เซิร์ฟเวอร์อาจยังปกติแต่ไม่ตอบสนองต่อ ping ใน workload คลาวด์ให้เลือกตรวจสอบแบบ HTTP หรือ TCP port แทน คุณสามารถอนุญาต ICMP แบบเจาะจงที่ security groups ได้หากจำเป็นต้องใช้ ping จริงๆ

ping กับการเช็ค TCP port ต่างกันอย่างไร?

ping ใช้ ICMP (ไม่มีพอร์ต — ตรวจสอบหมายเลขเลเยอร์ 3 อย่างเดียว) TCP port จะเปิดการเชื่อมต่อ TCP ที่พอร์ตที่กำหนด ยืนยันการเชื่อมต่อเลเยอร์ 4 host อาจผ่าน ping แต่ fail ที่ TCP (firewall บล็อก port) หรือในทางกลับกัน (ICMP โดนบล็อกแต่ port เปิด)

ตรวจวัด round-trip time ของ ping หรือไม่?

ใช่ — เวลาตอบสนอง (round-trip) ถูกบันทึกทุกครั้งที่ตรวจสอบและติดตามเป็นสถิติย้อนหลัง เหมาะสำหรับการจับสัญญาณเสื่อมสภาพของเครือข่าย: host เดิมแต่ RTT เพิ่มจาก 20ms เป็น 200ms สื่อว่าเกิดปัญหา routing หรือ network congestion

ping IP ภายในได้หรือไม่?

ได้ ก็ต่อเมื่อ IP นั้นสามารถเข้าถึงได้จาก server checker ของเรา - หมายถึงต้องเป็น public IP ช่วง private ตาม RFC1918 (192.168.x.x, 10.x.x.x, 172.16-31.x.x) จะใช้กับการตรวจสอบจากภายนอกไม่ได้ ถ้าเป็นโครงสร้างพื้นฐานภายในให้รัน self-hosted heartbeat agent ภายในเครือข่ายเพื่อ ping หาเรา

การตรวจสอบ Ping — ตรวจสอบการเข้าถึง TCP

ยืนยันว่าเซิร์ฟเวอร์ของคุณทำงานที่เลเยอร์เครือข่ายโดยไม่ขึ้นกับบริการเว็บใด ๆ ที่ทำงานอยู่ข้างบน

ทำไมต้องมีการ ping ในเมื่อมีการมอนิเตอร์ HTTP อยู่แล้ว

การมอนิเตอร์ HTTP จะบอกว่าหน้าเว็บตอบสนองถูกต้องหรือไม่ ส่วนการมอนิเตอร์ ping จะบอกว่าเครื่องเซิร์ฟเวอร์ยังสามารถเข้าถึงได้หรือไม่ ทั้งสองคำถามแตกต่างกัน และความแตกต่างนี้สำคัญเมื่อเกิดปัญหา หากแอปเว็บล่มแต่เซิร์ฟเวอร์ยังปกติ HTTP จะล้มเหลว - ping ยังผ่าน ซึ่งจะช่วยจำกัดขอบเขตในการวิเคราะห์ปัญหาได้ทันที หากทั้งสองล้มเหลว - อาจเป็นปัญหาเครือข่ายหรือโครงสร้างพื้นฐาน หากล้มเหลวแค่ ping - อาจเป็นเพราะ firewall เริ่มบล็อกการ ping แต่ HTTP ยังใช้ได้สำหรับผู้ใช้

การมอนิเตอร์ ping ก็เป็นเครื่องมือที่เหมาะสำหรับโฮสต์ที่ไม่ได้ให้บริการ HTTP: เซิร์ฟเวอร์ฐานข้อมูล, เมลเซิร์ฟเวอร์, แอปเซิร์ฟเวอร์ที่อยู่หลัง load balancer, เกตเวย์ VPN, ระบบภายในองค์กร - ทุกที่ที่คุณแค่ต้องการทราบว่า "เครื่องนี้ยังมีชีวิตและเข้าถึงได้หรือไม่"

ทำไมการ ping แบบ TCP ถึงสำคัญ

การ ping แบบดั้งเดิมที่ใช้ ICMP (คำสั่ง "ping") เหมาะสำหรับการใช้งานบนเดสก์ท็อป แต่ไม่เหมาะสมกับการมอนิเตอร์จากคลาวด์ ไฟร์วอลล์ส่วนใหญ่สมัยนี้จะบล็อกหรือจำกัดอัตรา ICMP โดยเฉพาะจากเครือข่ายสาธารณะ ดังนั้น timeout จาก ICMP อาจแปลว่า "เซิร์ฟเวอร์ดับ" หรือ "firewall ดักแพ็กเก็ตไว้" ซึ่งตีความยากและไม่ควรเกิดขึ้นกับเครื่องมือแจ้งเตือน

DiagnoSEO Uptime Monitoring ใช้การ ping แบบ TCP: การตรวจสอบจะพยายามเปิดการเชื่อมต่อ TCP ที่พอร์ตที่รู้จัก (เริ่มจาก 80 หากไม่ได้ถึง fallback ที่ 443) โดยมี timeout 5 วินาที ถ้าได้รับ SYN/ACK - แปลว่า host เข้าถึงได้ ถ้าไม่ได้ - คุณจะเห็นข้อผิดพลาดจริงจาก kernel (connection refused, timeout, no route to host) ทำให้วิเคราะห์ปัญหาได้เร็วขึ้น

มีอะไรที่ถูกบันทึกบ้าง

ทุกครั้งที่ ping จะบันทึกผลลัพธ์ (up / down) และเวลาตอบสนอง RTT ในหน่วยมิลลิวินาที ข้อมูลนี้จะเข้าสู่ pipeline เดียวกับประวัติ HTTP monitor - คุณจะเห็นกราฟเส้น sparkline ของแต่ละรอบตรวจสอบ เปอร์เซ็นต์ uptime 24 ชั่วโมง และ 30 วัน พร้อม heatmap การเข้าถึงย้อนหลัง 30 วัน หาก host ล่ม จะมีการเปิด incident และแจ้งเตือนไปยังช่องทางที่เปิดใช้งาน

คำแนะนำสำหรับการมอนิเตอร์ ping

เลือกช่วงเวลาสั้น: ping ใช้ทรัพยากรต่ำ เลือก 1-5 นาทีหากแผนราคาของคุณรองรับ จะตรวจพบปัญหาได้เร็วขึ้นในต้นทุนที่ต่ำ
ผสานกับการมอนิเตอร์พอร์ต: หากคุณมีฐานข้อมูลที่ 5432 หรือเมล์ที่ 25 ให้เพิ่มการตรวจสอบพอร์ตด้วย ping จะบอกว่า "เครื่องทำงาน" พอร์ตจะบอกว่า "บริการกำลังฟังอยู่"
เฝ้าติดตามค่า RTT: เวลาตอบสนองจะถูกบันทึกทุกครั้ง หาก RTT กระโดดเพิ่มขึ้นกระทันหัน มักเป็นสัญญาณเตือนปัญหาใหญ่ที่จะมาถึง - กำหนด threshold ไว้เพื่อจับมันก่อนเป็น incident จริง
ใช้ threshold การยืนยันผลลัพธ์: เครือข่ายมีความไม่เสถียรเป็นระยะ ค่าเริ่มต้นคือ 2 ครั้งตรวจสอบติดต่อกันที่ล้มเหลว ช่วยป้องกัน false positive

แผงควบคุมแสดงผลอย่างไร

Monitors แบบ ping จะแสดงร่วมกับ monitors ที่เป็น HTTP, port, keyword, API และ heartbeat ในลิสต์เดียวกัน คุณสามารถแท็ก ("โครงสร้างพื้นฐาน", "ภายใน"), กรองตามสถานะ, เรียงตาม RTT หรือจะหยุด/เริ่มใหม่ได้เหมือนกับตัวอื่น แจ้งเตือนจะถูกส่งไปที่ช่องทางเดียวกัน (Email, Telegram, Slack, Discord, SMS) ด้วยกฎเงื่อนไขกลางคืนและ threshold การยืนยันผลลัพธ์ที่เหมือนกันทุกประการ

ตั้งค่าอย่างไร

เปิดเครื่องมือ คลิก "เพิ่ม monitor", เลือกประเภท "Ping (TCP)", วาง host (เช่น db.internal.firma.com), ตั้งช่วงเวลา แล้วบันทึก จากรอบถัดไป Monitor จะพยายามเชื่อมต่อ TCP ทุกนาที, บันทึกค่า RTT และแจ้งเตือนเมื่อ host ไม่ตอบสนอง

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

Ping monitoring ใช้ทำอะไร?
ตรวจสอบการเข้าถึงในระดับเลเยอร์ 3 — host ตอบสนองต่อ ICMP echo หรือไม่ เหมาะกับ router, switch, อุปกรณ์ IoT, โครงสร้างพื้นฐานภายใน และทุกอย่างที่ไม่ได้ run ด้วย HTTP แต่ควรจะออนไลน์และเข้าถึงได้
ทำไม server AWS/cloud ของฉันไม่ผ่านการตรวจ ping?
ผู้ให้บริการคลาวด์ส่วนใหญ่บล็อก ICMP เป็นค่าเริ่มต้นที่ security-group หรือ firewall เซิร์ฟเวอร์อาจยังปกติแต่ไม่ตอบสนองต่อ ping ใน workload คลาวด์ให้เลือกตรวจสอบแบบ HTTP หรือ TCP port แทน คุณสามารถอนุญาต ICMP แบบเจาะจงที่ security groups ได้หากจำเป็นต้องใช้ ping จริงๆ
ping กับการเช็ค TCP port ต่างกันอย่างไร?
ping ใช้ ICMP (ไม่มีพอร์ต — ตรวจสอบหมายเลขเลเยอร์ 3 อย่างเดียว) TCP port จะเปิดการเชื่อมต่อ TCP ที่พอร์ตที่กำหนด ยืนยันการเชื่อมต่อเลเยอร์ 4 host อาจผ่าน ping แต่ fail ที่ TCP (firewall บล็อก port) หรือในทางกลับกัน (ICMP โดนบล็อกแต่ port เปิด)
ตรวจวัด round-trip time ของ ping หรือไม่?
ใช่ — เวลาตอบสนอง (round-trip) ถูกบันทึกทุกครั้งที่ตรวจสอบและติดตามเป็นสถิติย้อนหลัง เหมาะสำหรับการจับสัญญาณเสื่อมสภาพของเครือข่าย: host เดิมแต่ RTT เพิ่มจาก 20ms เป็น 200ms สื่อว่าเกิดปัญหา routing หรือ network congestion
ping IP ภายในได้หรือไม่?
ได้ ก็ต่อเมื่อ IP นั้นสามารถเข้าถึงได้จาก server checker ของเรา - หมายถึงต้องเป็น public IP ช่วง private ตาม RFC1918 (192.168.x.x, 10.x.x.x, 172.16-31.x.x) จะใช้กับการตรวจสอบจากภายนอกไม่ได้ ถ้าเป็นโครงสร้างพื้นฐานภายในให้รัน self-hosted heartbeat agent ภายในเครือข่ายเพื่อ ping หาเรา

การตรวจสอบ Ping