ช่องทางการเติมเงินของ Alibaba Cloud: สาเหตุทั่วไปและแนวทางแก้ไขสำหรับความล้มเหลวในการตรวจสุขภาพ SLB บ่อยๆ (Health Check Failed)

ในการทำงานประจำวันของการดำเนินงานและการบำรุงรักษาเว็บไซต์ระดับองค์กรและการเพิ่มประสิทธิภาพ SEO สิ่งที่น่าปวดหัวที่สุดสำหรับทีมคือ "ไม่สามารถเปิดเว็บไซต์ได้เป็นครั้งคราว" "ความล่าช้าในการเข้าถึงเพิ่มสูงขึ้นอย่างกะทันหัน" หรือ "การเชื่อมต่อความคิดเห็นของผู้ใช้ในบางพื้นที่ถูกรีเซ็ต"

ในฐานะเครื่องมือเพิ่มประสิทธิภาพเว็บไซต์ SEO ฉันตระหนักดีถึงผลกระทบร้ายแรงของความพร้อมใช้งานและความเสถียรของเว็บไซต์ต่อการจัดอันดับของเครื่องมือค้นหาหากเครื่องมือค้นหา Spider (เช่น Googlebot หรือ Baidubot) มักพบ502 Bad Gateway หรือ504 Gateway Timeout เมื่อรวบรวมข้อมูลเว็บไซต์ของคุณเครื่องมือค้นหาจะระบุเว็บไซต์ของคุณอย่างรวดเร็วว่า "ไม่น่าเชื่อถือ" และลดความถี่ในการรวบรวมข้อมูลดัชนีโดยตรงลดอันดับคำหลักลงอย่างมาก

ในสถาปัตยกรรมคลาวด์คอมพิวติ้งของ Alibaba Cloud สัญญาณเตือนประเภทนี้มักมาจากเบื้องหลังคนเดียวกัน-

อาลีบาบาคลาวด์โหลดบาลานซ์ (SLB / ALB / NLB) การตรวจสุขภาพล้มเหลวบ่อยครั้ง (Health Check Failed)

。

เมื่อการตรวจสุขภาพล้มเหลว SLB จะคิดว่าอินสแตนซ์ ECS ที่ส่วนหลัง "ตายแล้ว" และหยุดกระจายการเข้าชมไปและหากการตรวจสุขภาพกระโดดระหว่าง "สำเร็จ" และ "ล้มเหลว" บ่อยครั้งก็จะทำให้การเข้าชมถูกตัดออกและตัดกลับผู้ใช้ส่วนหน้าและเครื่องมือค้นหาจะพบข้อผิดพลาดที่ผิดปกติจำนวนมากเมื่อรวบรวมข้อมูลสไปเดอร์

วันนี้ตั้งแต่การตรวจสอบสถาปัตยกรรมการส่งผ่านเครือข่ายการกำหนดค่าส่วนหลังไปจนถึงการบำรุงรักษาทรัพยากรบนคลาวด์ฉันจะวิเคราะห์สาเหตุทั่วไปของความล้มเหลวในการตรวจสุขภาพ SLB ของ Alibaba Cloud บ่อยครั้งและมอบชุดโซลูชันที่มีประสิทธิภาพ

1.เหตุใดการตรวจสุขภาพ SLB จึงมีความสำคัญต่อ SEO และธุรกิจ?

ก่อนที่จะดำเนินการตรวจสอบทางเทคนิคในเชิงลึกเราจะชี้แจงตรรกะการดำเนินงานของการตรวจสุขภาพ SLB

Alibaba Cloud SLB ประเมินสถานะสุขภาพของแบ็กเอนด์โดยการส่งคำขอการตรวจจับ (เช่น HTTP GET, การจับมือ TCP เป็นต้น) ไปยังอินสแตนซ์ ECS ส่วนหลังเป็นประจำ

สถานะปกติ: SLB กระจายคำขอส่วนหน้าไปยังเซิร์ฟเวอร์ส่วนหลังแต่ละเครื่องอย่างเท่าเทียมกัน

