การหยุดทำงานของ Cloudflare, ความล้มเหลวของ CDN ระดับภูมิภาค และการลดลงระดับ Edge จะไม่แสดงบนหน้าสถานะเสมอไป เมื่อ Tokyo POP ของ CDN ของคุณล่ม แต่สถานะทั่วโลกแสดงเป็นสีเขียว การตรวจสอบของคุณจากเวอร์จิเนียจะไม่ตามทัน
การตรวจจับการหยุดทำงานในภูมิภาคจำเป็นต้องมีการตรวจสอบจากตำแหน่งที่ผู้ใช้ของคุณอยู่จริงๆ ไม่ใช่แค่ที่โครงสร้างพื้นฐานของคุณเท่านั้น
ตี 3 วิศวกรที่พร้อมโทรติดต่อของคุณได้รับแจ้งจากความสำเร็จของลูกค้า: "ลูกค้าองค์กรสามรายในสิงคโปร์รายงานว่าพวกเขาไม่สามารถเข้าถึงแอปได้ เริ่มต้นเมื่อประมาณสองชั่วโมงที่แล้ว"
คุณตรวจสอบแดชบอร์ดการตรวจสอบของคุณ — ทุกอย่างเป็นสีเขียว หน้าสถานะของ Cloudflare — ใช้งานได้แล้ว AWS — ไม่มีเหตุการณ์ใดๆ APM ของคุณ — กราฟเล็กๆ น้อยๆ ที่มีความสุข ดังนั้นคุณจึงขอให้ลูกค้าลองอีกครั้ง ล้างแคช ตรวจสอบเครือข่ายของพวกเขา
แต่มันก็ยังคงเกิดขึ้น ตั๋วเพิ่มเติมจากภูมิภาคเดียวกัน ในที่สุด ก็มีคนเรียกใช้ Traceroute จาก Singapore VPS และพบว่า: การรับส่งข้อมูลกำลังเข้าสู่ Cloudflare Edge ที่ส่งคืน 502 CDN มีการหยุดทำงานของภูมิภาคซึ่งส่งผลกระทบต่อ PoP หนึ่งตัว — และไม่มีสิ่งใดในสแต็กการตรวจสอบของคุณที่ถูกตรวจสอบจากภูมิภาคนั้น
การหยุดทำงานสองชั่วโมง สำหรับภูมิศาสตร์เฉพาะ การแจ้งเตือนเป็นศูนย์ นั่นคือจุดบอดที่เพจนี้เกี่ยวกับ
ไม่ว่าจะเป็นการหยุดทำงานของ Cloudflare ความล้มเหลวของ Edge อย่างรวดเร็ว หรือการเสื่อมสภาพของภูมิภาค Akamai การตรวจพบปัญหาเหล่านี้จำเป็นต้องมีการตรวจสอบจากภูมิภาคที่ได้รับผลกระทบ นั่นคือวิธีที่คุณจะตรวจพบปัญหาก่อนที่จะกลายเป็นการยกระดับปัญหาของลูกค้า
อินเทอร์เน็ตไม่ใช่เครือข่ายเดียว คำขอจากซิดนีย์เดินทางผ่านโครงสร้างพื้นฐานที่แตกต่างอย่างสิ้นเชิงกับคำขอจากแฟรงก์เฟิร์ต เมื่อส่วนใดส่วนหนึ่งของเส้นทางภูมิภาคนั้นล้มเหลว เฉพาะผู้ใช้ในภูมิภาคนั้นเท่านั้นที่ได้รับผลกระทบ
CDN เช่น Cloudflare, Fastly และ Akamai ดำเนินการ Points of Presence (PoP) หลายร้อยจุดทั่วโลก เมื่อ Edge Server หรือ PoP เฉพาะประสบปัญหา — ฮาร์ดแวร์ล้มเหลว การกำหนดค่าผิดพลาด หรือปัญหาด้านความจุ — เฉพาะผู้ใช้ที่ถูกกำหนดเส้นทางไปยัง Edge นั้นเท่านั้นที่ได้รับผลกระทบ สถานะส่วนกลางของ CDN ยังคงเป็น "ใช้งานได้" เนื่องจาก Edge 95% ยังอยู่ในสภาพปกติ
ตัวอย่าง: ในเดือนมิถุนายน 2022 Cloudflare เกิดไฟฟ้าดับเป็นเวลา 30 นาที ซึ่งส่งผลกระทบต่อศูนย์ข้อมูล 19 แห่งเนื่องจากการเปลี่ยนแปลงการกำหนดค่าเครือข่าย ผู้ใช้ในภูมิภาคเหล่านั้นพบข้อผิดพลาด ผู้ใช้ที่อื่นพบว่าไม่มีอะไรผิดปกติ
DNS เป็นขั้นตอนแรกในคำขอใดๆ เมื่อ 1.1.1.1 ของ Cloudflare หรือเซิร์ฟเวอร์ DNS ของ CDN ของคุณประสบปัญหาในภูมิภาคใดภูมิภาคหนึ่ง — เส้นทาง anycast ที่กำหนดค่าไม่ถูกต้อง, เนมเซิร์ฟเวอร์ที่โอเวอร์โหลด — ผู้ใช้ในภูมิภาคนั้นจะไม่สามารถแก้ไขโดเมนของคุณได้ เบราว์เซอร์ของพวกเขาแสดงเพียง "DNS_PROBE_FINISHED_NXDOMAIN"
ตัวอย่าง: ปัญหา DNS ภูมิภาคอาจเกิดจากการกรองระดับ ISP ปัญหาตัวแก้ไขในเครื่อง หรือปัญหาการกำหนดเส้นทางแบบคาสต์ที่ส่งผลต่อพื้นที่ทางภูมิศาสตร์บางแห่งเท่านั้น
การรั่วไหลของเส้นทาง BGP การไฮแจ็ก และการกำหนดค่าที่ไม่ถูกต้องสามารถเปลี่ยนเส้นทางการรับส่งข้อมูลผ่านเส้นทางที่ต่ำกว่ามาตรฐานหรือหลุมดำโดยสิ้นเชิง เมื่อผู้ให้บริการหลักในภูมิภาคมีปัญหาการกำหนดเส้นทาง การรับส่งข้อมูลจากภูมิภาคนั้นไปยัง CDN หรือต้นทางของคุณอาจล้มเหลว แม้ว่าปลายทางทั้งสองจะทำงานได้อย่างสมบูรณ์ก็ตาม
ตัวอย่าง: เหตุการณ์ BGP ส่งผลกระทบต่อเครือข่ายนับพันเป็นประจำ เส้นทาง AS ที่กำหนดค่าไม่ถูกต้องเพียงครั้งเดียวอาจทำให้เว็บไซต์ของคุณไม่สามารถเข้าถึงได้จากทั้งประเทศเป็นเวลาหลายชั่วโมงโดยที่ดูดีจากตำแหน่งการตรวจสอบของคุณ
ISP หลักในบางประเทศอาจมีการลดระดับการเชื่อมต่อกับ CDN ของคุณเนื่องจากข้อพิพาทในการเพียร์ ความแออัด หรือปัญหาโครงสร้างพื้นฐาน ผู้ใช้บน Telstra ในออสเตรเลียอาจประสบความล้มเหลวในขณะที่ผู้ใช้ Optus ในเมืองเดียวกันไม่มีปัญหา — เนื่องจากการจราจรไหลผ่านเส้นทางที่ต่างกัน
ตัวอย่าง: ข้อพิพาทแบบเพียร์ริ่งระหว่าง ISP และผู้ให้บริการระบบคลาวด์ ในอดีตเคยส่งผลให้ความเสื่อมโทรมลงหลายสัปดาห์ซึ่งส่งผลกระทบต่อผู้ใช้หลายล้านรายในตลาดเฉพาะ
เธรดทั่วไป: ความล้มเหลวทั้งหมดเหล่านี้มีขอบเขตทางภูมิศาสตร์ ต้นกำเนิดของคุณขึ้นแล้ว การกำหนดค่า CDN ของคุณถูกต้อง แต่ที่ใดที่หนึ่งระหว่าง Edge ของคุณและผู้ใช้ในภูมิภาคใดภูมิภาคหนึ่ง มีบางอย่างเสียหาย — และการตรวจสอบของคุณที่ตรวจสอบจากสถานที่แห่งหนึ่งในเวอร์จิเนียไม่มีทางที่จะตรวจพบได้
การตรวจสอบสถานะการออนไลน์ส่วนใหญ่ได้รับการออกแบบมาเพื่อปัญหาที่ง่ายกว่า: "เซิร์ฟเวอร์ตอบสนองหรือไม่" สำหรับไซต์ที่เร่งรัดด้วย CDN ที่ให้บริการผู้ใช้ทั่วโลก นั่นไม่ใช่คำถามที่ถูกต้องอีกต่อไป
บริการตรวจสอบส่วนใหญ่มีค่าเริ่มต้นเป็นการตรวจสอบจากสถานที่บางแห่งในสหรัฐฯ หรือสหภาพยุโรป หาก Singapore PoP ของ Cloudflare หยุดทำงาน เช็คของคุณจาก Oregon จะยังคงประสบความสำเร็จ — มันได้เปรียบที่แตกต่างและดีต่อสุขภาพ ในขณะเดียวกัน ผู้ใช้ APAC ของคุณเห็นข้อผิดพลาด 502
การเรียกใช้การตรวจสอบจาก AWS ไปยัง Cloudflare จะใช้การเชื่อมต่อแกนหลักบนระบบคลาวด์ ซึ่งเป็นเส้นทางที่ได้รับการปรับปรุงซึ่งไม่ได้แสดงถึงการรับส่งข้อมูลของผู้ใช้จริง การตรวจสอบสังเคราะห์ของคุณจาก AWS ap-southeast-1 อาจเลี่ยงเส้นทางเครือข่ายที่แน่นอนที่ล้มเหลวสำหรับผู้ใช้ ISP ในพื้นที่
หน้าสถานะ CDN สะท้อนถึงมุมมองภายใน ซึ่งมักจะรวมอยู่ใน PoP หลายร้อยรายการ ปัญหาระดับภูมิภาคที่ส่งผลกระทบต่อโครงสร้างพื้นฐาน 5% อาจไม่กระตุ้นให้มีการอัปเดตหน้าสถานะ — แต่ 5% นั้นอาจรวมถึงเอเชียตะวันออกเฉียงใต้ทั้งหมด
การตรวจสอบ HTTP จะบอกคุณว่าคำขอสำเร็จหรือล้มเหลว แต่ไม่โดยที่ล้มเหลว หากไม่มีข้อมูลการแยกย่อยการติดตามและเวลาในการตอบสนองจากภูมิภาคที่ได้รับผลกระทบ คุณจะไม่สามารถระบุได้ว่าปัญหาคือ DNS, การกระโดดข้ามเครือข่ายเฉพาะ หรือขอบ CDN ของคุณ
Cloudflare มี PoP มากกว่า 310 รายการ หากการตรวจสอบของคุณตรวจสอบจาก 3 ตำแหน่ง แสดงว่าคุณกำลังตรวจสอบ Edge น้อยกว่า 1% ที่ผู้ใช้ของคุณอาจได้รับผลกระทบ นั่นไม่ใช่การตรวจจับไฟดับ — นั่นคือความหวังในสิ่งที่ดีที่สุด
ทุกนาทีที่การหยุดทำงานของ Cloudflare หรือความล้มเหลวของ CDN ระดับภูมิภาคไม่ถูกตรวจพบ คุณจะสูญเสียผู้ใช้ รายได้ และความไว้วางใจในตลาดที่คุณอาจไม่รู้ด้วยซ้ำว่าคุณกำลังให้บริการอยู่
การหยุดทำงานในระดับภูมิภาคในช่วงเวลาทำการในเขตเวลานั้นอาจทำให้เสียเวลาในการทำธุรกรรม การสมัครใช้งาน หรือการเรียก API ผู้ใช้ไม่ได้ส่งอีเมล "ไซต์ของคุณไม่ทำงานสำหรับฉัน" พวกเขาเพียงแค่ออกไป คุณจะเห็นการลดลงในเมตริกระดับภูมิภาคในภายหลัง โดยไม่มีการระบุสาเหตุที่ชัดเจน
ลูกค้าองค์กรมี SLA เมื่อพวกเขาไม่สามารถเข้าถึงแพลตฟอร์มของคุณได้ และคุณไม่รู้ด้วยซ้ำว่าเกิดปัญหา นั่นเป็นการสนทนาที่ไม่ดี "เราตรวจไม่พบการหยุดทำงาน" ไม่ใช่การตอบสนองที่สร้างความไว้วางใจ โดยเฉพาะอย่างยิ่งเมื่อพวกเขาจ่ายเงินเพื่อความน่าเชื่อถือ
Googlebot รวบรวมข้อมูลจากหลายตำแหน่งทั่วโลก หาก CDN Edge ในภูมิภาคแสดงข้อผิดพลาดหรือการตอบสนองช้า ซึ่งจะส่งผลต่องบประมาณการรวบรวมข้อมูล การประเมิน Core Web Vitals และการจัดอันดับในท้ายที่สุด คุณอาจพบว่าการเข้าชมลดลงในบางตลาดโดยไม่มีสาเหตุที่ชัดเจน
Mean Time to Recovery (MTTR) เริ่มต้นเมื่อคุณตรวจพบปัญหา หากการหยุดทำงานของ Cloudflare ระดับภูมิภาคส่งผลกระทบต่อผู้ใช้เป็นเวลา 2 ชั่วโมงก่อนที่คุณจะทราบเรื่องนี้จากตั๋วของลูกค้า นั่นจะเป็นการเพิ่ม 2 ชั่วโมงใน MTTR ที่มีผลของคุณ การตรวจจับเชิงรุกเป็นวิธีเดียวที่จะลดผลกระทบจากการหยุดทำงานที่เกิดขึ้นจริงให้เหลือน้อยที่สุด
การตรวจจับการหยุดทำงานในภูมิภาคจำเป็นต้องมีการตรวจสอบจากตำแหน่งที่ผู้ใช้ของคุณอยู่ พร้อมด้วยการวินิจฉัยเชิงลึกเพื่อระบุตำแหน่งที่เกิดความล้มเหลว
ตำแหน่งการตรวจสอบแต่ละตำแหน่งจะเข้าถึงขอบ CDN ที่แตกต่างกันและลัดเลาะไปตามเส้นทางเครือข่ายที่แตกต่างกัน ในการตรวจจับการหยุดทำงานในระดับภูมิภาค คุณต้องมีโหนดในทุกภูมิภาคที่คุณมีการรับส่งข้อมูลที่สำคัญ — เอเชียแปซิฟิก ยุโรป อเมริกา ตะวันออกกลาง แอฟริกา ไม่ใช่แค่ "ต่างประเทศ" — โดยเฉพาะที่ที่ผู้ใช้ของคุณอยู่
การตรวจสอบจากสถานที่มากกว่า 50 แห่งครอบคลุม CDN PoP และเส้นทาง ISP หลัก
เมื่อเช็คล้มเหลวจากสิงคโปร์แต่สำเร็จจากทุกที่ คุณจำเป็นต้องรู้ว่านี่คือ DNS หรือไม่ กระโดดเครือข่ายเฉพาะ? ขอบ CDN? Traceroute และ MTR จากตำแหน่งที่ได้รับผลกระทบจะเป็นหลักฐานที่คุณต้องการในการวินิจฉัยสาเหตุที่แท้จริงและส่งต่อไปยัง Cloudflare, ISP ของคุณ หรือผู้ให้บริการโฮสติ้งของคุณ
ข้อมูลการวินิจฉัยจะเปลี่ยน "มีบางอย่างเสียหาย" ให้กลายเป็นสาเหตุที่แท้จริงที่ดำเนินการได้
400ms จากโตเกียวเป็นเรื่องปกติหรือนั่นคือความเสื่อมของ Cloudflare Edge ข้อมูลประวัติต่อสถานที่จะสร้างเส้นพื้นฐานที่ช่วยให้คุณตรวจพบความล้มเหลวที่ช้า — เวลาแฝงที่เพิ่มขึ้นซึ่งไม่ทำให้เกิดความล้มเหลวอย่างรุนแรง แต่ทำให้ประสบการณ์ผู้ใช้ลดลง คุณสามารถตรวจพบปัญหา CDN ระดับภูมิภาคได้ก่อนที่จะเกิดการหยุดทำงานโดยสมบูรณ์
เส้นพื้นฐานจะตรวจพบความเสื่อมโทรมก่อนที่จะเกิดการขัดข้อง
คำแนะนำทีละขั้นตอนในการใช้การตรวจสอบที่ตรวจจับการหยุดทำงานของ Cloudflare และความล้มเหลวของ CDN ระดับภูมิภาคก่อนที่ผู้ใช้ของคุณจะรายงาน
ตรวจสอบการวิเคราะห์ของคุณเพื่อระบุว่าผู้ใช้ของคุณอยู่ที่ใด หาก 20% ของการรับส่งข้อมูลมาจากเอเชียแปซิฟิก คุณต้องมีโหนดตรวจสอบหลายโหนด — สิงคโปร์ โตเกียว ซิดนีย์ มุมไบ จับคู่ความครอบคลุมการตรวจสอบกับการกระจายผู้ใช้จริง
ตั้งค่าการตรวจสอบ HTTP สำหรับ URL หลักของคุณที่ผ่าน Cloudflare หรือ CDN ของคุณ สิ่งเหล่านี้ควรกระทบกับขอบ CDN ไม่ใช่ต้นทางของคุณโดยตรง รวมโดเมนแอปของคุณ ตำแหน่งข้อมูล API และหน้าสาธารณะที่สำคัญ
ภูมิภาคต่างๆ มีเวลาในการตอบสนองพื้นฐานที่แตกต่างกัน กำหนดค่าเกณฑ์ที่เหมาะสม: อาจยอมรับได้ 500 มิลลิวินาทีจากยุโรป แต่ 500 มิลลิวินาทีจากสหรัฐอเมริกาตะวันออก (เมื่อต้นทางของคุณอยู่ที่นั่น) บ่งบอกถึงปัญหา CDN Edge ใช้ข้อมูลในอดีตเพื่อกำหนดเส้นฐานที่สมจริง
ตั้งค่าการแจ้งเตือนที่เริ่มทำงานเมื่อบางภูมิภาคล้มเหลว ไม่ใช่แค่เมื่อสถานที่ทั้งหมดล้มเหลวเท่านั้น ความล้มเหลวในสิงคโปร์เพียงแห่งเดียวยังคงเป็นการหยุดทำงานที่คุ้มค่าแก่การรู้ กำหนดเส้นทางการแจ้งเตือนที่มีลำดับความสำคัญสูงไปยัง Slack, PagerDuty หรือระบบการจัดการเหตุการณ์ของคุณ
เมื่อมีการแจ้งเตือน คุณต้องตรวจสอบอย่างรวดเร็ว: นี่เป็นปัญหาของ Cloudflare หรือไม่ ปัญหาเส้นทางเครือข่าย? ดีเอ็นเอส? เปิดใช้งาน Traceroute และ MTR ตามความต้องการจากตำแหน่งการตรวจสอบ เพื่อให้คุณสามารถรวบรวมข้อมูลการวินิจฉัยได้ทันที
บันทึกกระบวนการ: วิธีตรวจสอบการหยุดทำงานในภูมิภาคของ Cloudflare จะตรวจสอบ API สถานะของ Cloudflare ได้ที่ไหน วิธีเปิดตั๋วพร้อมหลักฐาน คุณสามารถปรับใช้การบรรเทาผลกระทบใดบ้าง (เฟลโอเวอร์ การบายพาสแคช ฯลฯ) การเตรียมพร้อมนี้จะช่วยลด MTTR ลงอย่างมาก
ตั้งการแจ้งเตือนปฏิทินรายสัปดาห์เพื่อตรวจสอบเวลาแฝงและสถานะการออนไลน์ต่อภูมิภาค มองหารูปแบบ: APAC ช้าลงอย่างต่อเนื่องหรือไม่ มี blips เป็นประจำในสถานที่เฉพาะหรือไม่? การตรวจสอบเชิงรุกจะตรวจจับความเสื่อมโทรมได้ช้าก่อนที่จะส่งผลกระทบต่อผู้ใช้อย่างมีนัยสำคัญ
สำหรับบริการที่ไม่สามารถยอมรับการหยุดทำงานในระดับภูมิภาคได้ ให้ลองใช้กลยุทธ์หลาย CDN ที่ DNS สามารถเฟลโอเวอร์ระหว่างผู้ให้บริการได้ สิ่งนี้จำเป็นต้องมีการตรวจสอบแต่ละ CDN อย่างอิสระและมีระบบอัตโนมัติที่สามารถเปลี่ยนการรับส่งข้อมูลได้ มันซับซ้อนแต่ก็มีความยืดหยุ่น
Latency Global ถูกสร้างขึ้นเพื่อตรวจจับปัญหาประเภทนี้โดยเฉพาะ เช่น การหยุดทำงานของ Cloudflare, ความล้มเหลวของ CDN ระดับภูมิภาค และปัญหาเครือข่ายที่การตรวจสอบตำแหน่งเดียวพลาดไป เราตรวจสอบจาก สถานที่จริงมากกว่า 70 แห่งทั่ว 6 ทวีป ครอบคลุมภูมิภาค CDN PoP ที่สำคัญทั้งหมด
การตรวจสอบทุกครั้งจะรวมการแบ่งเวลาทั้งหมด — การแก้ไข DNS, การเชื่อมต่อ TCP, การแฮนด์เชค TLS, TTFB และเวลาตอบสนองทั้งหมด เมื่อมีบางอย่างล้มเหลวจากภูมิภาคใดภูมิภาคหนึ่ง คุณสามารถเรียกใช้ Traceroute และ MTR จากตำแหน่งนั้นเพื่อระบุตำแหน่งที่แน่ชัดในเส้นทางเครือข่ายที่เกิดปัญหา ราคาตรงไปตรงมา: $5/เดือน สำหรับ 5 จอภาพ รวมทุกตำแหน่งแล้ว
การตรวจจับการหยุดทำงานในภูมิภาคต้องใช้โครงสร้างพื้นฐานในหลายพื้นที่ นั่นคือสาเหตุที่เครื่องมือตรวจสอบส่วนใหญ่ไม่เสนอหรือเรียกเก็บเงินตามราคาองค์กร เรามุ่งเน้นไปที่สิ่งสำคัญ: ความครอบคลุมและความลึกของการวินิจฉัย
การหยุดทำงานของ CDN ระดับภูมิภาคเกิดขึ้นเมื่อเซิร์ฟเวอร์ Edge หรือ Points of Presence (PoP) เฉพาะในเครือข่าย CDN ล้มเหลวหรือลดลง ในขณะที่ Edge อื่นๆ ยังคงใช้งานได้ ตัวอย่างเช่น Cloudflare อาจมีปัญหากับ Singapore PoP ในขณะที่ Edge ของสหรัฐอเมริกาและยุโรปทำงานได้ดี ผู้ใช้ที่เปลี่ยนเส้นทางผ่าน Edge ที่ได้รับผลกระทบจะพบข้อผิดพลาดหรือประสิทธิภาพการทำงานที่ช้า ผู้ใช้ที่อื่นไม่สังเกตเห็นอะไรเลย การหยุดทำงานเหล่านี้จะมองไม่เห็นสำหรับการตรวจสอบที่ตรวจสอบจากภูมิภาคที่ไม่ได้รับผลกระทบเท่านั้น
โดยทั่วไปแล้ว หน้าสถานะ CDN จะแสดงสถานะโดยรวมโดยรวม ไม่ใช่ความสมบูรณ์ของ PoP เมื่อ Edge ได้รับผลกระทบ 5% สถานะโดยรวมอาจยังคงเป็น "ใช้งานได้" เนื่องจาก 95% ของโครงสร้างพื้นฐานกำลังทำงานอยู่ หน้าสถานะยังมีเวลาแฝงในการอัปเดต — ต้องใช้เวลาในการตรวจพบ ตรวจสอบ และโพสต์ปัญหา นอกจากนี้ ปัญหาบางอย่างไม่เป็นไปตามเกณฑ์การเปิดเผยต่อสาธารณะแต่ยังคงส่งผลกระทบต่อผู้ใช้ของคุณ การตรวจสอบโดยอิสระจากหลายสถานที่เป็นวิธีเดียวที่จะได้ข้อมูลจริงเกี่ยวกับความพร้อมใช้งานในระดับภูมิภาค
อย่างน้อยที่สุด คุณต้องมีสถานที่ตรวจสอบในทุกภูมิภาคหลักที่คุณมีผู้ใช้: อเมริกาเหนือ ยุโรป และเอเชียแปซิฟิกเป็นอย่างน้อย เพื่อความครอบคลุมที่ดีขึ้น สถานที่มากกว่า 50 แห่งที่กระจายอยู่ทั่วโลกจะจับประเด็นปัญหาระดับภูมิภาคส่วนใหญ่ได้ สิ่งสำคัญคือการจับคู่ความครอบคลุมของการตรวจสอบกับภูมิศาสตร์ผู้ใช้ของคุณ หาก 30% ของผู้ใช้ของคุณอยู่ใน APAC คุณต้องมีโหนดหลายโหนดที่นั่น (สิงคโปร์ โตเกียว ซิดนีย์ มุมไบ) มันไม่เกี่ยวกับการจับคู่ CDN PoP ทุกรายการ แต่ครอบคลุมกลุ่มภูมิภาคหลักๆ
ขั้นแรก รวบรวมหลักฐานการวินิจฉัย: Traceroute และ MTR จากตำแหน่งที่ได้รับผลกระทบ รหัสตอบกลับ HTTP และข้อมูลเวลา และการประทับเวลา ตรวจสอบหน้าสถานะของ Cloudflare และ Twitter เพื่อรับทราบ หากเป็นปัญหาของ Cloudflare อย่างชัดเจน ให้เปิดตั๋วสนับสนุนพร้อมหลักฐานของคุณ สำหรับการบรรเทาทันที ให้พิจารณา: ข้าม Cloudflare ชั่วคราวสำหรับภูมิภาคที่ได้รับผลกระทบ (หากต้นทางของคุณสามารถจัดการได้) เปิดใช้งาน CDN สำรองหากคุณมีความสามารถหลาย CDN หรืออัปเดตหน้าสถานะของคุณเพื่อรับทราบปัญหาในขณะที่ Cloudflare แก้ไขปัญหานั้น บันทึกทุกอย่างเพื่อการตรวจสอบหลังเหตุการณ์
ใช่ ด้วยเครื่องมือติดตามที่เหมาะสม ระยะเวลาการตรวจสอบ HTTP แบบเต็มจะแสดง: เวลาในการแก้ไข DNS (หาก DNS ล้มเหลวหรือช้า คุณจะรู้ว่าเป็นปัญหา DNS), เวลาในการเชื่อมต่อ TCP (ปัญหาเส้นทางเครือข่าย), เวลาแฮนด์เชค TLS (ปัญหาใบรับรองหรือการเข้ารหัสลับ) และ TTFB/เวลาตอบสนอง (ปัญหาต้นทางหรือการประมวลผล Edge) Traceroute แสดงเส้นทางเครือข่ายและตำแหน่งที่แพ็กเก็ตถูกทิ้งหรือล่าช้า ด้วยการเปรียบเทียบข้อมูลนี้จากภูมิภาคที่ได้รับผลกระทบกับภูมิภาคที่ดี คุณสามารถระบุได้อย่างชัดเจนว่าความล้มเหลวเกิดขึ้นที่จุดใดในห่วงโซ่คำขอ
ด้วยช่วงเวลาการตรวจสอบ 1 นาที คุณสามารถตรวจจับการหยุดทำงานภายใน 1-2 นาทีหลังจากสตาร์ท บริการตรวจสอบส่วนใหญ่ยืนยันการหยุดทำงานหลังจากเกิดความล้มเหลวติดต่อกัน 2-3 ครั้ง เพื่อหลีกเลี่ยงการแจ้งเตือนเมื่อเกิดการขัดข้องชั่วคราว ดังนั้นเวลาในการตรวจจับที่สมจริงคือ 2-5 นาที เปรียบเทียบสิ่งนี้กับการหยุดทำงานที่รายงานโดยลูกค้า ซึ่งอาจใช้เวลาหลายชั่วโมงกว่าจะแสดงผ่านตั๋วการสนับสนุน ความแตกต่างใน MTTR นั้นสำคัญมาก — 5 นาทีกับ 2 ชั่วโมงหมายถึงผลกระทบต่อผู้ใช้ที่แตกต่างกันมาก
อย่างแน่นอน. ได้อย่างรวดเร็ว Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN และ CDN อื่นๆ สามารถประสบปัญหาขัดข้องในระดับภูมิภาคได้ ใช้หลักการเดียวกันนี้: CDN มีโครงสร้างพื้นฐานแบบกระจาย และระบบแบบกระจายใดๆ อาจมีความล้มเหลวบางส่วนได้ วิธีการตรวจจับจะเหมือนกัน — ตรวจสอบจากตำแหน่งทั่วโลกหลายแห่งเพื่อตรวจจับปัญหาที่ส่งผลกระทบต่อ Edge หรือภูมิภาคเฉพาะ ไม่ว่าคุณจะใช้ CDN ใดก็ตาม
หยุดพึ่งพาหน้าสถานะ CDN และตั๋วของลูกค้าเพื่อเรียนรู้เกี่ยวกับการหยุดทำงานในภูมิภาค เพิ่มตำแหน่งข้อมูล เลือกตำแหน่งการตรวจสอบ และทราบภายในไม่กี่นาทีเมื่อ Cloudflare, Fastly หรือส่วนใดส่วนหนึ่งของสแต็กของคุณล้มเหลวในภูมิภาคใดๆ
$5/เดือน • กว่า 70 แห่ง (+40 เร็วๆ นี้) • ไม่มีสัญญา • ยกเลิกได้ตลอดเวลา