กลยุทธ์การตรวจสอบสำหรับโครงสร้างพื้นฐาน

เมื่อเร็ว ๆ นี้ฉันได้พบกับการหยุดทำงานของบางเว็บไซต์ Drupal ที่ฉันได้ปรับใช้ ฉันต้องการที่จะเข้าถึงปัญหาในเชิงรุกมากกว่าที่จะตอบสนองต่อการหยุดทำงานเหล่านั้นด้วยการรีสตาร์ทบริการหรือเซิร์ฟเวอร์เอง ฉันได้อ่านเกี่ยวกับเครื่องมือตรวจสอบเช่น nagios, munin, cacti และอื่น ๆ เพื่อตรวจสอบสถานะของเซิร์ฟเวอร์ / โครงสร้างพื้นฐานของคุณ แต่ฉันไม่ได้ลองใช้งานจริง ฉันจัดการกับ Drupal เกือบ 99% ของเวลาและฉันต้องการค้นหาคำแนะนำสำหรับการตรวจสอบระดับเซิร์ฟเวอร์และการตรวจสอบระดับ Drupal (รหัสแอปพลิเคชัน)

โดยทั่วไปฉันต้องการรับการแจ้งเตือนเมื่อโหลดเซิร์ฟเวอร์สูงอาจชี้ไปที่ผู้ร้าย (หรือเหยื่อ) เพื่อที่ฉันจะได้สามารถตัดสินใจได้อย่างชาญฉลาด ฉันต้องการทราบว่าผู้คนใช้อะไรในการติดตามระดับ Drupal (เช่นการส่งอีเมล) เมื่อมีข้อผิดพลาด / คำเตือนของ PHP (จะเกิดอะไรขึ้นเมื่อเซิร์ฟเวอร์อีเมลไม่ทำงาน)

หากคุณต้องการตรวจสอบเว็บไซต์ Drupal หลายแห่งจากที่เดียวกันด้วยการแจ้งเตือน ฯลฯ ... ฉันบอกได้เลยว่าคุณไม่ใช่คนเดียว มันเริ่มเป็นช่องทางธุรกิจโดยตอนนี้เต็มไปด้วย:

• Droptor

• ใหม่ที่ระลึก ( Acquiaใช้มันสำหรับลูกค้าของพวกเขา)

ทั้งสองเป็นวิธี SaaS เชิงพาณิชย์ด้วยตัวเลือกที่ จำกัด ฟรีเพื่อลองใช้บริการ

นอกจากนี้ยังมีตัวเลือกการติดตามโอเพ่นซอร์สZabbixพร้อมโมดูล Drupal http://drupal.org/project/zabbixแต่คุณควรกำหนดค่าและสร้างเซิร์ฟเวอร์ของคุณเอง

ตัวเลือกทั้งหมดเหล่านี้มีโมดูล Drupal เพื่อส่งข้อมูลเซิร์ฟเวอร์และข้อมูลเฉพาะของ Drupal ไปยังเซิร์ฟเวอร์มอนิเตอร์

UPDATE Muninยังมีโมดูล Drupal ที่เฉพาะเจาะจงโดยมีสาขา 2.x ตั้งอยู่บนพื้นฐานของ Drush

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

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

• แจ้งให้คุณทราบหากมีเว็บไซต์เกิดขึ้น (แน่นอน)
• วัดระยะเวลาตอบสนอง
• วัดการตอบสนองและความพร้อมใช้งานบนพอร์ต TCP / UDP แบบกำหนดเองใด ๆ
• ตรวจสอบสถานะอีเมล
• อนุญาตสำหรับคำขอ HTTP ที่กำหนดเองช่วยให้คุณทดสอบแง่มุมต่าง ๆ ของแอปพลิเคชันของคุณ
• การรายงานอย่างกว้างขวาง
• การตรวจสอบทั่วโลกและพวกเขาเพิ่มเว็บไซต์ตรวจสอบมากกว่าหนึ่งโหลทุกสองสามเดือน

นี่คือคำแนะนำที่ไม่เชื่อเรื่องพระเจ้าของ Drupal:

• My Sites Upจะส่ง Ping เซิร์ฟเวอร์ของคุณเป็นระยะและจะส่งอีเมลถึงคุณ (หรือ SMS หากคุณได้รับแพ็คเกจที่ไม่ต้องเสียค่าใช้จ่าย) หากไซต์ของคุณออฟไลน์หรือไม่ตอบสนอง
• ผลกระทบต่อการโหลดเป็นอีกหนึ่งเครื่องมือฟรีที่ยอดเยี่ยมที่สามารถทดสอบเว็บไซต์ของคุณเพื่อให้คุณสามารถบอกได้ว่าเมื่อใดที่เริ่มต้นล้มเหลว

เท่าที่แอพพลิเคชั่น Drupal นั้นฉันขอแนะนำให้ใช้Xdebug + WebgrindหรือXHProfเพื่อทำโปรไฟล์รหัสและจับตามองคำถามนี้: วิธีที่ดีที่สุดในการวัดประสิทธิภาพของ Drupal stack

ฉันชอบ pingdom สำหรับไซต์ขนาดเล็ก / กลางเพราะมีประโยชน์: มันบอกคุณว่ามีบางอย่างผิดปกติจากมุมมองของลูกค้าซึ่งสามารถดำเนินการได้ สิ่งต่าง ๆ เช่นโหลดเฉลี่ยไม่ได้มีความหมายอะไรเลยนอกจากว่าคุณมีกองซ้อนที่กำหนดค่าผิดพลาด (ซึ่งคุณไม่ควร) หรือคุณถูกทุบจาก Digg / Reddit (ซึ่งในกรณีนี้ไม่มีอะไรที่คุณสามารถทำได้คุณควรมี เตรียม)

จากบล็อกของ Ted Dziuba:

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

• โหลดเฉลี่ยบนเซิร์ฟเวอร์สูงกว่า 20
• คิวงานมีหน่วยงาน X มากกว่าหน่วย ขอแสดงความยินดี, พล่าม, คิวของคุณกำลังทำสิ่งที่ควรทำ
• ตัวชี้วัดบางตัวมีค่ามากกว่าค่าเฉลี่ยที่กำหนดเชิงประจักษ์ ฉันรู้สึกขุ่นเคืองเป็นการส่วนตัวเช่นนี้

อ่านโพสต์บล็อกมันเฮฮา

ฉันใช้check_drupalเพื่อตรวจสอบเว็บไซต์ drupal ต่างๆ นี่คือปลั๊กอิน nagios ซึ่งไม่ต้องการการเปลี่ยนแปลงรหัสใด ๆ กับเว็บไซต์ drupal ข้อกำหนดเพียงอย่างเดียวคือต้องมีdrushอยู่บนเซิร์ฟเวอร์