ทำให้ monit รออีกต่อไปก่อนที่จะคิดว่ามีบางอย่างเสียชีวิต


20

ฉันพยายามเริ่มโปรแกรม (Resque) แต่ใช้เวลาสักครู่ก่อนเขียนไฟล์ pidfile ดังนั้นฉันคิดว่า Monit คิดว่าโปรแกรมยังไม่เริ่มและเริ่มโปรแกรมหนึ่งหรือสองโปรแกรมก่อนที่จะเขียน pidfile ของโปรแกรมแรก

ฉันจะหน่วงเวลาที่ Monit ตรวจสอบอีกครั้งเพียงแค่สำหรับกระบวนการนี้ได้อย่างไร หรือฉันควรแก้ปัญหานี้ในอีกทางหนึ่ง?


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

คำตอบ:


10

ฉันจะหน่วงเวลาที่ Monit ตรวจสอบอีกครั้งเพียงแค่สำหรับกระบวนการนี้ได้อย่างไร


สิ่งที่คุณพยายามจะทำให้สำเร็จนั้นสามารถทำได้ผ่านฟีเจอร์" SERVICE POLL TIME " ของ monit

เอกสาร Monit กล่าวว่า

บริการจะถูกตรวจสอบในช่วงเวลาปกติที่กำหนดโดย

set daemon n

คำให้การ. การตรวจสอบจะดำเนินการในลำดับเดียวกับที่เขียนในไฟล์. monitrc ยกเว้นว่าการพึ่งพาเป็นการติดตั้งระหว่างบริการในกรณีนี้ลำดับชั้นของบริการอาจสลับลำดับของการตรวจสอบ

วิธีหนึ่งในการปรับแต่งแบบสำรวจความคิดเห็นคือ

  1. ช่วงเวลาที่กำหนดเองขึ้นอยู่กับความยาววงจรสำรวจความคิดเห็นหลายรายการ

ทุก ๆ [หมายเลข] รอบ

ตัวอย่าง:

check process resque with pidfile /your/app/root/tmp/pid/resque.pid
   every 2 cycles

หรือฉันควรแก้ปัญหานี้ในอีกทางหนึ่ง?


ฉันยังพยายามครั้งแรกในการตรวจสอบงานที่ต้องทำใหม่ด้วย monit เพราะ monit เป็น daemon ที่เบามาก แต่ในที่สุดก็ตัดสินด้วย GOD ฉันรู้ว่าฉันรู้ว่าพระเจ้าเป็นทรัพยากรหิวมากเมื่อเทียบกับ monit แต่ในกรณีของการต่อต้านเราพบว่ามันเป็นคู่ที่ดี


ขอบคุณ! ฉันลงเอยด้วยการใช้ทุก ๆ x รอบ ฉันเพิ่งพบหมายเลขที่เหมาะกับฉัน
Ramon Tayag

19

คุณสามารถตรวจสอบบริการเฉพาะในช่วงเวลาที่แตกต่างจากค่าเริ่มต้น ...

ดูSERVICE POLL TIMEในเอกสาร Monit

ตัวอย่างสำหรับโปรแกรม Resque ของคุณคือตรวจสอบจำนวนรอบที่แตกต่างกัน:

check process resque with pidfile /var/run/resque.pid
   every 5 cycles

หรือจากส่วนตัวอย่าง:

Some servers are slow starters, like for example Java based Application Servers. 
So if we want to keep the poll-cycle low (i.e. < 60 seconds) but allow some services to take its time to start, 
the every statement is handy:

 check process dynamo with pidfile /etc/dynamo.pid every 2 cycles
       start program = "/etc/init.d/dynamo start"
       stop program  = "/etc/init.d/dynamo stop"
       if failed port 8840 then alert

หรือคุณสามารถใช้ประโยชน์จากการตรวจสอบสไตล์ cron

check process resque with pidfile /var/run/resque.pid
   every 10 * * * *

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

check process apache with pidfile /var/run/httpd.pid
       start program = "/etc/init.d/httpd start" with timeout 90 seconds

คำตอบเดียวกันใช่มั้ย
ewwhite

2
with timeout 90 secondsเป็นสิ่งที่ฉันต้องการ ขอบคุณ
แอนดรูว์

1
รุ่งโรจน์สำหรับการรวมการหมดเวลาและสไตล์ cron นี่คือคำตอบที่ถูกต้องและครบถ้วนที่สุด
RCross

9

นอกจากนี้คุณยังสามารถตรวจสอบว่าบางสิ่งบางอย่างล้มเหลวเป็นเวลา X ตรง:

 if failed 
    port 80 
    for 10 cycles 
 then alert

หรือสำหรับ X คูณภายในโพล Y:

 if failed 
    port 80
    for 3 times within 5 cycles 
 then alert

