Monit เฝ้าดูว่าบริการยังทำงานอยู่และยกมันขึ้นมาเมื่อล้ม คำถามแรกที่ยุติธรรม: ทำไมต้องใช้ ในเมื่อ systemd ทำเรื่องเดียวกันได้ด้วยบรรทัดเดียวคือ Restart=always

คำตอบกำหนดการจัดวางทั้งหมด systemd เห็นว่ากระบวนการจบไปแล้วก็เริ่มมันใหม่ แต่มันไม่รู้ว่าบริการตอบคำขอได้หรือไม่ PHP-FPM ที่ชนขีดจำกัดจำนวนกระบวนการนั้นยังมีชีวิตและแข็งแรงดีในสายตา systemd ในขณะที่เว็บไซต์คืนค่า 502 และ MySQL ที่ดิสก์หมดก็ยังทำงานในฐานะกระบวนการและไม่รันคิวรีสักตัว ในขณะที่ Monit ไม่ได้ตรวจว่ากระบวนการมีอยู่หรือไม่ แต่ตรวจพฤติกรรมของมัน: พอร์ตตอบไหม คำขอ HTTP คืนอะไร ใช้หน่วยความจำเท่าไร

จากตรงนี้จึงได้กฎ: ปล่อย systemd ไว้อย่างที่เป็นแล้วเพิ่ม Monit สำหรับการตรวจเชิงหน้าที่ ไม่มีประโยชน์ที่จะทำงานรีสตาร์ตกระบวนการที่ล้มซ้ำซ้อนกัน

การจัดวาง

sudo apt install monit

ไฟล์หลักคือ /etc/monit/monitrc การตรวจของคุณเองไปอยู่ใน /etc/monit/conf.d/ เป็นไฟล์แยก การเริ่มต้นตามปกติ:

set daemon 60
set logfile /var/log/monit.log
set mailserver localhost
set alert admin@example.com

การสำรวจนาทีละครั้งเป็นสมดุลที่สมเหตุสมผล ถี่กว่านั้นเพิ่มภาระและเพิ่มความเสี่ยงของการรีสตาร์ตผิดพลาดเพราะความล่าช้าเพียงหนึ่งวินาที

เว็บอินเทอร์เฟซ: เฉพาะในเครื่อง

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

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'a-long-password'

การเข้าถึงจากภายนอกผ่านอุโมงค์ SSH:

ssh -L 2812:localhost:2812 user@203.0.113.25

หลังจากนั้นหน้าเว็บจะเปิดบนคอมพิวเตอร์ของคุณเองที่ localhost:2812 และไม่มีอะไรหันออกข้างนอกเลย

การตรวจที่มีความหมาย

เว็บเซิร์ฟเวอร์ — ไม่ใช่จากการมีอยู่ของกระบวนการแต่จากคำตอบของมัน:

check process nginx with pidfile /run/nginx.pid
    start program = "/bin/systemctl start nginx"
    stop program  = "/bin/systemctl stop nginx"
    if failed host 127.0.0.1 port 80 protocol http
        request "/" status = 200
        for 3 cycles then restart
    if 3 restarts within 10 cycles then unmonitor

ตรงนี้มีสามบรรทัดที่สำคัญกว่าที่เหลือ

protocol http ... status = 200 คือการตรวจที่ทั้งหมดนี้ถูกตั้งขึ้นมาเพื่อมัน: เซิร์ฟเวอร์ต้องคืนหน้าเว็บ ไม่ใช่แค่เปิดพอร์ตค้างไว้

for 3 cycles หมายถึงอย่าตอบสนองต่อความล้มเหลวครั้งเดียว ถ้าไม่มีมัน Monit จะรีสตาร์ตบริการเพราะการตอบสนองช้าเพียงครั้งเดียวภายใต้ภาระ ซึ่งมีแต่ทำให้เรื่องแย่ลง

if 3 restarts within 10 cycles then unmonitor เป็นบรรทัดที่บังคับ ถ้าบริการขึ้นไม่ได้เพราะความผิดพลาดในไฟล์ตั้งค่า Monit จะรีสตาร์ตมันไปตลอดกาล เพิ่มภาระและถมล็อกจนเต็ม บรรทัดนี้บอกว่า: ล้มเหลวสามครั้ง หยุดแล้วทิ้งข้อความไว้ สิ่งที่ต้องการต่อจากนั้นคือมนุษย์ ระบบอัตโนมัติช่วยอะไรไม่ได้แล้ว

พื้นที่ดิสก์ถูกตรวจโดยไม่มีระบบอัตโนมัติใด ๆ เป็นเพียงการแจ้งเตือนเท่านั้น:

check filesystem rootfs with path /
    if space usage > 85% then alert
    if inode usage > 85% then alert

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

การตรวจไฟล์ตั้งค่า

sudo monit -t
sudo systemctl reload monit
sudo monit summary
sudo monit status

monit -t ตรวจไวยากรณ์ก่อนนำไปใช้ ส่วน monit summary ให้ตารางสถานะแบบสั้น — จุดที่ควรเริ่มเมื่อตรวจสอบปัญหาใด ๆ

และตรวจด้วยว่าเมลถูกส่งจริง Monit รายงานเหตุการณ์ทางอีเมล และถ้าไม่ได้ตั้งค่าการส่งไว้ก็จะไม่มีการแจ้งเตือน: บริการจะรีสตาร์ตแล้วคุณก็ไม่รู้ — ในขณะที่การรีสตาร์ตซ้ำ ๆ นั่นแหละคือสัญญาณหลัก มันดูได้ในล็อกด้วย: /var/log/monit.log

สิ่งที่ Monit ไม่ทำ

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

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