הגדרת רוטציית לוגים ומדיניות שימור: מדריך DevOps

מדוע לוגים ממלאים את הדיסק: היכן נשברת רוטציית לוגים

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

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

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

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

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

מה נותנת רוטציה מנוהלת ואחסון לוגים

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

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

מה נראה במטריקות לאחר המעבר לסכימה מנוהלת:

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

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

השוואה בין גישות לרוטציית לוגים: גודל, זמן, שליחה

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

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

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

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

סדר היישום: מביקורת ועד מסירת הנהלים

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

1. ביקורת מקורות הלוג. מתעדים מי כותב לדיסק: נתיב, עוצמה, התנהגות בזמן קפיצות, מי מחזיק את הקובץ פתוח. בנפרד בוחנים קונטיינרים ויומן המערכת — להם לוגיקת שמירה משלהם.
2. סכימת רוטציה וחלונות שמירה. לכל קבוצה בוחרים סף לפי גודל או מרווח, מספר עותקים נשמרים ודחיסה. מפרידים בין מחלקות: ביקורת וגישות נשמרות זמן רב יותר, דיבאג — כמה יממות.
3. הגדרת כללים. תצורות בפורמט logrotate לפי קבוצות: דחיסת ארכיונים, פעולות לאחר רוטציה לפתיחה מחדש של מתאם הקובץ, העתקה עם קיצוץ במקומות שבהם התהליך לא מגיב לאות, הרשאות לספריות.
4. בדיקה תחת עומס. מריצים זרימה מעל השיא: הכלל פועל בסף, שורות לא הולכות לאיבוד במפגש בין קבצים, הדחיסה לא חוסמת כתיבה, עותקים ישנים באמת נמחקים.
5. נראות. התראות על מקום פנוי, גיל הקובץ האחרון ושגיאות רוטציה — אחרת את הכשל יבחינו דרך שירות לא זמין, ולא דרך מטריקה.
6. מסירת נהלים. מסמך ודיון עם משמרת התורנות: היכן נמצאים הלוגים, מה לעשות בהצפה, כיצד לפנות מקום בבטחה ולהחזיר את הכלל לאחור.

ארטיפקטים של היישום: תצורות, סכימות, נהלים

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

• תצורת רוטציה לכל מקור: תנאי הפעלה (לפי גודל או לוח שנה), מספר עותקים נשמרים, דחיסה, ארכוב מושהה ופעולה לאחר פתיחה מחדש של הקובץ על ידי התהליך.
• נוהל שמירה: טבלה «מחלקת לוג — תקופת שמירה חמה — תקופת ארכיון — מדיה — מי רשאי למחוק לפני המועד».
• מפת מקורות: רשימת שירותים וצמתים, מה נכתב לקובץ, מה עובר ליומן המערכת, היכן יש כפילות ומדוע.
• תיעוד לתורנים: מה לעשות כשהדיסק מתמלא, כשהרוטציה לא פעלה, כשצריך להעלות פירוט בדחיפות — עם פקודות מוכנות ופלט צפוי.
• הרשאות גישה ללוגים: מטריצת תפקידים — קריאה ישירה, גישה לפי בקשה, היכן מוסתרים נתונים אישיים, מי רשאי לשנות מועדים ותצורה.
• בדיקות והתראות: מופעלות אם הרוטציה לא עברה, הארכיון לא הועלה או המקום הפנוי נמוך מהסף, — עם שיוך לתורן מסוים.
• הוראות החזרה לאחור: כיצד להחזיר את התצורה הקודמת ולהעלות עותקים שנמחקו מהארכיון, כל עוד תקופת השמירה לא פגה.
• מדידות לפני ואחרי: נפח הלוגים בדיסק, חלק הצומת שהם תופסים, מספר תקלות בגלל הצפה — בסיס להשוואה לאחר שינויים.

מקרה בוחן: הפסיקו לאבד לוגים בעומס שיא

השירות כתב לוגים לקבצים בכל צומת, והרוטציה הוגדרה בשורה אחת: 100 MB, לשמור הכול. בשיא היישום המשיך לכתוב לקובץ שכבר עבר רוטציה, וחלק מהרשומות נעלם — 'חורים' הופיעו בדיוק בדקות שבהן חקירת התקלה הייתה נחוצה ביותר. חיפוש האירוע הנדרש ארך 20–30 דקות: המהנדס עבר שמונה צמתים וחיפש בארכיונים ידנית.

מה שינו

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

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

מטריקות לפני ואחרי

שיעור הרשומות שאבדו בשיא ירד מ-3–7% לאפס — השווינו מוני היישום עם מספר השורות באחסון. חיפוש אירוע אחד הצטמצם מ-20–30 דקות ל-10–20 שניות לפי אינדקס, בלי מעבר על צמתים ופירוק ארכיונים ידני.

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

במה שונה רוטציה לפי גודל מרוטציה לפי זמן?

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

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

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

שאלות טכניות נפוצות על רוטציה ואחסון לוגים

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

מועדים, שלמות וחקירת תקלות

האם אפשר לבצע רוטציה בלי הפעלה מחדש של השירות?

כן. אם התהליך יודע לפתוח מחדש את מתאם הקובץ לפי אות — הרוטציה מתבצעת בלי קטיעת חיבורים, הקובץ מחליף שם, והכתיבה ממשיכה לקובץ החדש.

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

כיצד לוודא שהמדיניות באמת מיושמת?

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

מה נותן ביקורת לוגים וכיצד לשמור ארכיון?

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

נדון במשימה ונחזור עם תוכנית רוטציית לוגים

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

מהשיחה הזו נבנית תוכנית ליישום מדיניות — לפי קווי המתאר שלכם, ולא לפי תבנית:

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

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