สถานะข้อยกเว้น (Health Check Failed):SLB กำหนดความผิดปกติของ ECS และแยกโดยอัตโนมัติคำขอจะไม่ถูกส่งไป

หากการกำหนดค่าการตรวจสอบสุขภาพไม่เหมาะสมหรือมีอันตรายที่ซ่อนอยู่ในเซิร์ฟเวอร์ส่วนหลังจะปรากฏขึ้น

การตรวจสุขภาพล้มเหลวบ่อยครั้ง/สลับกระโดด

。สิ่งนี้ไม่เพียงแต่จะทำให้โหลดเซิร์ฟเวอร์เดียวเพิ่มขึ้นอย่างกะทันหันและการตอบสนองของทั้งไซต์ช้าลง (ลดตัวบ่งชี้ TTFB ใน Core Web Vitals) แต่ยังทำให้หน้าเว็บไซต์ไม่สามารถเข้าถึงได้เป็นระยะๆ

นอกจากนี้เมื่อดำเนินการจัดสรรทรัพยากรระบบคลาวด์ขนาดใหญ่และการขยายธุรกิจทีมปฏิบัติการและการบำรุงรักษามักให้ความสำคัญกับการกำหนดค่า SLB แต่ไม่สนใจการจัดการโครงสร้างพื้นฐานบัญชีคลาวด์ในช่วงเริ่มต้นของโครงการหรือในระหว่างรอบการดำเนินงานและการบำรุงรักษาอย่าลืมทำล่วงหน้า

การเติมเงินบัญชีอาลีคลาวด์

และการวางแผนงบประมาณเพื่อให้แน่ใจว่าเงินในบัญชีเพียงพอและหลีกเลี่ยง

เนื่องจากการค้างชำระกฎการตรวจสอบ SLB จึงไม่ถูกต้องแบนด์วิดท์เครือข่ายสาธารณะจึงถูกจำกัดหรือคำเตือนการตรวจสอบระบบคลาวด์ถูกระงับซึ่งจะปกปิดความล้มเหลวในการตรวจสุขภาพที่แท้จริง

2.สาเหตุทั่วไป6ประการและแนวทางแก้ไขสำหรับความล้มเหลวในการตรวจสุขภาพ SLB บ่อยๆ

จากประสบการณ์หลายปีของฉันในการปรับแต่งไซต์และการแก้ไขปัญหาความล้มเหลวในการตรวจสุขภาพ SLB มักเกิดจากสาเหตุหลัก6ประการดังต่อไปนี้:

1.กลุ่มรักษาความปลอดภัย/ไฟร์วอลล์ป้องกันการตรวจพบ IP ของ SLB

นี่เป็นหลุมที่ง่ายที่สุดสำหรับมือใหม่ในการดำเนินการและบำรุงรักษาและผู้ดูแลเว็บ

หลักการและอาการ:

SLB ภายในผ่านส่วน IP เครือข่ายส่วนตัวที่เฉพาะเจาะจง (เช่น

100.64.0.0/10

รอให้ Alibaba Cloud รักษาส่วนเครือข่าย) เพื่อเริ่มคำขอตรวจสุขภาพไปยัง ECS ส่วนหลังหากอินสแตนซ์ ECS ของคุณเปิดอยู่ภายใน

Iptables

、

Ufw

、

Firewalld

หรือกำหนดค่าในคอนโซล Alibaba Cloud

กฎกลุ่มความปลอดภัย

หาก IP เครือข่ายส่วนตัวเหล่านี้ถูกฆ่าและสกัดกั้นโดยไม่ได้ตั้งใจ SLB จะไม่สามารถรับการตอบสนองตามปกติจากแบ็กเอนด์ได้

การแก้ปัญหา:

ลงชื่อเข้าใช้คอนโซล Alibaba Cloud ECS เพื่อตรวจสอบกลุ่มความปลอดภัยที่อินสแตนซ์อยู่