หรือทั้งคู่:

 check filesystem rootfs with path /dev/hda1
  if space usage > 80% for 5 times within 15 cycles then alert
  if space usage > 90% for 5 cycles then exec '/try/to/free/the/space'

( จากที่นี่ )


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

2

สมาชิกในทีมของฉันคิดวิธีแก้ปัญหาที่ค่อนข้างฉลาดซึ่งอนุญาตให้ monit ตรวจสอบบ่อยครั้ง (ทุกนาที)แต่เมื่อพยายามเริ่มบริการใหม่ (ซึ่งใช้เวลาประมาณ 10 นาที) จะรอระยะเวลาผ่อนผันที่ระบุไว้ก่อนที่จะพยายามเริ่ม อีกครั้ง

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

check host bamboo with address bamboo.mysite.com
   if failed
           port 443 type tcpSSL protocol http
           and status = 200
           and request /about.action
            for 3 cycles
   then exec "/bin/bash -c 'ps -ef | grep -v "$$" | grep -v "grep" | grep restartBamboo.sh >/dev/null 2>&1; if [ $? -ne 0 ]; then /opt/monit/scripts/restartBamboo.sh; fi'"

หาก Bamboo (เว็บแอปเริ่มต้นช้า) ไม่ทำงานติดต่อกัน 3 นาทีให้เริ่มต้นใหม่ แต่ถ้าสคริปต์รีสตาร์ทยังไม่ได้ทำงาน

สคริปต์ที่ถูกเรียกนั้นมีโหมดสลีปที่ระบุซึ่งรอ LONGER ดังนั้นเวลาเริ่มต้นที่ช้าที่สุดสำหรับการให้บริการ

#!/bin/bash
echo "Retarting bambo by calling init.d"
/etc/init.d/bamboo stop
echo "Stopped completed, calling start"
/etc/init.d/bamboo start
echo "Done restarting bamboo, but it will run in background for sometime before available so, we are sleeping for 15 minutes"
sleep 900
echo "done sleeping"

2

รุ่นปัจจุบันของ Monit (5.16) สนับสนุนการหมดเวลาสำหรับสคริปต์เริ่มต้นด้วยไวยากรณ์:

 <START | STOP | RESTART> [PROGRAM] = "program"
    [[AS] UID <number | string>]
    [[AS] GID <number | string>]
    [[WITH] TIMEOUT <number> SECOND(S)]

เอกสารระบุ:

ในกรณีของการตรวจสอบกระบวนการ Monit จะรอ 30 วินาทีเพื่อให้การเริ่ม / หยุดการกระทำเสร็จก่อนที่จะยอมแพ้และรายงานข้อผิดพลาด คุณสามารถลบล้างการหมดเวลานี้ได้โดยใช้ตัวเลือก TIMEOUT

ซึ่งเป็นสิ่งที่ค่า "หมดเวลา" จะทำ


การขยายการหมดเวลาใช้งานได้หากการเริ่มต้นจริงใช้เวลานาน แต่ในคำถามเดิมดูเหมือนว่าโปรแกรมอาจเริ่มต้นอย่างรวดเร็ว (เช่นส่งคืน) แต่ไม่ได้เขียน PID ทันที มีวิธีบอกให้ Monit ว่าไม่ได้ตรวจสอบบริการตามเวลาที่กำหนดหลังจากรีสตาร์ทหรือไม่?
PeterVermont

timeoutควรนำไปใช้ทั้งสองเริ่มต้นและเริ่มต้นใหม่ เท่าที่ฉันเข้าใจมันทำให้เกิดความล่าช้าก่อนที่ Monit จะตรวจสอบว่า: a) กำลังทำงานอยู่ b) ไฟล์ PID ที่คาดหวังถูกสร้างขึ้นและ c) กระบวนการที่ PID ที่คาดการณ์กำลังทำงานอยู่ในปัจจุบัน ฉันมีปัญหาบางอย่างในการทำให้มันทำงานเมื่อแอปพลิเคชันที่ระบุเป็นเพียงสคริปต์ที่แยกกระบวนการจริงจากนั้นส่งคืนโดยไม่ทราบว่าเกิดอะไรขึ้นกับกระบวนการ การทำให้มันทำงานในกรณีนี้คือความเจ็บปวด
jeteon

ระบบจะรีบูทและเริ่มบริการอะไรบ้าง มีวิธีใดบ้างในการระบุการหน่วงเวลาเริ่มต้นเป็นวินาทีสำหรับการตรวจสอบแต่ละครั้ง? นอกจากนี้การตรวจสอบโดยไม่ต้องใช้คำสั่งเริ่มต้น / หยุด
Massimo

START DELAYผมเชื่อว่าในกรณีที่คุณอาจจะมองหา
jeteon
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.