Apache2 ล่มบ่อยครั้งเมื่อใช้ HestiaCP? คู่มือการตรวจสอบและแก้ไขปัญหาอัตโนมัติด้วย Monit (พร้อมการตั้งค่าที่สมบูรณ์)

พบปัญหา Apache2 ขัดข้องบ่อยครั้ง หรือการรีสตาร์ทอัตโนมัติของ Monit ล้มเหลวในสภาพแวดล้อม HestiaCPหรือไม่? บทความนี้จะให้คำแนะนำเชิงปฏิบัติเพื่อหลีกเลี่ยงข้อผิดพลาดทั่วไปเมื่อตรวจสอบ Apache2 ด้วย Monit โดยวิเคราะห์ปัญหาทั่วไปอย่างละเอียด เช่น ความไม่ตรงกันของเส้นทาง PID และการบล็อกสิทธิ์ และนำเสนอไฟล์การกำหนดค่าการทำงานอัตโนมัติของ Monit ที่ใช้งานได้จริง เรียนรู้เทคนิคการบำรุงรักษาเซิร์ฟเวอร์ที่มีความพร้อมใช้งานสูง และบรรลุการกู้คืนอัตโนมัติระดับที่สองจากความล้มเหลวได้แล้ววันนี้!

ปัญหาที่ฉันพบเจอขณะใช้ Monit ในการตรวจสอบ Apache2

เมื่อวันศุกร์ที่แล้ว เซิร์ฟเวอร์แจ้งเตือน Monit ให้ผมทราบกลางดึก

ฉันเหลือบมองแผงควบคุมอย่างเหม่อลอย และในคอลัมน์สถานะของ apache2 ก็มีคำว่า Timeout สีแดงปรากฏขึ้น

ฉันคิดเรื่องนี้อยู่สักพัก ฉันเพิ่งเพิ่มโปรแกรมตรวจสอบ Monit ลงในเซิร์ฟเวอร์ระหว่างวัน และฉันก็คัดลอกและวางการตั้งค่าจากบทช่วยสอนออนไลน์ ไม่น่าจะมีปัญหาอะไรใช่ไหม?

เช้าวันต่อมา มันก็หมดเวลาอีกครั้ง หลังจากครั้งที่สาม โปรแกรมมอนิเตอร์ก็หยุดทำงาน และหน้าจอแสดงผลว่า "ไม่ได้ตรวจสอบ"

ฉัน...

ยอมรับว่าตอนแรกฉันไม่ได้คิดอะไรจริงจัง การมอนิเตอร์ด้วย Apache2 เหรอ? คุณสามารถหาเทมเพลตการตั้งค่าได้มากมายบนอินเทอร์เน็ต แค่คัดลอกและวางก็พอแล้ว แต่ขั้นตอนการวางนี่แหละที่ทำให้ฉันหัวเสียจริงๆ

สาเหตุหลักของความขัดแย้งระหว่างสถาปัตยกรรมเริ่มต้นของ HestiaCP และพอร์ตของ Monit

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

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

ดูเหมือนจะปกติดีใช่ไหม? มันตรวจสอบพอร์ต 80 และหากเกิดข้อผิดพลาด มันจะรีสตาร์ท หากยังคงเกิดข้อผิดพลาดหลังจากรีสตาร์ท 5 ครั้ง ระบบจะหมดเวลา

ปัญหาคือ Apache2 ของคุณไม่ได้ทำงานอยู่บนพอร์ต 80 ด้วยซ้ำ

นี่คือจุดอ่อนของ HestiaCP และเป็นสาเหตุหลักที่ทำให้หลายคนตกหลุมพรางนี้ สถาปัตยกรรมเริ่มต้นของ HestiaCP คือการใช้ Reverse Proxy ของ Nginx + Apache2 โดย Nginx ใช้พอร์ต 80 และ 443 อยู่ด้านหน้า และ Apache2 ทำงานบนพอร์ต 8081 ในเครื่องเดียวกันอยู่ด้านหลัง

ถ้าคุณขอให้ Monit ตรวจสอบสถานะการทำงานของ Apache2 บนพอร์ต 80 มันก็เหมือนกับการไปแมคโดนัลด์เพื่อหาเคเอฟซี เซิร์ฟเวอร์จะมองคุณด้วยสีหน้าว่างเปล่า และคุณกับเซิร์ฟเวอร์ก็จะจ้องมองกัน ในที่สุด Monit ก็จะสรุปว่าเซิร์ฟเวอร์ของคุณล่มและเริ่มรีสตาร์ทอย่างบ้าคลั่ง

