הגדרת צינור איסוף לוגים: איסוף, אחסון, ויזואליזציה

למה איסוף לוגים נשבר ככל שהעומס גדל

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

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

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

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

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

האפקט המדיד של מערכת איסוף אירועים אחודה

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

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

חיפוש רוחבי בכל השירותים

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

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

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

קיצור זמן חקירת התקלה

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

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

אפשרויות איסוף לוגים: סוכן, תור, זרימה

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

מתי איסוף ישיר מספיק

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

מתי נדרשים אגירה ושליחה חוזרת

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

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

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

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

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

מה מבררים בביקורת

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

קונפיגורציות, תרשימי זרימות ונהלי תורנויות

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

קונפיגורציות ותרשימי זרימות

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

נהלים והוראות לתורנים

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

מקרה בוחן: כיצד ארגון מחדש של האיסוף קיצר את חקירת התקלות

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

מה היה קודם: קבצים מפוזרים על הצמתים

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

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

מה נהיה: חיפוש אחוד ודקות במקום שעות

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

חיפוש אחר תקלה אורך 3–5 דקות במקום שעה, רשומות שאבדו — 0.2%, שלמות התמונה גדלה לכל השירותים, כולל משימות רקע ותורים. התראות שווא פחתו פי ארבעה: הכלל נבנה על קצב גידול השגיאות, לא על רשומה בודדת. חקירה ולוחות רצים מעל זרימה אחת ב-Grafana, בחירה אחת לא נאספת פעמיים.

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

מה לעשות אם אירועים כבר נאספים במקומות שונים?

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

הגירה חלקה של שירותים

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

מסירה כפולה לתקופת מעבר

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

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

שאלות טכניות ששואלים לפני ההתחלה

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

מה יקרה אם הקולטן אינו זמין?

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

האם ניתן להעביר שירותים בשלבים?

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

מה לעשות עם שדות רגישים ברשומות?

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

אילו זמנים ורמות אחסון נדרשים?

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

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

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

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

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