การตรวจสอบเวลาในการตอบสนอง

ทำไมเวลาตอบสนองถึงสมควรมีการแจ้งเตือนแยกต่างหาก

การแจ้งเตือน uptime มาตรฐานขึ้นอยู่กับสัญญาณแบบไบนารี: ขึ้นหรือลง พื้นที่สีเทาระหว่างนั้น - ขึ้นแต่ช้า - คือที่ซึ่งปัญหาส่วนใหญ่ของระบบยุคใหม่แฝงตัวอยู่ คำสั่งฐานข้อมูลที่ตั้งค่าผิดเริ่มใช้เวลานาน 4 วินาทีแทนที่จะเป็น 50 ms ปัญหา memory leak ทำให้ garbage collection กระตุก API ภายนอกที่ backend เรียกเริ่มไม่เสถียร สิ่งเหล่านี้ไม่ได้ทำให้เว็บใช้ไม่ได้โดยสิ้นเชิง แต่ทำให้เว็บนั้นใช้งานไม่ได้ - และล้วนเป็นสัญญาณเตือนล่วงหน้าก่อนจะเกิดเหตุขัดข้องในอีกหนึ่งหรือสองชั่วโมง

การมอนิเตอร์เวลาตอบสนองช่วยจับความช้าก่อนจะกลายเป็นเหตุขัดข้อง คุณสามารถกำหนด threshold สำหรับแต่ละมอนิเตอร์ได้เอง และเมื่อเวลาตอบสนองเกิน threshold หลายครั้งติดต่อกัน คุณจะได้รับการแจ้งเตือน ก่อนที่การแจ้งเตือนจะถูกส่ง คุณยังมีเวลาในการตรวจสอบ ปรับขนาด แก้ไขการเรียกที่มีปัญหาหรือย้อนการ deploy ที่เป็นต้นเหตุ

Threshold ทำงานอย่างไรใน DiagnoSEO Uptime Monitoring

แต่ละมอนิเตอร์สามารถตั้งค่าได้สองพารามิเตอร์: rt_threshold_ms และ rt_threshold_breaches ตัวแรกคือเวลาตอบสนอง (ms) ที่คุณมองว่ายอมรับได้ อีกตัวคือจำนวนครั้งที่ต้องเกิน threshold ติดต่อกันถึงจะส่งการแจ้งเตือน โดยค่าเริ่มต้น threshold จะปิดอยู่ และจำนวนการเกินคือสาม

การออกแบบสองพารามิเตอร์ช่วยลด false positive จังหวะของระบบเครือข่ายมีขึ้นลงได้ Garbage collection ก็มีหยุดบ้าง การกระโดดเป็น 1 วินาทีครั้งเดียว ทั้งที่ปกติ 200 ms ไม่ควรปลุกคุณตอนตีสาม แต่หากช้า 1 วินาทีติดกันสามครั้ง นั่นคือปัญหารุนแรง เลือก threshold ตามพฤติกรรมปกติที่สังเกตได้และเผื่อขอบเขต: ถ้า p95 ปกติคือ 400 ms ให้ตั้ง threshold 1000 ms ถ้า p95 คือ 50 ms (API ภายใน) ให้ threshold 200 ms

เหมาะสำหรับใช้งานร่วมกับอะไร

การแจ้งเตือนเวลาตอบสนองจะดีที่สุดเมื่อใช้ร่วมกับสัญญาณอื่น ๆ ของมอนิเตอร์ ภาพรวมเต็ม: threshold บอกว่าระบบเริ่มเสื่อม, HTTP code บอกเมื่อไหร่พังจริง, การเตือน SSL/โดเมน คือสัญญาณขัดข้องด้านเวลา การแจ้งเปลี่ยน DNS บอกปัญหาด้าน configuration สี่สัญญาณนี้ช่วยให้มอนิเตอร์เดียวกันให้ observability ที่สมบูรณ์แทนแค่ "ทำงาน/ไม่ทำงาน" แบบ binary

แดชบอร์ดก็ช่วยในจุดนี้ แต่ละมอนิเตอร์จะแสดงกราฟ sparkline ระยะสั้นของเวลาตอบสนอง - ตัวบ่งชี้แบบเห็นภาพของแนวโน้มเสื่อม คุณสามารถดูค่าเฉลี่ย 24 ชม., 7 วัน และ 30 วัน หากเห็นค่าเฉลี่ยค่อย ๆ สูงขึ้นทุกสัปดาห์ - นั่นคือสัญญาณเตือนล่วงหน้าที่ควรตรวจสอบก่อนเกิน threshold

Threshold ที่แนะนำโดยประเภทเว็บไซต์

