Graylog: מדוע לוגים הולכים לאיבוד בין שרתים
לוגים מפוזרים על פני עשרות מכונות: האפליקציה כותבת ל-journald, מאזן העומסים — לקובץ משלו, מסד הנתונים — למאגר פנימי, וחלק מהשירותים בכלל עוברים לקונטיינרים שחיים דקות ספורות.
כשבחצות נופל תשלום, המהנדס פותח הפעלות SSH לכל הצמתים, מחפש ב-rotation ובכל זאת אינו רואה את התמונה המלאה — עד לרגע הניתוח הקבצים הישנים ביותר כבר נדרסו.
המחיר של מבנה כזה הוא לא רק שעות של חיפוש. אירוע שלא עזב את המארח נעלם יחד איתו: הפעלה מחדש של pod, autoscaling, נפילת צומת — וההקשר של התקלה אבד ללא אפשרות שחזור. גרוע מכך, כשיש לוגים, אבל לכל שרת יש זמן משלו ופורמט משלו, ואי אפשר לתפור אותם לכרונולוגיה אחת באופן ידני.
לוגינג מרוכז דרך Graylog סוגר את זה ברמת האיסוף: סוכן על כל מכונה לוקח אירועים מקבצים, מיומנים וזרמי קונטיינרים ושולח אותם ברשת לנקודת אחסון אחת. משם פועלת החלק הצד-שרתי — מקבל את הזרם, מפרק אותו לשדות לפי תבניות, מפזר לאינדקסים ושומר בדיוק כמה שצריך לניתוח תקלות ודרישות ביקורת.
העיקר כאן הוא לא "איסוף לשם איסוף", אלא מה שקורה אחר כך. נקודת אחסון אחת הופכת את החיפוש מסיור בין שרתים לשאילתה אחת: לפי שירות, רמה, מזהה בקשה או חלון זמן.
המהנדס רואה את כל השרשרת — מבקשה בכניסה ועד שגיאה במסד הנתונים — כרצף אירועים מתמשך, ולא כאוסף של פרגמנטים מנותקים.
בנפרד נפתרת שאלת האובדנים. מאגר בצד הסוכן שורד אי-זמינות של השרת, ובצד המקבל מוגדרות תורים וחוקי השלכה: תחת עומס הולך לאיבוד הרעש, ולא אירועים משמעותיים. זה בדיוק ההבדל בין "הלוגים קיימים איפשהו" לבין "אפשר לנתח תקלה לפי הלוגים".
מפרקים איך זה נסגר: מבחירת סכמת האיסוף וסימון השדות ועד למדיניות אחסון וגישה לנתונים.
מה נותן איסוף לוגים מרוכז
חיפוש בלוגים במקום מעבר על שרתים
כשלוגים נמצאים על עשרות מארחים, חקירת תקלה הופכת למעבר ידני: להתחבר לכל אחד, להיזכר בנתיב לקובץ, לעשות grep לפי זמן. אחסון מאוחד ב-Graylog מסיר את השלב הזה — שאילתה על כל המקורות בבת אחת, סינון לפי שירות, צומת וחלון זמן. מה שפעם לקח שעה של תיאום "אצל מי לבדוק" מצטמצם לשורת חיפוש אחת תוך שניות.
שלמות התמונה ופורמט אחיד
אפליקציות שונות כותבות בדרך שלהן: חלקן ב-JSON, חלקן בטקסט חופשי, חלקן בכלל שותקות לגבי שגיאות. אנחנו מנרמלים את הזרמים לפורמט משותף באמצעות מפרסרים ומחלצים שדות — רמה, שירות, מזהה בקשה.
כתוצאה מכך, אירוע המפוזר על פני כמה צמתים נאסף לשרשרת אחת, והסיבה לתקלה נראית במלואה, ולא כפragment.
פחות עבודה ידנית וחזרה לאחור צפויה
התראות מוגדרות מסירות את התורנות של "עיניים על הלוגים": כלל מופעל על אנומליה ושולח הקשר, ולא זרם גולמי. רוטציה ותקופת שמירה נקבעות במדיניות — המאגר לא גדל ללא שליטה, ובמקביל ההיסטוריה לתקופה הנדרשת נשארת זמינה לחקירה. המהנדסים משקיעים זמן בתיקון, ולא בחיפוש היכן מה נמצא.
מה זה משנה עבור הצוות
מהירות החיפוש, שלמות האירועים והפורמט האחיד יחד נותנים את העיקר — זמן צפוי עד למענה על השאלה "מה קרה". מפרקים כיצד זה נסגר בתשתית שלכם.
דרכי מסירת לוגים ל-Graylog
דרך המסירה קובעת מה בכלל תראו ב-Graylog. סוכן על המארח קורא קבצים וחוצצים של יישומים, יומן המערכת אוסף את כל מה שמערכת ההפעלה כותבת, ושליחה מתוך היישום מספקת אירוע מובנה עם שדות מוכנים. הבחירה משפיעה על שלמות התמונה, על העומס על המארחים ועל מהירות החיפוש בעת ניתוח תקרית.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן איסוף על המארח | פארק שרתים הטרוגני, לוגים בקבצים, נדרש איסוף ממאות מכונות | דורש התקנה ועדכון על כל מארח, נדרש פיקוח על חוצצים בעת ניתוק בתקשורת |
| איסוף דרך יומן המערכת | התחלה מהירה, אירועים תשתיתיים, פורמט אחיד ממערכת ההפעלה | הרבה טקסט לא מובנה, חלק מהשדות הולכים לאיבוד, קישור חלש לאירועים עסקיים |
| שליחה מתוך היישום | שירותים קריטיים שבהם חשובים הקשר הבקשה, מזהה המשתמש והמעקב | דורש התאמת קוד ופורמט אחיד לאירועים, אחרת השדות בשירותים שונים לא יתאימו |
| שליחה ישירה ברשת מתוך ספריית הלוגינג | קונטיינרים ומשימות קצרות-חיים שבהן הסוכן לא מספיק לעלות | אין חוצץ מקומי: כאשר היעד אינו זמין, האירועים הולכים לאיבוד ללא אפשרות שחזור |
בפועל משלבים בין האפשרויות: הסוכן מכסה את רמת המערכת ואת הקבצים, והיישום שולח אירועים עסקיים ישירות. אז מתכנסים ב-Graylog גם נתונים תשתיתיים וגם נתוני יישום, והחיפוש לפי תקרית מתבצע לפי מזהה בקשה אחד.
אנו מתייגים את המקורות כך שכל אירוע נושא את שם השירות, הסביבה והגרסה — בלי זה הניתוח הופך לסריקה ידנית.
בנפרד אנו מחליטים מה לעשות בעת ניתוק בתקשורת עם היעד: מגדירים חוצץ דיסקי ומגבילים את גודלו, כדי שהמארח לא יגיע למצב של הצפה. תארו את הפארק ואת השירותים הקריטיים שלכם — נחזור עם הערכה ותוכנית לפי סכמת המסירה.
כיצד אנו מיישמים לוגים מרכזיים
היישום מתחיל לא בהתקנת Graylog, אלא במיפוי של מה שכבר מייצר אירועים: אפליקציות, מאזני עומסים, מסדי נתונים, מתזמר וציוד רשת. בשלב זה אנו מתעדים פורמטים (plain text, JSON, GELF), נפחים יומיים ועוצמת שיא — מאלה תלויים טופולוגיית הכניסות וגודל האחסון. ללא מיפוי, חלק מהמקורות הולכים לאיבוד, וחורים בלוגים מתגלים רק בזמן חקירת תקלה.
- סקירת מקורות. אוספים רשימת מערכות, פורמטים ונפחי הודעות, קובעים היכן נדרש סוכן והיכן די בשליחה ברשת. בנפרד מסמנים מקורות עם פורמט לא תקני — עבורם מכינים כללי פענוח.
- תכנון סכימת הזרימות. מפזרים הודעות בין זרימות ואינדקסים: אפליקציה, אבטחה, תשתית. מגדירים כללי ניתוב ומדיניות שמירה — נתונים חמים נשמרים מהר, ארכיון עובר לאמצעי אחסון זול.
- הגדרת הקליטה. מקימים כניסות לפרוטוקולים הנדרשים, מגדירים חילוץ שדות, נרמול זמן והעשרה (שם שירות, סביבה, גרסה). זה מה שהופך טקסט גולמי לנתונים שעליהם נבנות שאילתות והתראות.
- בדיקת שלמות. מוודאים שהכול מגיע: משווים מונים במקור ובמערכת, תופסים הודעות שאבדו וכפילויות, בודקים התנהגות בעומס שיא ובניתוק תקשורת.
- התראות ודשבורדים. מגדירים כללים לאנומליות וספים, מרכיבים פאנלים לשירותים מרכזיים, כדי שהתורן יראה את התמונה ללא שאילתות ידניות.
- נהלים והרשאות. מפרידים הרשאות לפי צוותים, מתארים תקופות שמירה וסדר הוספת מקורות חדשים.
- מסירה לתפעול. מאמנים תורנים, מוסרים תיעוד ומעבירים את המערכת לליווי.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בדוח. תארו את התשתית שלכם — נחזור עם הערכה ותוכנית יישום.
מה הלקוח מקבל לידיו
אנו פורסים את Graylog כך שהמערכת תפעל בלעדינו: זרימות, אינדקסים, כללי ניתוח והרשאות מתוארים בקונפיגורציה, ולא "בראש של המהנדס". להלן — מה בדיוק נשאר לצוות שלכם לאחר המסירה.
- קונפיגורציות של כל הצמתים: נקודות כניסה לקליטת לוגים, שיוך זרימות לאינדקסים, פרמטרי אחסון ורוטציה, הגדרות שכפול — כקבצים תחת בקרת גרסאות, ולא כעריכות ידניות בממשק האינטרנטי.
- סכמת זרימות וניתוב: איזה מקור מגיע לאן, לפי אילו כללים הודעה עוברת לזרימה הנכונה, כיצד מוגדרים סדרי עדיפויות ומה קורה לאירועים שלא נותחו.
- כללי ניתוח וחילוץ שדות: מערכי כללים לכל סוג מקור — ניתוח תאריכים, רמות, מזהי בקשות, התאמה לסכמת שדות אחידה, כדי שחיפוש במערכות שונות יעבוד באופן זהה.
- דשבורדים והתראות: פאנלים מוכנים לפי שירותי מפתח וכללים שמופעלים על אנומליות — עלייה בשיעור השגיאות, היעלמות זרימת לוגים, זינוק בכשלים.
- נוהל תפעול: סדר הוספת מקור חדש, רוטציית אינדקסים, עדכון כללי ניתוח ושחזור לאחר תקלת צומת — שלב אחר שלב, עם אחראים.
- תיעוד: תרשים ארכיטקטורה, תיאור זרימות, מילון שדות והוראות למהנדס תורן — כדי שחקירת תקרית לא תתחיל בשאלה "איפה מחפשים את זה".
- הרשאות והפרדת זכויות: תפקידים לצוותים, תצוגות נפרדות לפי השירותים שלהם, ביקורת פעולות במערכת.
כל ארטיפקט נמסר במצב עובד ונבדק בתשתית שלכם. תארו את המשימה — נחזור עם הערכה ותוכנית.
מקרה בוחן: כיצד קוצר זמן ניתוח האירועים
מה היה לפני ההטמעה
אלינו הגיע לקוח עם תמונה קלאסית: שלושה מתחמים — פרודקשן, קדם-פרודקשן ושירותים פנימיים — ולכל אחד דרך משלו לצפות בלוגים. חלק מהאפליקציות כתבו לקבצים בדיסקים מקומיים, חלק העבירו זרם ל-journald, וחלק — ל-stdout של הקונטיינרים.
בעת ניתוח אירוע, המהנדס התורן בירר תחילה באיזה צומת חי השירות הבעייתי, אחר כך ניגש לאותו צומת, ואז נזכר באיזה פורמט נכתבים שם האירועים.
ניתוח ממוצע של אירוע אחד ארך 40-60 דקות, וחלק גדול מזמן זה הוקדש לא לניתוח אלא לאיסוף הנתונים. גרוע מכך: עם הפעלה מחדש של הקונטיינר, הלוגים נעלמו יחד איתו, ואת תמונת התקלה ניתן היה לשחזר רק לפי סימנים עקיפים.
פורמטים שונים של זמן בשירותים שונים הוסיפו בלבול — התאמת אירועים משתי מערכות לפי זמן הייתה משימה בפני עצמה.
מה שינו
פרסו Graylog כנקודת איסוף אחודה: סוכני sidecar על הצמתים, GELF בכניסה, אינדקס אחד לכל מתחם. העיקר — לא האיסוף עצמו, אלא הבאת האירועים לסכמה משותפת: שדות חובה של שירות, סביבה ומזהה בקשה, פורמט זמן אחיד. לאחר מכן הגדירו חילוץ שדות מהודעות לא מובנות וזרמים (streams) עם כללי שמירה נפרדים לכל מתחם.
בנפרד נסגרה סוגיית הגישה: התורן רואה רק את הזרמים שלו, המפתח — את השירות שלו בכל הסביבות. הריטנציה מוגדרת כך שנתונים חמים חיים באינדקס מהיר, וכל מה שמעבר לכך עובר לארכיון — ובמקביל החיפוש בארכיון נשאר זמין מאותו ממשק.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| זמן ניתוח ממוצע של אירוע | 40-60 דק' | 8-12 דק' |
| שיעור האירועים שנותחו ללא גיוס מהנדס נוסף | ~30% | ~80% |
| שחזור התמונה לאחר הפעלה מחדש של השירות | בלתי אפשרי | היסטוריה מלאה |
| חיפוש לפי אירועים בחודש | מעבר ידני בין צמתים | שאילתה אחת |
הרווח העיקרי לא הגיע מאיסוף הלוגים כשלעצמו, אלא מסכמת השדות האחודה: חיפוש לפי מזהה בקשה מציג מיד את כל השרשרת — ממאזן העומסים ועד למסד הנתונים. המהנדס הפסיק להיות שליח בין מערכות ועסק באבחון עצמו.
במה שונה Graylog מאיסוף לוגים על כל שרת?
באחסון מקומי כל שרת מנהל יומן משלו, וזה עובד בדיוק עד לניתוח התקרית הראשון. תקלה פגעה בשלושה צמתים — אתם פותחים שלוש קונסולות, משווים ידנית חתימות זמן, וחלק מהיומנים כבר נדרסו על ידי רוטציה או אבדו יחד עם הדיסק של המכונה שקרסה. ככל שגדל המלאי, כך יקר יותר כל ניתוח כזה: זמן המהנדסים מושקע באיסוף נתונים ולא בטיפול בגורם השורש.
אחסון מרוכז משנה את הסכימה עצמה: סוכנים על השרתים שולחים זרם אירועים לאחסון משותף, שבו הרשומות מאונדקסות ומתנהלות לפי כללים אחידים.
Graylog מקבל אירועים בפרוטוקולי איסוף תקניים, מפזר אותם לזרמים ושומר באינדקס חיפוש — השאלה "מה קרה בכל הצמתים בין שתי חתימות זמן" נפתרת בשאילתה אחת במקום מעבר בין מכונות. היומן המקומי נשאר במקרה זה כמאגר זמני למקרה של ניתוק בתקשורת, אך מפסיק להיות מקור האמת היחיד.
ההבדל מתבטא בשלושה דברים. הראשון — מהירות: חיפוש אחר תקרית מבוזרת אורך דקות ולא שעות של השוואה ידנית. השני — שימור: תקופת האחסון נקבעת לפי מדיניות בצד האחסון ולא לפי גודל הדיסק של שרת מסוים, ולכן אירועים אינם נעלמים יחד עם הצומת.
השלישי — הקשר אחיד: כללי הניתוח, הסוואת שדות רגישים והתראות מוגדרים פעם אחת ומיושמים על כל המקורות, במקום להיות משוכפלים בכל מכונה.
יש גם צד שני, שראוי לומר אותו בכנות. הסכימה המרוכזת מוסיפה נקודה שצריך לתחזק: אחסון, אינדקסים, הרשאות גישה וערוץ רשת בין הסוכנים לקולט. אם לא מסננים את זרם האירועים בכניסה, הנפח גדל מהר יותר מהתועלת שבחיפוש. לכן מתחילים את ההטמעה בכללי סינון ומבנה לרשומות, ורק אחר כך מרחיבים את הכיסוי.
המסקנה המעשית פשוטה: יומנים מקומיים טובים לדיבוג של שירות אחד כאן ועכשיו, אחסון מרוכז — לתפעול מלאי שבו חשוב להתאושש מתקלה ולהוכיח מה קרה. תארו כמה צמתים יש לכם ואילו מקורות צריך לאחד — נחזור עם הערכה ותוכנית הטמעה.
ספקות טכניים נפוצים
ספקות בנוגע ללוגים מרוכזים בדרך כלל מתמקדים בשלושה דברים: האם איסוף הלוגים "יכביד" על שרתי הפרודקשן, האם האחסון יתפח לגדלים לא סבירים, והאם נקודת הכניסה האחודה ללוגים תהפוך לפרצת אבטחה. להלן כיצד כל אחד מאלה נסגר מבחינה הנדסית.
איסוף הלוגים יעמיס על שרתי הפרודקשן?
הסוכן קורא קבצים באופן אינקרמנטלי ושולח נתונים באופן אסינכרוני, עם חוצץ על הדיסק והגבלה על רוחב הפס. אם היעד אינו זמין, הסוכן אינו חוסם את האפליקציה ואינו מאבד אירועים — הם ממתינים בתור.
בנוסף, בכל מארח מוגדרת מגבלה על חלק מהמעבד והזיכרון, כך שאפילו פרץ שיא של לוגים אינו דוחק תהליכי עבודה. בפועל, עלויות התקורה נשמרות בטווח של אחוזים בודדים, ולא "אוכלות חצי מהשרת".
האחסון יתפח ויהפוך לבלתי ניתן לניהול?
הנפח נקבע לא "לפי העין", אלא לפי מדיניות שמירה: אינדקסים חמים נשמרים N ימים לחיפוש מהיר, לאחר מכן הנתונים עוברים לארכיון קר או נמחקים לפי כלל retention. בנפרד מוגדרת רוטציה לפי גודל האינדקס ולפי מספר השארדים — המאגר מפסיק לגדול ללא סוף.
חלק מהרעש (health-check, heartbeat שגרתי) נחתך בכניסה באמצעות מסננים, ורק מה שבאמת נחוץ לחקירת אירועים מגיע לאחסון.
נקודת איסוף הלוגים האחודה — זה סיכון לאבטחה?
הגישה לממשק ול-API מופרדת לפי תפקידים: מפתח רואה רק את הזרמים שלו, תורן רואה את כל הפרודקשן, ביקורת — קריאה בלבד. התעבורה בין הסוכנים ליעד מוצפנת, והיעד עצמו יושב בסגמנט רשת נפרד ואינו חשוף החוצה.
כל הפעולות במערכת מתועדות בלוג — מי, מתי ואיזו בקשה ביצע — כך שהפלטפורמה עצמה אינה הופכת לנקודה עיוורת.
מה יקרה אם היעד אינו זמין באופן זמני?
הסוכנים חוצצים אירועים באופן מקומי ושולחים אותם מחדש לאחר חידוש הקשר, כך שחלון אי-הזמינות אינו הופך לפער בלוגים. עבור זרמים קריטיים מוגדר יעד גיבוי או נתיב מסירה שני. זהו חלק סטנדרטי מהתרשים, ולא תרחיש חירום שיצטרכו לכבות ידנית.
תארו את התשתית שלכם ואת נפחי הלוגים — נחזור עם הערכה ותוכנית הטמעה.
בואו נדון במשימת הלוגים שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, עלינו להבין את סכימת איסוף הלוגים הנוכחית שלכם. תארו מהיכן מגיעים האירועים (אפליקציות, מאזני עומסים, בסיסי נתונים, התקני רשת), לאן הם נכתבים כעת ומה כבר מוגדר — זה מספיק כדי לדון במשימה באופן ענייני.
לאחר מכן נשווה את התמונה שלכם לקו המתאר הטיפוסי של Graylog ונראה היכן בדיוק הזרימות שונות:
- מקורות ודרכי מסירה: סוכנים על המארחים, קליטה ברשת, איסוף מקונטיינרים ומשירותי ענן;
- פירוק ונרמול: חילוץ שדות מטקסט לא מובנה, סכימה אחידה למקורות הטרוגניים;
- ניתוב: זרימות וכללים שלפיהם אירועים מגיעים לאינדקסים ולמאגרים הנכונים;
- אחסון ורוטציה: תוחלת חיים של אינדקסים, חלוקה לפי נפח, מדיניות מחיקת נתונים ישנים;
- חיפוש והתראות: שאילתות שמורות, לוחות מחוונים, טריגרים לחריגות וספים;
- הרשאות: תפקידים, הפרדה לפי צוותים ופרויקטים, ביקורת פעולות במערכת;
- תפעול: גיבוי תצורה, עדכון, בקרת עומס על הקליטה.
לגבי כל סעיף נאמר מה אנחנו עושים בעצמנו, והיכן נדרש הצד שלכם — הרשאות, סכימת הרשת, רשימת המקורות. כך ההערכה והתוכנית נשענות על תשתית אמיתית ולא על הנחות, ואתם רואים מראש את היקף העבודה ואת סדר ההטמעה.
תארו את הסכימה הנוכחית ומה לא מתאים לכם בה כעת — נחזור עם הערכה ותוכנית.