ตรวจสอบให้แน่ใจว่าในกฎทิศทางการเข้าอนุญาตให้กลุ่มเครือข่าย IP การตรวจสอบสุขภาพของ SLB เข้าถึงพอร์ตแบ็กเอนด์ (เช่น HTTP 80, 443หรือพอร์ตที่กำหนดเอง TCP)

เข้าสู่ระบบ ECS ตรวจสอบการตั้งค่าไฟร์วอลล์ในเครื่องและเพิ่มส่วนเครือข่ายการตรวจจับ SLB ลงในรายการที่อนุญาตพิเศษ: Bash # ใช้ iptables เป็นตัวอย่างอนุญาตให้ส่วนเครือข่ายภายในเข้าถึง iptables -A INPUT -s 100.64.0.0/10 -p tcp -- dport 80 -j ACCEPT

2.Backend Nginx/การกำหนดค่าบริการเว็บหรือเส้นทาง (Path) ส่งกลับไม่ใช่2xx/3xx ตอบสนอง

หลักการและอาการ:

สำหรับการตรวจสอบ HTTP/HTTPS SLB จะตั้งค่า "เส้นทางการตรวจสุขภาพ" ที่แบ็กเอนด์ (โดยปกติค่าเริ่มต้นคือ

/

หรือ

/Check.html

) ส่งคำขอ SLB คิดโดยค่าเริ่มต้นเพียงผลตอบแทน

HTTP 2xx หรือ3xx

รหัสสถานะถือว่าประสบความสำเร็จ

หากแบ็กเอนด์ของคุณกำหนดค่าการเปลี่ยนเส้นทางหลอกแบบคงที่แบบบังคับการสกัดกั้นการเข้าถึงที่ไม่ได้รับอนุญาต (401/403) หรือรายงาน404หน้าแรกเริ่มต้น SLB จะพิจารณาว่าการตรวจสุขภาพล้มเหลว

การแก้ปัญหา:

หน้าตรวจสุขภาพพิเศษ: อย่าใช้หน้าแรกของเว็บไซต์เป็นเส้นทางตรวจสุขภาพขอแนะนำให้สร้างไฟล์แบบคงที่ที่มีน้ำหนักเบา (เช่น/healthcheck.html) ในไดเรกทอรีรากของบริการเว็บเนื้อหาจะถูกเขียนลงไป

การทดสอบ Back-end: ทดสอบเส้นทางโดยใช้คำสั่ง curl ใน ECS ท้องถิ่น: curl -I ht tp:// 127.0.0.1:80/healthcheck.html

ตรวจสอบให้แน่ใจว่ากลับส่วนหัวของการตอบสนอง HTTP เป็น HTTP/1.1

200 OK.

ปรับส่วนหัวของชื่อโดเมน: หาก Nginx ของคุณกำหนดค่าโฮสต์เสมือนแบบหลายไซต์และผูกไว้กับ server_name ที่ระบุคำขอเริ่มต้นที่ SLB อาจถูกจับคู่กับ Nginx เนื่องจากไม่มีส่วนหัวที่ถูกต้องและ default_server และส่งคืน403หรือ404ในขณะนี้คุณต้องกรอกชื่อโดเมนการตรวจสุขภาพอย่างชัดเจนในการกำหนดค่าขั้นสูงของการตรวจสุขภาพ SLB

3.ระบบ ECS ด้านหลังหมดทรัพยากร (CPU/หน่วยความจำ/IO ทะยาน)

หลักการและอาการ:

หากเว็บไซต์ได้รับผลกระทบจากการเข้าชมอย่างกะทันหันการโจมตี CC หรือมีการสืบค้นช้าและหน่วยความจำรั่วทำให้การใช้ CPU ของ ECS ถึง100% หรือหน่วยความจำหมด (OOM) เว็บเซิร์ฟเวอร์ (Nginx/PHP-FPM/Java) จะไม่สามารถตอบสนองต่อ SLB ได้ทันเวลาคำขอตรวจพบทำให้การตรวจสุขภาพทำงานล่วงเวลา

แนวทางการแก้ไข:

ตรวจสอบ CPU หน่วยความจำโหลดระบบและดิสก์ I/O Curve ของ CloudMonitor

