מאין מגיע גידול הדיסק של שרת VPN ואיך להגביל אותו

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

מצאו את המאגר שגדל ואת הקצב שבו גדל

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

df -h /var
df -i /var

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

journalctl --disk-usage

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

מה סבב עושה לקובץ פתוח

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

lsof +L1 | head

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

logrotate -d /etc/logrotate.conf

היכן התקרה שייכת, וכמה גדולה היא צריכה להיות

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

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

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

אמתו את התקרה לאחר אתחול

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

systemctl restart systemd-journald
journalctl --disk-usage

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

השוו את הקריאה הבאה לזו

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

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

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