לוגים מרכזיים: היכן נשבר איסוף הלוגים המפוזר
כל עוד היומנים נכתבים מקומית על כל מכונה, אין למערכת תמונה אחודה. השירות כותב ל-journald, האפליקציה — לקובץ בתוך הווליום, מאזן העומסים — ליומן משלו; לכל אחד פורמט משלו, רמת פירוט משלו ומועד רוטציה משלו. בעת תקלה המהנדס מקבל לא נתונים לחקירה, אלא רשימת שרתים ומשימה למצוא את הסיבה ידנית.
מעבר על כל הצמתים הוא החלק היקר ביותר. צריך להיכנס לכל אחד בתורו, להיזכר בנתיב אל היומן, לחלץ קטע ולהשוות חתימות זמן — אך השעונים במכונות שונים זה מזה, ואירועים של אותה בקשה מתגלים בקבצים שונים עם היסט. תקלה הפרושה על פני כמה שירותים נאלצים להרכיב חלקים-חלקים, תוך איבוד שעות.
חלק מהרשומות נעלם פיזית. יומני הקונטיינר חיים בשכבה שנמחקת יחד עם הקונטיינר: ריסטארט — וההקשר של הנפילה אבד. אם האפליקציה נופלת במחזוריות, הקובץ נכתב מחדש באותן הודעות עצמן, ודוחק את מה שהיה לפני התקלה. אובדן לוגים בריסטארט מאפס את החקירה בדיוק ברגע שבו הנתונים נחוצים ביותר.
הצד השני — הצפת הדיסק שעליו יושבים היומנים. ללא הגבלות על גודל ותקופת שמירה, הלוגים אוכלים את המחיצה, ואז השירות שכותב אותם עצמו מדרדר או נופל. ניקוי חירום לפי לוח זמנים או רוטציה אגרסיבית מדי נותנים אפקט הפוך: עד רגע החקירה הרשומות הנחוצות כבר נמחקו.
נבחן כיצד זה נסגר באמצעות לוגים מרכזיים: נקודת איסוף אחת, חתימות זמן אחידות, שמירה לפי מדיניות וחיפוש בכל השירותים בבת אחת, ולא אחד-אחד.
מה נותנת נקודת איסוף וחיפוש אחת על פני כל השירותים
כאשר כל שירות כותב יומנים לקובץ משלו על הצומת שלו, את סיבת התקלה מחפשים בכוח גס: להתחבר למכונה הנכונה, לנחש את הטווח הזמני, להשוות ידנית חתימות זמן.
נקודת איסוף לוגים אחת על Grafana Loki מבטלת את השלב הזה — רשומות מכל השירותים נכנסות למאגר אחד עם תגיות משותפות של שירות, סביבה וגרסת בילד.
חיפוש רוחבי בכל היומנים במקום מעבר על צמתים
החיפוש מתבצע לפי מזהה הבקשה שהשירותים מסמנים בכל שורה. המהנדס רואה את כל השרשרת — מהשער החיצוני ועד התור והמסד — בחלון אחד, בלי לתאם הרשאות גישה למכונות של אחרים. זמן חקירת אירוע בתקלה טיפוסית יורד משעות לדקות, וזה האפקט הראשון שמבחינה בו המשמרת התורנית.
שלמות התמונה לכל אורך שרשרת הבקשה
תגיות לפי שירות, סביבה וגרסת בילד מאפשרות להשוות את ההתנהגות של סביבת הבדיקות וסביבת הפרודקשן ולראות באיזה שלב אבדה ההודעה. מחלקה שלמה של תקלות — פערים בין שירותים, בקשות קטועות, שגיאות "שקטות" — התגלתה בעבר רק מתלונת משתמש; כעת היא נראית בזרם כאנומליה.
תקופת שמירת היומנים ונראות השירותים
מדיניות השמירה קובעת את תוחלת החיים של הרשומות: רשומות טריות נשמרות חמות לחקירת תקלות שוטפות, ותיקות עוברות לאחסון קר — הנפח לא גדל ללא בקרה, וההיסטוריה נשארת נגישה לניתוח בעיות חוזרות. נראות השירותים מפסיקה להיות תלויה בשאלה מי ומתי הציץ בצומת מסוים.
דרכי העברת הלוגים: סוכן, קולט, שער שירות
אפשר לאסוף רשומות מהמכונות והאפליקציות בכמה דרכים, ואת הבחירה מכתיבה לא הנוחות אלא מה שכבר קיים בסביבה. השירות כותב לקובץ — אין צורך לשנות קוד, הסוכן קורא את הזרם במקום. צריך שדות קפדניים ותיוג בקשה — יהיה צורך לשנות את האפליקציה עצמה. להלן הווריאנטים הממשיים והמגבלות שלהם, כדי שאלה לא יצופו כבר תוך כדי ההטמעה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן על הצומת — איסוף לוגים באמצעות סוכן | היומנים נכתבים לקובץ או ליומן המערכת, אין אפשרות לשנות קוד | תקורה של איסוף על כל צומת; בלי דיסק חוצץ מאבד את הזנב כשהקולט אינו זמין |
| קולט יומנים ברשת | התקני רשת ושירותים ישנים שיודעים רק לשלוח דרך הרשת | אין אישור מסירה בעת ניתוק הערוץ, המבנה מצומצם לשורה אחת |
| שער שירות לצד האפליקציה | קונטיינרים, הרבה תהליכים קצרי-חיים, פלט לזרם | מסבך את הפריסה, לשער יש מחזור חיים ועדכונים משלו |
| מסירה ישירה מהאפליקציה | נדרשים שדות מדויקים, תיוג בקשה, קישור לטראסינג | דורש פיתוח באפליקציה והצמדה לספרייה; כשל בערוץ מפיל את החוצץ בזיכרון |
חציצה היא שאלה משותפת לכל הדרכים. הסוכן והשער כותבים את המצטבר לדיסק ומשלימים את השליחה כשהקולט זמין שוב, בעוד שליחה ישירות מהקוד מחזיקה תור בזיכרון התהליך ומאבדת אותו יחד איתו. מכאן הסכימה העובדת — משולבת: סוכן כבסיס, ושער במקומות שבהם התהליכים קצרי-חיים.
סדר ההטמעה: ממיפוי המקורות ועד למסירה
את שלבי הטמעת הלוגים בונים כך שלאחר המסירה המערכת תמשיך לחיות בלעדינו. אנחנו מתחילים לא בהתקנה אלא במיפוי מקורות הלוגים: כל עוד לא ידוע כמה שירותים כותבים, באיזה פורמט ובאיזו עוצמה, כל קונפיגורציה היא ניחוש.
- מיפוי מקורות הלוגים — עוברים על השירותים, הצמתים והאפליקציות, ורושמים את פורמט הרשומות, הנפח היומי והבעלים. לפי הטבלה הזו מחשבים את העומס על המאגר ואת תקופת השמירה.
- סכימת זרמי היומנים — היכן עומד האוסף, כיצד הרשומות מגיעות למאגר, ואילו תגיות (שירות, סביבה, רמה) משתמשים בהן. את התגיות בוחרים כך שהקרדינליות תישאר צפויה.
- פריסה — Loki ו-Grafana, שכבה חמה על דיסקים ואחסון ארוך-טווח באחסון אובייקטים. כלל ה-Lifecycle מחזיק את הימים האחרונים בגישה מהירה, ואת השאר מעביר לשכבה הקרה.
- גישה והפרדה — תפקידים ב-Grafana ומקורות נתונים נפרדים לפי צוותים: מפתח רואה את השירותים שלו ואינו קורא של אחרים.
- בדיקה בעומס אמיתי — משחזרים את זרם השיא, מודדים את ההשהיה מרגע הכתיבה ועד להופעה בחיפוש, ובוחנים את ההתנהגות בכשל של האוסף ובהצפת דיסק.
- התראות ודשבורדים — כללים ב-LogQL לשגיאות ולזינוקים, וניתוב ההתראות לתורן.
- מסירת התשתית ללקוח — קונפיגורציה במאגר הקוד, נהלי תפעול, והדרכת הצוות על סביבה חיה.
מה נשאר אצלכם לאחר המסירה: קונפיגורציות ונהלים
הפרויקט לא מסתיים בהדגמת דשבורדים: בסיומו אתם מקבלים סט ארטיפקטים שלפיהם המערכת חיה ומתפתחת בלי מעורבות שלנו. הכול נמצא במאגר הקוד שלכם, מנוהל בגרסאות ועובר רוויו כמו קוד רגיל — שינוי בכלל איסוף או בסף נראה בהיסטוריית השינויים.
- קונפיגורציות של אוספי הלוגים. קבצי הסוכנים לכל צומת ושירות: מקורות הרשומות, כללי פירוק, תגיות סביבה וצוות, ותקופות שמירה לכל זרם.
- סכימת זרמי הרשומות. המסלול מהאפליקציה ועד המאגר וממשק החיפוש, כולל ההתנהגות כשהמאגר אינו זמין — חציצה בדיסק וסדר השלמת השליחה.
- מדיניות גישה ליומנים. תפקידים והפרדה לפי צוותים וסביבות, מיסוך שדות רגישים לפני הכתיבה, והרשאות נפרדות לקריאת סביבת הפרודקשן.
- תיאור הספים וכללי ההתראה. מה נחשב לאירוע, על איזה חלון ותדירות זה מופעל, לאן הולכת ההתראה וכיצד מכבים את הכלל במקרה של התראות שווא.
- תיעוד החיפוש. תזכורת לשאילתות טיפוסיות — לפי מזהה בקשה, שירות, חלון זמן — וניתוח של שניים-שלושה אירועים אמיתיים עם הסיבה שנמצאה.
- נוהל תורנות. מי ומתי בוחן את הפאנלים, זמן התגובה, סדר האסקלציה, וסדר הפעולות כשמאגר היומנים אינו זמין.
- הוראות חיבור שירות חדש. תבנית קונפיגורציה ובדיקה שהרשומות הופיעו, התגיות סומנו, והזרם אינו משוכפל.
את כל הארטיפקטים מוסרים עם תיאור מלווה: היכן הם נמצאים, מי הבעלים, ומה משתנה כשמוסיפים שירות.
מקרה בוחן: כיצד קיצרנו את חקירת האירוע משעות לדקות
לפני הפרויקט היומנים חיו בארבעה מקומות: קבצים על שרתי האפליקציות, זרם הקונטיינרים, הפאנל של מאזן העומסים וטבלאות המסד. המהנדס פתח ארבעה ממשקים והשווה רשומות לפי זמן ידנית — חיפוש סיבת התקלה נמשך בין שעתיים לחמש שעות, וחלק מהתקלות לא הותירו אחריהן דבר מלבד תלונת לקוח.
פרסנו את Grafana Loki כמאגר יומנים אחיד. האוסף על כל צומת מסמן לרשומות תגיות של שירות, סביבה וגרסת בילד — לפיהן מתבצע החיפוש, ולכן אין צורך לזכור מה נמצא על איזו מכונה. נתונים חמים חיים חודש, ואחר כך נשלחים לאחסון קר: המרשם לא גדל ללא בקרה, והחקירה של פניות ישנות נשארת אפשרית.
מה השתנה בעבודה עם אירוע
חיבור המקורות התנהל בגלים: תחילה שירותים קריטיים, אחר כך משימות רקע והשכבה הרשתית. בסך הכול 47 מקורות בשלושה שבועות, כולל כאלה שלא תועדו ביומנים כלל קודם לכן. שאילתה על לקוח מסוים מחזירה שרשרת רשומות מכל הצמתים בתוך שניות, בלי השוואה ידנית לפי זמן.
זמן איתור סיבת התקלה הצטמצם משעות ל-10–15 דקות — בממוצע פי 12 לפי האירועים שתועדו. בנפרד סגרנו מחלקה של תקלות שנודעו בעבר רק מהמשתמשים: חוסר סנכרון עם מערכות חיצוניות וכשלים במשימות רקע. כעת מופעלת עליהן התראה, והתורן רואה את הבעיה לפני שהלקוח מבחין בה.
במה נבדלים לוגים מרכזיים מאיסוף לוגים
איסוף לוגים הוא תובלה: הסוכן קורא קבצים, חוצץ אותם ומוסר אותם לצומת משותף. הקבצים מתגלים זה לצד זה, אבל זה לא הופך לכלי — המעבר על המארחים והחיפוש הידני נשארים. לוגים מרכזיים מתחילים במקום שבו לאיסוף מתווספים אינדקס אחיד, הפרדת הרשאות ותקופת שמירה מבוקרת.
חיפוש אחיד מחליף את המעבר על המכונות: השאילתה מתבצעת לפי תגיות של שירות, סביבה וגרסה, והתוצאה מרוכזת לפיד אחד עם הקשר לפני ואחרי האירוע. מופיעה קורלציה — לפי מזהה הבקשה רואים באיזה שירות הוא הידרדר, בלי לעבור בין טרמינלים לארכיונים פרוקים.
תפקידים ותקופות שמירה — הגבול השני. גישה ללוגים של סביבת התשלומים לא ניתנת יחד עם גישה לסביבת הפיתוח, והתקופה נקבעת במדיניות: האינדקס החם מחזיק את הימים האחרונים לחקירת תקלות, והארכיון — זמן ארוך יותר, לחקירות ולדרישות הרגולטורים.
| קריטריון | קבצים במקום אחד | לוגים מרכזיים |
|---|---|---|
| חיפוש | מעבר ידני על מארחים | שאילתה לפי תגיות, תוצאה אחת |
| גישה | גישה משותפת לשרת | תפקידים לפי מקורות וסביבות |
| שמירה | גדל כל עוד יש מקום בדיסק | מדיניות לפי מקור ותקופה |
| מבנה | טקסט לא מפורק | שדות, תגיות, מזהה בקשה |
בפרקטיקה שלנו זה נראה כך: Grafana Loki קולט את הזרם, התגיות יוצרות את האינדקס, והפאנלים וההתראות נבנים מעל אותו מקור — חקירת התקלה מתנהלת בממשק אחד במקום התכתבות של "שלח לי את הקובץ שלך".
ספקות טכניים: נפחים, שמירה, הרשאות
לפני ההתחלה דנים לא ב"למה", אלא בפרטים קונקרטיים: כיצד המערכת תתנהג כשנפח הרשומות יגדל פי שניים, מה יקרה כשהקולט אינו זמין ומי יקבל גישה ליומנים של אחרים.
חיבור אפליקציות מוכנות אינו דורש שינויים בקוד: אם השירות כותב ליציאה הסטנדרטית או לקובץ, מספיק להגדיר את סוכן האיסוף ואת התגיות. להלן השאלות הנפוצות ביותר.
כמה מהר גדל נפח הרשומות ומה מגביל אותו?
הנפח גדל יחד עם מספר השירותים והתעבורה. אנחנו מגבילים בכניסה: משליכים רעש — בדיקות חיות, שגיאות חוזרות — וקובעים מכסות לאפליקציה ודילול בחריגה. הגידול הופך לצפוי, ולא ל"עד שהדיסק ייגמר".
מה יקרה אם הקולט אינו זמין?
הסוכן חוצץ את הרשומות על הדיסק המקומי ושולח אותן לאחר חידוש הקשר. החוצץ מוגבל: בהצפה הולכות לאיבוד הרשומות הוותיקות ביותר, אך האפליקציה עצמה ממשיכה לעבוד ואינה נחסמת.
כיצד מופרדת הגישה לרשומות?
מפרידים לפי תגיות ומרחבים: צוות רואה רק את השירותים שלו. תפקידים לקריאה ולשינוי כללים ניתנים בנפרד, והגישה ליומנים של צוותים שכנים סגורה כברירת מחדל.
כמה זמן נשמרות הרשומות וכיצד הן נמחקות?
את התקופה קובעים במדיניות לפי מחלקות: רשומות טריות נשמרות באחסון מהיר לחקירת אירועים, אחר כך עוברות לדחוס ונמחקות לפי לוח זמנים. המאגר לא גדל עד אין סוף.
נדון במשימה: מה להכין לשיחה הראשונה
כדי לדון בהטמעת הלוגים באופן ענייני ולא בסיסמאות, די בנתוני פתיחה על התשתית שלכם — אין צורך להכין דבר מראש. פאנלים, אוספים ומאגר יומנים אנחנו פורסים בעצמנו; מכם נדרש ההקשר שלפיו מחשבים את הנפח.
לאחר השיחה נחזור עם אומדן ותוכנית עבודה: שלבים, מה אנחנו סוגרים בצד שלנו, והיכן נדרשת גישה של המנהלים שלכם.
- רשימת שירותים וסביבות: אילו אפליקציות, מסדים, תורים ופרוקסים כותבים יומנים, ואילו סביבות מופרדות — פיתוח, בדיקות, פרודקשן. מזה תלוי מספר המקורות וכיצד לפרוס את הרשומות לפי תגיות.
- היכן הרשומות נמצאות כיום: קבצים על שרתים עם רוטציה, יומני קונטיינרים, פלט מערכת ההפעלה. חשוב להבין מה כבר נאסף ומה הולך לאיבוד בריסטארט.
- תרחישי חיפוש ביומנים: חקירת אירוע לפי מזהה בקשה, שגיאות של שירות מסוים, פניות תמיכה. השאלות הממשיות קובעות את סכימת התגיות, תקופת השמירה וסט הפאנלים.
- נפח: זרם רשומות משוער ליממה ועומק השמירה הנדרש לחקירת אירועים ולדרישות ביקורת.
- דרישות גישה: מי מהצוותים צריך לראות מה, האם נדרשת ייצוא למערכות חיצוניות, והאם יש מגבלות על נתונים אישיים ברשומות.
- מגבלות האתר: מקטעי רשת בלי יציאה החוצה, מגבלות על דיסקים וערוצים, וסדר אישור שינויים.
יספיק גם חצי מהרשימה — את השאר נברר בשיחה. ככל שרשימת השירותים ותרחישי החיפוש קונקרטיים יותר, כך האומדן מדויק יותר והתיקונים בשלב ההטמעה מועטים יותר.