ลงชื่อเข้าใช้ขั้ว ECS และใช้ top หรือ htop เพื่อดูกระบวนการที่ใช้ทรัพยากรมากที่สุด

หากทรัพยากรไม่เพียงพอที่เกิดจากการเติบโตตามปกติของธุรกิจควรอัปเกรดข้อกำหนด ECS หรือควรเพิ่มโหนดแบ็คเอนด์ให้ทันเวลาในขณะเดียวกันควรตรวจสอบให้แน่ใจว่าห่วงโซ่ทุนของบัญชีมีเสถียรภาพและเติมเงินในบัญชี Alibaba Cloud ให้เสร็จทันเวลาเพื่อหลีกเลี่ยงความล้มเหลวของการหักอินสแตนซ์การชำระเงินชั่วคราวบังคับปิดเครื่อง

4.หมดเวลา (Timeout) และการตั้งค่าช่วงเวลาการตรวจสุขภาพที่ไม่สมเหตุสมผล

หลักการและอาการ:

SLB ช่วยให้สามารถปรับแต่ง "หมดเวลาการตอบสนอง", "ช่วงเวลาการตรวจสุขภาพ", "เกณฑ์สุขภาพ" และ "เกณฑ์ที่ไม่แข็งแรง"

หากเวลาตอบสนองของแบ็คเอนด์บางครั้งใช้เวลา2วินาทีเนื่องจากตรรกะทางธุรกิจที่หนักกว่าและคุณตั้งค่า "หมดเวลาการตอบสนอง" ของ SLB เป็น1วินาทีและ "เกณฑ์ที่ไม่แข็งแรง" เป็น2ครั้งตราบใดที่การตรวจจับสองครั้งติดต่อกันค้างเล็กน้อย SLB จะกำหนดความล้มเหลวของโหนดทันทีทำให้เกิดความล้มเหลวในการตรวจสุขภาพบ่อยครั้ง

แนวทางการแก้ไข:

ปรับพารามิเตอร์การตรวจสุขภาพ SLB ให้เหมาะสมและแนะนำให้ใช้ชุดพารามิเตอร์ที่ค่อนข้างราบรื่น:

หมดเวลาตอบสนอง: ขอแนะนำให้ตั้งค่าที่3 ~ 5วินาที (ปล่อยให้เวลาบัฟเฟอร์สำหรับส่วนหลัง)

ช่วงเวลาการตรวจสุขภาพ: แนะนำให้ตั้งค่าเป็น2 ~ 5วินาที

เกณฑ์ที่ไม่แข็งแรง: ตั้งค่าเป็น3ครั้ง (นั่นคือความล้มเหลวติดต่อกัน3ครั้งจะถูกแยกออกอย่างสมบูรณ์เพื่อป้องกันไม่ให้เครือข่ายกระวนกระวายใจเป็นครั้งคราวและการวินิจฉัยผิด)

เกณฑ์สุขภาพ: ตั้งเป็น2 ~ 3ครั้ง

5.การเชื่อมต่อพร้อมกันของแบ็คเอนด์ถึงขีดจำกัดสูงสุดหรือปัญหา Keep-Alive

หลักการและอาการ:

การตรวจสอบสุขภาพของโปรโตคอล HTTP มักจะสร้างและตัดการเชื่อมต่อ TCP 。หากเว็บเซิร์ฟเวอร์แบ็กเอนด์ (เช่น Nginx หรือ Apache) การตั้งค่า

Max_clients

หรือจำนวนการเชื่อมต่อพร้อมกันสูงสุดมีขนาดเล็กเกินไปหรือมีซ็อกเก็ตมากเกินไปในสถานะ TIME_WAIT ซึ่งจะทำให้คิว TCP ส่วนหลังล้นและปฏิเสธคำขอการเชื่อมต่อใหม่ของ SLB

แนวทางการแก้ไข:

ปรับพารามิเตอร์เครือข่ายเคอร์เนลลินุกซ์ให้เหมาะสมที่สุด (/etc/sysctl.conf):Ini, TOMLnet. ipv4.tcp _ tw_reuse = 1 net. ipv4.tcp _ fin_timeout = 30 net.core.somaxconn = 1024

ปรับพารามิเตอร์การทำงานพร้อมกันสูงของ Nginx: ขยาย worker_connections และ keepalive_timeout ใน nginx.conf เพื่อให้แน่ใจว่ายังมีกระบวนการทำงานของผู้ปฏิบัติงานเพียงพอที่จะจัดการกับคำขอโพรบ SLB ภายใต้การทำงานพร้อมกันสูง

6.การตรวจสอบสุขภาพ TCP ภายใต้การเชื่อมต่อยาว/Websocket สถานการณ์

หลักการและอาการ:

สำหรับการตรวจสอบ TCP SLB จะสร้างการเชื่อมต่อโดยค่าเริ่มต้นผ่านการจับมือสามทาง (SYN -> SYN-ACK -> ACK) จากนั้นส่ง RST ทันทีเพื่อตัดการเชื่อมต่อเพื่อตรวจสอบสุขภาพแอปพลิเคชั่นแบ็คเอนด์หรือไฟร์วอลล์บางตัวจะตัดสินว่าพฤติกรรม "จับมือกันแต่ไม่ส่งข้อมูลและส่ง RST บ่อยๆ" เป็นการสแกนที่ผิดกฎหมายจากนั้นจึงบล็อก IP การตรวจจับ SLB อย่างแข็งขันทำให้การตรวจสุขภาพล้มเหลว

แนวทางการแก้ไข:

ไม่รวมการตรวจจับการจับมือที่ผิดปกติของส่วนเครือข่ายส่วนตัว SLB ในแอปพลิเคชันแบ็คเอนด์หรือไฟร์วอลล์

หากเป็นแอปพลิเคชัน HTTP ให้พยายามเปลี่ยนโหมดการตรวจสอบ SLB เป็นการตรวจสอบ HTTP/HTTPS เพื่อตรวจจับรหัสสถานะ HTTP ที่แม่นยำยิ่งขึ้น

3.ขั้นตอนการทำงาน "สี่ขั้นตอน" เพื่อแก้ไขปัญหาการตรวจสุขภาพ SLB

อย่าตกใจเมื่อคุณเห็นสัญญาณเตือน "Health Check Failed" สีแดงบนคอนโซลขอแนะนำให้ทำการวินิจฉัยอย่างรวดเร็วตามลำดับต่อไปนี้:

[ขั้นตอนแรก: ECS ท้องถิ่นทดสอบ]

ใช้ curl เพื่อทดสอบพอร์ตบริการในพื้นที่และ URL การตรวจสุขภาพเพื่อยืนยันว่าบริการแบ็คเอนด์นั้นเป็นปกติ

↓

[ขั้นตอนที่2: การตรวจสอบเครือข่ายและกลุ่มความปลอดภัย]

ตรวจสอบว่ากลุ่มรักษาความปลอดภัยและไฟร์วอลล์ภายใน (iptables) ได้ปล่อยส่วนเครือข่าย100.64.0.0/10หรือไม่

↓

[ขั้นตอนที่3: การจับแพ็คเก็ตและการวิเคราะห์บันทึก]

เรียกใช้แพ็กเก็ต tcpdump บน ECS เพื่อวิเคราะห์ว่าได้รับคำขอโพรบ SLB และรหัสส่งคืน HTTP เฉพาะหรือไม่

↓

[ขั้นตอนที่4: การตรวจสอบระบบคลาวด์และการตรวจสอบทรัพยากร]

ตรวจสอบการใช้ CPU/หน่วยความจำ/ดิสก์/แบนด์วิดท์ของระบบและยืนยันว่าสถานะบัญชี Alibaba Cloud และการหักทรัพยากรเป็นปกติหรือไม่

ในหมู่พวกเขา

คำสั่งจับแพ็คเก็ต

มีประโยชน์มากคุณสามารถเรียกใช้โดยตรงภายใน ECS:

Bash

