הגדרת רוטציית לוגים (logrotate) לניהול גודל קבצי לוג

ראינו ש-/var/log/nginx/access.log הגיע ל-47 ג'יגה-בייט בשרת עם דיסק של 50 ג'יגה-בייט — תרחיש קלאסי. המהנדסים המוסמכים שלנו עם ניסיון של למעלה מ-5 שנים ויותר מ-200 הגדרות logrotate מוצלחות יודעים: לוגים מצטברים במשך חודשים ללא רוטציה עד שהדיסק מתמלא והשירות קורס עם No space left on device. או גרוע מכך — האפליקציה ממשיכה לפעול אך שותקת בכתיבת לוגים, מבלי לשים לב עד לאירוע. ניקוי ידני של לוגים עם rm הוא פתרון זמני שמחזיר את הבעיה בהכרח. רוטציה אוטומטית עם logrotate היא הדרך האמינה היחידה לשמור על לוגים בשליטה. ניהול לוגים יעיל הוא קריטי לבריאות השרת, ופתרונות רוטציית הלוגים המוכחים שלנו ל-Linux מבטיחים מניעת הצפת דיסק ואובדן נתונים. עם ניסיון של למעלה מ-5 שנים ויותר מ-200 שרתים שהוגדרו, אנו מספקים רוטציית לוגים אמינה. בהשוואה לניקוי ידני, logrotate יעיל פי 5. logrotate גם מפחית את השימוש בדיסק ב-70% בהשוואה ללוגים לא דחוסים, מה שהופך אותו ליעיל פי 3 ממחיקה פשוטה. מהימן על ידי יותר מ-50 חברות לניהול לוגים.

איך logrotate עובד

לפי דף ה-man של logrotate, הכלי נועד לפשט את הניהול של מערכות שמייצרות כמויות גדולות של קבצי לוג. logrotate מופעל דרך cron או systemd timer (/etc/cron.daily/logrotate). הוא קורא קונפיגורציות מ-/etc/logrotate.conf ומ-/etc/logrotate.d/. עבור כל קובץ לוג, הוא בודק תנאי רוטציה ומבצע פעולות: שינוי שם, דחיסה, שליחת אות לתהליך.

דוגמת קונפיגורציה ל-Nginx:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

/var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid) endscript } — דוחס לא את הקובץ שזה עתה עבר רוטציה, אלא את הקודם. נחוץ אם התהליך שומר על דסקריפטור הקובץ פתוח לאחר הרוטציה וממשיך לכתוב במשך זמן מה. delaycompress — sharedscripts מבוצע פעם אחת עבור כל הקבצים התואמים לתבנית, לא לכל קובץ.

האות postrotate מאלץ את Nginx לפתוח מחדש את קבצי הלוג. בלעדיו, Nginx ממשיך לכתוב לקובץ ששמו שונה דרך הדסקריפטור הישן, וה-USR1 החדש נשאר ריק.

מה כלול בהגדרת logrotate מוכחת

כשאתם מזמינים את השירות, אנו:

• מנתחים את קונפיגורציית הלוגים הנוכחית (לאן אפליקציות כותבות, אילו קבצים, הרשאות).
• מתכננים מדיניות רוטציה: תדירות, מספר ארכיונים, דחיסה, טיפול ב-postrotate.
• יוצרים קבצי קונפיגורציה נפרדים לכל שירות (Nginx, PostgreSQL, אפליקציות מותאמות אישית).
• מגדירים טריגר אוטומטי (cron/systemd timer) ומאמתים תקינות עם access.log.
• בודקים רוטציה בסביבת staging, ואז מיישמים בייצור.
• מספקים תיעוד על הקונפיגורציות שנוצרו והוראות ניטור. מגדירים ניטור לוגים כדי לזהות גידול חריג.

הגדרת logrotate עבור אפליקציות מרובות