• หน้า Landing Page การตลาด: 1500 ms เหมาะสม เพราะโหลดภาพและสคริปต์ tracking หลายอย่าง; ความเร็วไม่สำคัญเท่าความเสถียร
• หน้าสินค้าหรือหมวด Ecommerce: 800-1200 ms เว็บขายของที่ช้าฆ่า conversion; threshold แคบจะจับปัญหาไวขึ้น
• Dashboard แอปพลิเคชัน: 500-800 ms ผู้ใช้คาดหวังความไว Dashboard ช้าดูเหมือนแอปเสีย
• Public API: 200-400 ms สำหรับ endpoint ง่าย ๆ, endpoint ที่ต้องประมวลผลมากให้ตั้งสูงขึ้น แยกระดับ threshold ให้เหมาะสม
• Health Check มิโครเซอร์วิสภายใน: 50-100 ms ควรตอบแทบจะทันที; ช้าเกือบแน่นอนว่ามีปัญหาจริง

ไม่ว่าจะเลือก threshold อะไร อย่าเลือกครั้งเดียวแล้วลืม ควรประเมินใหม่ทุกไตรมาสตามแนวโน้มที่พบจริง ถ้าเตือน threshold บ่อยแต่ไม่เจอปัญหาเลย แปลว่า threshold แน่นไป ถ้ามีปัญหาแต่ก่อนหน้านี้ไม่มี threshold alert แปลว่า threshold หลวมเกิน

การกำหนดเส้นทางการแจ้งเตือน

การแจ้งเตือนเกิน threshold จะส่งผ่านช่องทางเดียวกับแจ้งเตือน down/recovery: Email, Telegram, Slack, Discord, SMS เคารพช่วงเวลางดแจ้งเตือนตอนกลางคืนและเก็บ log ไว้ในตารางเดียวกัน ต่างกันแค่ประเภท event ("threshold" แทน "down") และข้อความ - ข้อความแจ้งเวลาตอบสนองจริงและ threshold ที่ตั้ง ให้เห็นขนาดการเกิน threshold ได้ทันที

การตั้งค่า

แก้ไขมอนิเตอร์ใดก็ได้ ในฟอร์มให้ใส่ "Threshold เวลาตอบสนอง (ms)" ตามที่ต้องการ ปรับจำนวน "การเกินติดต่อกัน" ได้ถ้าไม่ต้องการค่าเริ่มต้นที่ 3 กดบันทึก รอบถัดไปแต่ละเช็กจะเปรียบเทียบเวลาตอบสนองกับ threshold และหลังจากเกิน threshold ตามจำนวนครั้งที่ตั้ง จะมีการแจ้งเตือนทันที

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

• มีการบันทึกค่าเมตริกเวลาตอบสนองอะไรบ้าง?

  Time To First Byte (TTFB) — คือมิลลิวินาทีระหว่างส่งคำร้องถึงได้รับ byte แรกของการตอบกลับ รวมถึงเวลาที่ใช้โหลดคำตอบทั้งชุด TTFB เป็นเมตริกสำคัญสำหรับสุขภาพเซิร์ฟเวอร์

• เวลาตอบสนองที่ "ดี" คือเท่าไร?

  ขึ้นกับ location และเนื้อหา หน้า static บน CDN: ต่ำกว่า 100 ms ดีมาก, ต่ำกว่า 300 ms ถือว่าโอเค สำหรับแอปพลิเคชัน dynamic: ต่ำกว่า 500 ms โอเค ต่ำกว่า 1000 ms พอรับได้ มากกว่า 2000 ms จะรู้สึกช้า เปรียบเทียบกับฐานเวลาทำงานจริงของคุณแทนที่จะดูตัวเลข absolute

• ฉันจะได้รับแจ้งเตือนเมื่อเวลาตอบสนองเกิน threshold หรือไม่?

  ใช่ มอนิเตอร์แต่ละตัวตั้งค่าเวลา threshold ได้ หากเกิน threshold ติดต่อกัน 3 ครั้ง จะมีการแจ้งเตือน "slow response" การบังคับให้ตรวจเช็กเกิน threshold 3 ครั้ง ป้องกัน false alarm จากอาการเน็ตกระตุกชั่วครั้งคราว

• เวลาตอบสนองถูกวัดจากที่ไหน?

  จากจุดเช็ก 13 จุดทั่วโลก (ยุโรป อเมริกาเหนือ เอเชีย อเมริกาใต้ โอเชียเนีย) ถ้ามอนิเตอร์แบบ single-region เวลาจะอิง region ที่ใกล้ที่สุด ส่วน multi-region แต่ละ region จะวัดแยกกัน มีประโยชน์มากสำหรับตรวจปัญหา CDN รายภูมิภาค

• Dashboard แสดงแนวโน้มเวลาตอบสนองหรือไม่?

  ใช่ — มีค่าเฉลี่ย 30 วันกราฟเคลื่อนที่, รายวันสูงสุด/ต่ำสุด และเปอร์เซ็นไทล์ (p50, p95) ช่วยวางแผนการขยายระบบ: ถ้า p95 พุ่งจาก 800ms เป็น 1500ms ในหนึ่งเดือน แปลว่าเซิร์ฟเวอร์เริ่มรับภาระเกิน แม้ uptime % จะยัง 100%