# คว้าจาก SLB

การรับส่งข้อมูล80พอร์ตของส่วนเครือข่ายส่วนตัว

Tcpdump-i any src net 100.64.0.0/10 and dst port 80 -nn

โดยสังเกตว่ามี

SYN

การป้อนแพ็คเกจและการตอบสนอง

HTTP status

คุณสามารถค้นหาได้ในไม่กี่วินาทีว่าปัญหาเกิดขึ้นใน "ขั้นตอนการเชื่อมต่อเครือข่าย" หรือ "ขั้นตอนการตอบสนองของแอปพลิเคชันบนเว็บ"

4.สรุปมุมมอง SEO: ความเสถียรคือการเพิ่มประสิทธิภาพ SEO ที่ดีที่สุด

ในฐานะเครื่องมือเพิ่มประสิทธิภาพเว็บไซต์ SEO ฉันคิดว่าตรรกะพื้นฐานของการเพิ่มประสิทธิภาพเว็บไซต์ไม่ได้เกี่ยวกับการเขียนบทความและการเชื่อมโยงภายนอก

ความมั่นคงของโครงสร้างพื้นฐานเป็นรากฐานที่สำคัญของ SEO

。

หลีกเลี่ยงการลดกำลังของเครื่องมือค้นหา: ความล้มเหลวในการตรวจสุขภาพ SLB บ่อยครั้งจะทำให้ส่วนหน้าโยนข้อผิดพลาด502/504เป็นระยะๆหลังจากสไปเดอร์ของเครื่องมือค้นหาพบข้อผิดพลาดดังกล่าวหลายครั้งมันจะระบุได้อย่างรวดเร็วว่าเซิร์ฟเวอร์ของเว็บไซต์ไม่เสถียรส่งผลให้การรวมหยุดนิ่งและอันดับลดลง

รับประกันประสบการณ์ของผู้ใช้และอัตรา Conversion: เว็บไซต์ที่มีความพร้อมใช้งานสูงและมีเวลาแฝงต่ำสามารถลดอัตราตีกลับ (Bounce Rate) ได้อย่างมีนัยสำคัญและปรับปรุงเวลาการเข้าพักของหน้าข้อมูลพฤติกรรมผู้ใช้เหล่านี้ยังเป็นตัวบ่งชี้ที่สำคัญสำหรับเครื่องมือค้นหาในการประเมินคุณภาพของหน้า

ให้ความสนใจกับรายละเอียดการดำเนินงานและการบำรุงรักษาและการจัดการทรัพยากร: เพื่อให้แน่ใจว่าโครงสร้างพื้นฐานมีความพร้อมใช้งานสูงไม่เพียงแต่สะท้อนให้เห็นในโค้ดและสถาปัตยกรรมเท่านั้นแต่ยังรวมถึงการจัดการทรัพยากรระบบคลาวด์ขององค์กรประจำวันด้วยการรักษาการจัดการเงินทุนที่เพียงพอและการเติมเงินในบัญชี Alibaba Cloud อย่างทันท่วงทีสามารถทำให้มั่นใจได้ว่าส่วนประกอบต่างๆเช่น SLB, CDN, Cloud Security Protection (WAF) และการตรวจสอบระบบคลาวด์จะทำงานอย่างต่อเนื่องและมีประสิทธิภาพเพื่อป้องกันปัญหาก่อนที่จะเกิดขึ้น

ด้วยความเข้าใจในเชิงลึกเกี่ยวกับกลไกการตรวจสุขภาพ SLB การกำหนดค่ากฎการตรวจจับที่เหมาะสมการปล่อยกลุ่มความปลอดภัยและการตรวจสอบประสิทธิภาพของเซิร์ฟเวอร์ส่วนหลังตลอดเวลาคุณสามารถแก้ปัญหาเรื้อรังของความล้มเหลวในการตรวจสุขภาพบ่อยครั้งและสร้างรากฐานที่มั่นคงและมีความพร้อมใช้งานสูงสำหรับเว็บไซต์ของคุณสถาปัตยกรรม!