หลังจากรีสตาร์ทแล้ว พอร์ตยังคงเป็น 8081 จากนั้น Monit จะลองตรวจสอบพอร์ต 80 ซึ่งก็ล้มเหลวเช่นกัน จึงรีสตาร์ทอีกครั้ง วงจรนี้จะวนซ้ำไปเรื่อยๆ จนกว่า Monit จะตัดสินใจว่าไม่สามารถแก้ไขได้แล้วและหมดเวลาไป

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

ไฟล์ PID ของ Apache2 ที่เสียหายทำให้ Monit เข้าใจผิดว่ากระบวนการดังกล่าวไม่มีอยู่จริง

หลังจากเปลี่ยนพอร์ตจาก 80 เป็น 8081 แล้ว ตามทฤษฎีแล้ว Monit ควรจะตรวจจับได้ใช่ไหม?

อย่างไรก็ตาม ในความเป็นจริงแล้ว บางครั้งมันก็ยังแสดงข้อความว่า "การดำเนินการล้มเหลว " อยู่ดี

หลังจากพยายามอยู่นาน ในที่สุดฉันก็ค้นพบว่าสาเหตุนั้นง่ายมาก: ไฟล์ PID เสียหาย

ลองนึกภาพดู Monit กำลังรีสตาร์ท Apache2 อย่างบ้าคลั่ง โดยแต่ละครั้งจะบังคับปิดและรีสตาร์ทมัน วนไปวนมาหลายรอบ ในระหว่างกระบวนการนี้ ไฟล์ /var/run/apache2/apache2.pid อาจมีขนาดเหลือ 0 ไบต์

กล่าวอีกนัยหนึ่ง ไฟล์ยังคงอยู่ แต่ว่างเปล่า

เมื่อ Monit อ่านไฟล์นี้ มันจะไม่พบอะไรเลย มันไม่รู้จัก Apache2 ของคุณ แม้ว่า Apache2 ของคุณจะทำงานได้อย่างสมบูรณ์แบบในพื้นหลังก็ตาม Monit ไม่คิดว่ากระบวนการนั้นมีอยู่จริง

เมื่อฉันเห็นเช่นนั้น ฉันถึงกับพูดไม่ออกไปชั่วขณะ

นี่คือภาวะชะงักงัน Monit ตรวจไม่พบอินสแตนซ์ Apache 2 จึงรีสตาร์ท Apache2 ทำให้ไฟล์ PID เสียหายระหว่างกระบวนการรีสตาร์ท ตรวจไม่พบในครั้งต่อไป และรีสตาร์ทอีกครั้ง วงจรนี้จะดำเนินต่อไปจนกว่าจะหมดเวลา

ขั้นตอนการแก้ไขปัญหาและซ่อมแซมสำหรับการตรวจสอบ Apache2 ในสภาพแวดล้อม HestiaCP

พูดตามตรง กระบวนการสืบสวนไม่ซับซ้อน แต่คุณต้องรู้ว่าควรสืบสวนไปในทิศทางใด

ขั้นตอนแรกคือการตรวจสอบว่า Apache2 ของคุณกำลังรับฟังอยู่ที่พอร์ตใด เพียงพิมพ์คำสั่งในเทอร์มินัล

netstat -tulpn | grep apache2

อีกทางเลือกหนึ่ง คุณสามารถใช้คำสั่ง `ss` ได้ ผลลัพธ์จะเหมือนกัน

ss -tulpn | grep apache2

คุณจะเห็นผลลัพธ์ที่คล้ายกับนี้

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

ยืนยันแล้วว่าเป็น 8081 ไม่ใช่ 80 นั่นแหละคือต้นตอของปัญหา

ขั้นตอนที่สองคือการซ่อมแซมไฟล์ PID ที่เสียหาย ขั้นตอนนี้ง่ายกว่า

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

ขั้นแรก ให้หยุดการตรวจสอบของ Monit ชั่วคราวเพื่อป้องกันไม่ให้รบกวนขณะที่คุณกำลังแก้ไขปัญหา จากนั้น ให้รีสตาร์ท Apache2 เพื่อให้มันเขียน PID ใหม่ที่สะอาด สุดท้าย ใช้คำสั่ง `cat` เพื่อตรวจสอบเนื้อหาของไฟล์ ควรมีสตริงของตัวเลข ไม่ใช่สตริงว่างเปล่า

เมื่อทำขั้นตอนนี้เสร็จแล้ว ปัญหาจะได้รับการแก้ไขโดยพื้นฐานแล้ว

การวิเคราะห์เปรียบเทียบรูปแบบการป้องกันแบบปรับตัวและแบบก้าวร้าวแบบดั้งเดิมของ Monit

บทแนะนำออนไลน์เกี่ยวกับการตั้งค่า Apache2 ร่วมกับ Monit โดยทั่วไปแบ่งออกเป็นสองประเภท

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

