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

והשורה על ה-inodes דרושה בנפרד: הם נגמרים בנפרד מהמקום, ובלעדיה המצב הזה עובר בלי שיבחינו בו.

בדיקת ההגדרות

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

monit -t בודק את התחביר לפני שהוא מוחל. ו-monit summary נותן טבלה קצרה של מצבים — המקום שממנו מתחילים לבדוק כל בעיה.

ובדקו שהדואר נשלח. Monit מדווח על אירועים במכתב, ואם המסירה אינה מוגדרת לא תהיה שום התראה: השירות יופעל מחדש ואתם לא תדעו על כך — בעוד הפעלות חוזרות הן בדיוק האות המרכזי. והן נראות גם ביומן: /var/log/monit.log.

מה Monit אינו עושה

הוא אינו מסלק את הסיבה. הפעלה מחדש היא דחייה, ושירות שמופעל מחדש כל הזמן פירושו שאיפשהו חסר זיכרון, או שהמקום נגמר, או שהאפליקציה דולפת. וערכו של הכלי אינו בהפעלה מחדש אלא במונה: שלוש הפעלות מחדש של nginx ביממה הן אבחנה שאחרת הייתה עוברת בלי שיבחינו בה, כי האתר עבד כל הזמן.

לכן מה שצריך להביט בו אינו המצב הנוכחי — הוא כמעט תמיד ירוק — אלא ההיסטוריה: כמה פעמים בשבוע שעבר משהו קם מעצמו. איך זה נראה בעמוד אחד מראה ההדגמה למטה.