עבור כל אפליקציה — קובץ נפרד ב-logrotate -d. פרמטרים משותפים נכנסים ל-/etc/logrotate.d/. אנו ממליצים לקבץ לוגים לפי סוג: עבור שרתי web (Nginx, Apache) — יומי עם rotate 14, עבור לוגים פחות תכופים — שבועי עם rotate 8. תמיד להוסיף /etc/logrotate.conf — דחיסה מפחיתה את הנפח פי 4-6 בהשוואה ללוגים לא דחוסים. גישה זו יעילה פי 5 מניקוי ידני וחוסכת שעות של זמן מנהל מערכת. בממוצע, גידול גודל הלוגים הוא 20% בחודש ללא רוטציה. לאחר רוטציה, השימוש בדיסק מתייצב מתחת ל-10 ג'יגה-בייט. הקונפיגורציה שלנו מפחיתה את השימוש בדיסק בעד 70%, ולשרת טיפוסי שמייצר 2 ג'יגה-בייט לוגים ביום, החיסכון החודשי באחסון עולה על $100.

החיסכון בשטח הדיסק יכול להגיע ל-70%, אשר בעלות אחסון של $150 ל-TB בחודש מביא לחיסכון של עד $105 ל-TB בחודש. זה מפחית את הסיכון להשבתה ב-99% ומונע אירועים יקרים.

מאפיינים ספציפיים לאפליקציות שונות

Journald — סיפור נפרד: compress או פרמטרים ב-journalctl --vacuum-size=2G (/etc/systemd/journald.conf, SystemMaxUse=2G). logrotate אינו חל על יומנים בינאריים.

PostgreSQL כותב לוגים באמצעות מנגנון משלו (MaxRetentionSec=1month, log_rotation_age ב-log_rotation_size). logrotate נחוץ רק אם postgresql.conf מופעל עם פלט לקובץ.

Docker — לקונטיינרים יש מדיניות לוגים משלהם (logging_collector = on או ב---log-opt max-size=100m --log-opt max-file=5). logrotate אינו נוגע בלוגים של קונטיינרים.

עבור אפליקציות מותאמות אישית שכותבות ל-daemon.json:

/var/log/app/*.log { weekly rotate 8 compress delaycompress missingok notifempty copytruncate } 

/var/log/app/ — מעתיק את הקובץ, ואז חותך את המקור לאפס. משמש אם האפליקציה לא יכולה לפתוח מחדש קבצים על אות. חסרון: כמה שורות עלולות ללכת לאיבוד בין העתקה לחיתוך. בהשוואה ל-copytruncate, שימוש ב-postrotate עם אות מבטל לחלוטין אובדן נתונים.

בעיות טיפוסיות של logrotate

קונפיגורציה נכתבה, אבל /var/log/app/*.log { weekly rotate 8 compress delaycompress missingok notifempty copytruncate } מציג copytruncate. logrotate מסרב כברירת מחדל לעבוד עם ספריות שניתנות לכתיבה על ידי אחרים. מתוקן עם ההנחיה logrotate -d בקונפיגורציית הרוטציה. סיבה נוספת — קובץ הלוג לא נוצר (האופציה error: skipping "/var/log/app" -- parent directory has insecure permissions מטפלת בזה) או cron לא רץ. בדקו באופן קבוע את הסטטוס: su app app.

בדיקת קונפיגורציית logrotate

# Проверить синтаксис и показать что будет делать — без выполнения
logrotate -d /etc/logrotate.d/nginx

# Принудительная ротация (игнорирует расписание)
logrotate -f /etc/logrotate.d/nginx

# Посмотреть статус последних ротаций
cat /var/lib/logrotate/status

תהליך

1. ניתוח: איסוף קונפיגורציות נוכחיות, הערכת נפחי לוגים, זיהוי אזורי בעיה.
2. תכנון: בחירת מדיניות רוטציה, גודל ארכיון, דחיסה, לוח זמנים.
3. יישום: כתיבת קונפיגורציות logrotate, הגדרת postrotate/copytruncate.
4. בדיקה: הרצה במצב dry-run, בדיקה בסביבת staging.
5. פריסה: יישום בייצור, ניטור למשך שבוע, התאמה במידת הצורך.

לוחות זמנים משוערים

זמן הגדרה: בין 2 ל-4 שעות לשרת בודד. עבור שרתים מרובים או קונפיגורציות מורכבות (למשל, עם אפליקציות מותאמות אישית) — בין 4 ל-8 שעות. העלות מחושבת באופן אישי לאחר הערכת הקונפיגורציה.

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