อีกแนวทางหนึ่งคือวิธีการ "การป้องกันเชิงรุก" ซึ่งใช้ systemctl ในการจัดการบริการ เพิ่มข้อจำกัดสำหรับกระบวนการลูก และใช้ตรรกะการตรวจจับที่เข้มงวดกว่า วิธีนี้ดูดี แต่มีข้อบกพร่องร้ายแรงคือ คำสั่งหยุดที่ใช้คือ `killall -9`

`killall -9` หมายความว่าอย่างไร? มันหมายถึงการบังคับปิดเครื่องโดยไม่คำนึงถึงว่ามันกำลังทำอะไรอยู่ การกระทำแบบใช้กำลังอย่างรุนแรงนี้อาจทำให้ไฟล์ PID เสียหายได้ ซึ่งเป็นปัญหาที่ผมเพิ่งกล่าวถึงไป

จากประสบการณ์ส่วนตัวของผม การจำกัดจำนวนกระบวนการลูกในคอนฟิกแบบรุนแรงนั้นมีประโยชน์จริง ๆ เมื่อ Apache2 ของคุณถูกโจมตีด้วย CC อย่างหนัก การจำกัดจำนวนกระบวนการลูกสามารถป้องกันไม่ให้เซิร์ฟเวอร์หน่วยความจำหมดได้ อย่างไรก็ตาม วิธีการใช้คำสั่ง `killall -9` นั้นใช้การไม่ได้จริง ๆ

สุดท้ายแล้วฉันจึงประนีประนอมและนำข้อดีของทั้งสองแบบมารวมกัน

การกำหนดค่าแนวทางปฏิบัติที่ดีที่สุดของ HestiaCP Apache2 Monit

แก้ไขไฟล์ /etc/monit/conf.d/apache2 โดยเพิ่มเนื้อหาต่อไปนี้เข้าไป

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

ขออนุญาตอธิบายหลักการเบื้องหลังการตั้งค่าเพียงไม่กี่บรรทัดนี้โดยสังเขปครับ

ควรใช้พอร์ต 8081 เพื่อให้ตรงกับสถาปัตยกรรมรีเวิร์สพร็อกซีของ HestiaCP อย่างแม่นยำ เลิกใช้พอร์ต 80 อย่างไม่จำเป็นเสียที

ใช้คำสั่ง `systemctl stop` แทน `killall -9` เพื่อหยุดไฟล์ PID เพื่อป้องกันไม่ให้ไฟล์เสียหาย

มีการเพิ่มข้อจำกัดเกี่ยวกับกระบวนการลูก: หากจำนวนกระบวนการลูกเกิน 120 กระบวนการจะเริ่มต้นใหม่หลังจากสองรอบติดต่อกันเพื่อป้องกันการโจมตีแบบ CC แต่ก็ไม่ได้รุนแรงเกินไป

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

เกณฑ์การหมดเวลาสุดท้ายถูกผ่อนปรนให้สามารถรีสตาร์ทได้ 5 ครั้งภายใน 10 รอบการทำงาน ซึ่งยังคงมีความทนทานต่อความผิดพลาดอย่างเพียงพอ

เฮสเทียซีพี ติดตามตรวจสอบสรุปการแก้ไขปัญหาการกำหนดค่าและการแบ่งปันประสบการณ์

หลังจากทำการเปลี่ยนแปลงการตั้งค่าแล้ว ผมได้ตรวจสอบ apache2 และในที่สุดแผงควบคุมก็แสดงตัวบ่งชี้สีเขียว "OK"

จะอธิบายความรู้สึกของฉันในตอนนั้นยังไงดี? มันเหมือนกับการเสียเวลาสองวันไปกับการแก้บั๊ก แล้วสุดท้ายก็พบว่าสาเหตุมาจากบรรทัดการตั้งค่าเพียงบรรทัดเดียวที่ผิดพลาด มันทั้งน่าหงุดหงิดและน่าขำไปพร้อมๆ กัน

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

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

ดังนั้น หากคุณกำลังใช้ HestiaCP และทดลองใช้ Monit เพื่อตรวจสอบ Apache2 โปรดจำไว้สองสิ่งนี้: เปลี่ยนพอร์ตเป็น 8081 และใช้คำสั่ง `systemctl` เพื่อหยุดการทำงาน ไม่ใช่ `killall -9` หากคุณทำสองสิ่งนี้ คุณก็จะสามารถหลีกเลี่ยงปัญหาเพิ่มเติมได้

เนื่องจากคุณอ่านมาถึงตรงนี้แล้ว ถ้าคุณคิดว่ามีประโยชน์ โปรดกดไลค์และแชร์ด้วยนะคะ และถ้าอยากรับข่าวสารอัปเดตก่อนใคร สามารถติดตามฉันได้เลยค่ะ!

ขอบคุณที่อ่านบทความของฉัน แล้วพบกันใหม่ครั้งหน้า