מדוע ניתוח לוגים ידני מפספס אנומליות
ניתוח לוגים ידני נתקל בתפוקה של האדם: התורן סוקר את זרם האירועים בעיניים ומחזיק בראשו כמה שורות אחרונות, ולא את הקשרים בין שירותים לאורך השעה שחלפה. חלק מהאירועים המוחמצים אינם חוסר קשב, אלא פיזיקה: אין במה להשוות את התנהגות השירות בשתי שעות שונות בלי להישען על מטריקות.
אנומליה כמעט לעולם אינה נראית כמו שורה אדומה אחת. זהו גידול בשיעור השגיאות בנתיב מסוים ביחס לקו הבסיס, זינוק של פסקי זמן אצל צרכן אחד, או סדרה של חזרות על בקשה. בזרם הכללי רשומות כאלה הן בודדות, בעוד השגרתיות מרובות בסדרי גודל, ולכן האות הנדיר טובע ברעש.
פירוק אירועים ידני לפי שירות אחד אינו מגיע לס�יבת השורש: היא נמצאת בשירות השכן — בתור, במאגר החיבורים, בתשובה של מערכת חיצונית.
הזמן עד לגילוי בסכימה כזו נקבע לא על ידי הניטור, אלא על ידי התלונה הראשונה של המשתמש. כל עוד האירוע לא הגיע לתמיכה, הוא מצטבר. נתוני הענף שאוסף DORA מראים: צוותים שמאתרים תקלות לפי אותות של המערכת ולא לפי פניות, מתאוששים מהר יותר פי כמה ופחות חוזרים לאותה תקלה שוב.
נפרק כיצד זה נסגר: איזה זרם אירועים נחשב לנורמה, היכן עובר גבול הרעש, וכיצד ההתראה מתחילה לפעול לפני המשתמש בלי להפוך לזרם של התראות שווא.
מה נותן ניתוח לוגים אוטומטי במקום בדיקות ידניות
פירוק ידני מתרחב באופן לינארי: ככל שיש יותר שירותים ומקורות, כך יש יותר בדיקות מדגמיות. המהנדס בודק את מה שהוא מספיק, והאנומליה חיה בין משמרות — מהתקלה הראשונה ועד הגילוי חולפות שעות. תצפית רציפה במקום מדגם מתרגמת את מהירות הגילוי לדקות.
המודל בונה קו בסיס של התנהגות בנפרד לכל מקור ומשווה אליו את הזרם הנוכחי, תוך התחשבות בשיאים יומיים ושבועיים. הספים מכוילים לפי אירועים שכבר נותחו, ולכן שיעור התראות השווא יורד לכמה אחוזים בודדים — התורן מפסיק להתייחס להתראות כרעש. Elasticsearch נשאר מאגר הלוגים: שכבת הניתוח קוראת את אותו זרם, ואין איסוף כפול.
כיסוי המקורות גדל בלי לכתוב מחדש את החוקים. שירות חדש מתחבר כזרם נפרד, ופרופיל ההתנהגות עבורו נבנה מההיסטוריה שנצברה — גם מערכות שאליהן הבדיקות הידניות לא הגיעו נכנסות לתצפית.
העומס על התורנים יורד הודות לשני דברים: השגרה עוברת לאוטומציה, והאותות מגיעים מקובצים לפי אירוע ולא כשורות נפרדות. התורן מקבל הקשר — מה השתנה ואילו צמתים נפגעו — ומפרק את הסיבה במקום להרכיב את התמונה ביד.
מצבי זיהוי אנומליות: השוואת גישות
מצב הזיהוי קובע את הפשרה המרכזית: כמה תקלות אמיתיות המערכת תפספס וכמה התראות שווא תמסור לתורן. אין אפשרות אוניברסלית — הבחירה תלויה ביציבות פורמט הלוגים, בקיומו של תיוג אירועים קודמים ובמחיר ההחמצה. להלן הגישות שביניהן בוחרים בהתחלה.
בפועל משלבים בין המצבים: חוקי סף סוגרים מטריקות קריטיות, קווי בסיס — זינוקים עונתיים, ואשכול הודעות — רעש טקסטואלי. סכימת זיהוי היברידית מאחדת את האותות של כל השכבות לזרם אחד ומפחיתה באופן ניכר את שיעור התראות השווא.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חוקי סף | מטריקה עם נורמה ברורה: תורים, שגיאות, השהיות | כיוון ידני לכל שירות, נשבר בשיאים עונתיים |
| קווי בסיס סטטיסטיים | זרם אחיד ופרופיל עומס חוזר | דרושה היסטוריה לאימון, מגיב לאט לשינוי חד בהתנהגות |
| אשכול הודעות | טקסט בעל מבנה חלש, תבניות רעש רבות | דורש נרמול, האשכולות מאבדים משמעות בשינוי פורמט הרשומה |
| מודלים ללא פיקוח | אין תיוג של אירועים קודמים | מציגים אנומליה בלי סיבה, דרוש ניתוח של אנליסט |
| סכימת זיהוי היברידית | פארק שירותים מגוון וסוגי לוגים שונים | הטמעה ארוכה יותר, דרושה הגדרת קשרים בין השכבות |
הסדר הוא כזה: תחילה מעריכים את צפיות הזרם ואת איכות התיוג, אחר כך מרכיבים סט מינימלי של שכבות — ורק לאחר בדיקה על נתונים היסטוריים מרחיבים את הסכימה. כך המערכת עולה לפעולה עם רגישות נשלטת, ולא עם זרם התראות שהתורן מתחיל להתעלם ממנו.
כיצד אנו מטמיעים את המערכת: שלבי עבודות ההנדסה
העבודות מתקדמות באיטרציות: תחילה מרכיבים תמונה מלאה של המקורות והזרמים, אחר כך בונים את צינור העיבוד, ורק לאחר מכן מפעילים את ההתראות. סדר זה נדרש כדי שהחוקים ייוולדו מרשומות אמיתיות, ולא מהנחות על איך בנויה המערכת.
- ביקורת מקורות. עוברים על יישומים, שירותים, מסדי נתונים, תורים וציוד רשת: מתעדים פורמטים של רשומות, תדירות הופעה, נפח יומי, שדות ובעלי הרשאות גישה.
- סכימת זרמים. מתארים את מסלול האירוע מסוכן האיסוף דרך החוצץ והתעבורה ועד למאגר, ומסמנים קטעים שבהם אפשריים אובדנים ועיכובים.
- נרמול אירועים. מביאים רשומות מגוונות לסכימה אחידה — זמן, מקור, רמה, מזהה בקשה, טקסט. כפילויות ורעש תפעולי נחתכים כאן, כדי שאותו שדות ישמשו גם את החיפוש וגם את החוקים.
- הגדרת חוקים ומודלים. מגדירים ספים, קשרים בין אירועים של שירותים שונים ופרופילי בסיס של התנהגות תקינה לכל צומת.
- בדיקה על נתונים היסטוריים. מריצים את החוקים על הלוגים שנצברו ומשווים את התוצאה למה שהתורנים זוכרים כאירועים אמיתיים: כך מכוילים את הרגישות ומסירים התראות שווא.
- הכשרת תורנים. עוברים על תיוג ההתראות, סדרי העדיפויות, סדר ההסלמה והפעולות למקרה שהאנליזר עצמו אינו זמין.
- מסירה וליווי. מוסרים תיעוד, הרשאות ותקנון לשינוי חוקים, כדי שהצוות יוכל לפתח את המערכת בלעדינו.
מה אנו מוסרים ללקוח בסיום הפרויקט
פרויקט לניתוח לוגים מסתיים לא בהצגת לוח ניטור, אלא בסט ארטיפקטים שאיתם הצוות שלכם ממשיך לעבוד בלעדינו. כל סעיף הוא קובץ, סכימה או מסמך, ולא תיאור של "איך זה תוכנן".
מוסרים לתוך הסביבה שלכם ומפרקים בשיחת וידאו: היכן חי החוק, מה יקרה בעת תקלה במקור, וכיצד להרחיב לשירות חדש.
- קונפיגורציות של אוספים ומפרסרים לכל פורמט מקור, כולל רשומות מרובות שורות ושורות לא סטנדרטיות. מקור חדש מתחבר בהעתקת פרופיל ותיקון שדות, בלי פיתוח קוד.
- סכימת זרמים מהמקור ועד להתראה, עם נקודות חציצה והתנהגות בעת אי-זמינות של הנמען. ממנה רואים היכן אירוע יכול ללכת לאיבוד ומה עוקב אחרי זה.
- חוקים וספים עם הנמקה: לכל אחד מצוין על איזה נתונים היסטוריים נבדק ואיזה שיעור התראות שווא הוא נותן. הסף משתנה בקונפיגורציה, ולא בקוד.
- מדיניות גישה לאירועים: הפרדה לפי תפקידים, הסוואת שדות רגישים בכניסה למאגר, יומן פניות. ביקורת גישה אינה דורשת ייצוא נפרד.
- תקנון תורנות: רמות קריטיות, סדר הסלמה, אמות מידה לזמן תגובה, פעולות בעת זינוק של התראות מאותו סוג.
- הוראה לחיבור מקורות חדשים — רשימת בדיקות שלב-אחר-שלב שהאירועים הגיעו ונותחו כראוי.
קייס: כיצד קיצרנו את זמן התגובה לאירועים
הלקוח — שירות מוצרי עם מערכת מבוזרת: עשרות יישומים, מאזן עומסים, broker של תורים, מסד נתונים ואירועי מתזמר. הלוגים מכל הסביבות נאספו למאגר אחד, אך נותחו ביד ורק לאחר פניות משתמשים — כלומר בדיעבד.
לפני: על האירוע נודע מהתמיכה
ההתראות עמדו על חוקי סף לפי מטריקות בודדות: או שלא פעל דבר, או שהגיעו עשרות התראות שמהן בודדות היו שימושיות. חלק מהחוקים התורנים השביתו תוך העלאת ספים — הרעש נעלם יחד עם הרגישות. זמן ממוצע מהאנומליה הראשונה בלוגים ועד לתגובת המהנדס — כשעה.
היקר מכל לא היה אובדן זמינות, אלא הידרדרות איטית: גידול בזמן התגובה של מסד הנתונים ודליפת חיבורים הצטברו שעות, והמשתמשים הבחינו בכך לפני הניטור.
מה שינינו ומה קיבלנו
חברנו תשעה מקורות: לוגים של יישומים, מאזן העומסים, ה-broker, מסד הנתונים, יומנים תפעוליים ואירועי האשכול. הפירוק והאחסון נבנו על Grafana Loki ומודל שבונה פרופיל התנהגות תקינה לפי תבניות הודעות ותדירויות.
האות הופך לסטייה מהפרופיל, ולא לחריגה מסף סטטי, ולכן ההתראה מגיעה עם הקשר מוכן: שירות, תבנית, חלון, ובכמה גדלה התדירות.
זמן הגילוי הצטמצם מ-55 דקות ל-4 — בערך פי שנים עשר. שיעור התראות השווא ירד מ-78% ל-15%: התורן הפסיק לפרק רעש והחזיר את רגישות החוקים.
סוג התקלות "הידרדרות הדרגתית בתשובות מסד הנתונים ודליפת חיבורים" הפסיק להגיע למשתמשים — האנומליה נתפסת בעלייה של השהיות, לפני השגיאות ההמוניות הראשונות.
מה לעשות אם הלוגים כבר נאספים, אך אינם מנותחים?
איסוף לוגים ופירוקם הם משימות שונות, והראשונה לרוב סגורה הרבה לפני השנייה. הסוכנים כותבים למאגר, הרוטציה מוגדרת, הנפח גדל, אך בפנים טקסט שטוח שאי אפשר לא לקבץ לפיו רשומות ולא לבנות ממנו מטריקה. להלן מה שנבנה מעל המאגר הקיים, ומה שנתקל במקורות.
מעל המאגר נבנית שכבת פירוק: חוקים לפי תבניות, חילוץ שדות — רמת חשיבות, רכיב, מזהה בקשה, קוד תשובה, משך הפעולה — והבאה לסכימת אירועים משותפת. האיסוף עצמו אינו נבנה מחדש, וההיסטוריה מורצת באותו פירוק בדיעבד: מיד רואים היכן האנומליה כבר הייתה וכמה זמן היא חוזרת.
ברמת המקורות יש לבנות מחדש במקום שבו ההודעה אינה נושאת הקשר: "שגיאת חיבור" בלי צומת, בקשה ומזהה מקצה-לקצה נותנת שדות מלאים לכאורה אך חסרי תועלת. הפתרון הוא תיקון הלוגינג בשירותים עצמם — פורמט רשומה אחיד, סט שדות חובה, מזהה trac, והפרדה בין רמת החשיבות לטקסט. היקף התיקון קטן, אך דווקא הוא קובע את דיוק ההתראות.
בנפרד חשוב סדר ההודעות: אם אירוע מודבק מכמה שורות או נכתב באופן אסינכרוני, בפירוק אובד הרצף, וזינוק שגיאות לאחר עדכון גרסה אינו מתקבץ לאירוע אחד. קיבוץ לפי מזהה בקשה וחלון זמן סוגר זאת חלקית; אמין יותר — לכתוב את האירוע כרשומה אחת.
העבודות מתנהלות כך: מלאי פורמטים לפי מקורות, פירוק ומבנה של אירועים מעל המאגר, תיקוני לוגינג ממוקדים, ואחר כך חוקי זיהוי והתראות. מדד התוצאה — שיעור האירועים שנותחו לשדות: כשהוא גבוה מ-95%, ההתראות נבנות על המבנה ולא על חיפוש מחרוזות משנה, והתראות השווא פוחתות פי כמה.
ספקות טכניים לפני תחילת העבודות
הספקות בשלב זה הם בדרך כלל הנדסיים: כיצד לחבר מקור נוסף בלי לכתוב מחדש את העיבוד, ומה יקרה אם זרם האירועים יגדל פי כמה. להלן תשובות ישירות למה שנשאל לרוב לפני תחילת העבודות.
כיצד מתחבר מקור חדש?
באמצעות מתאם בכניסה: מפרקים את הפורמט, מביאים את השדות לסכימה אחידה, חותכים כפילויות, ומשייכים את הרשומות לשירות ולבעלים. מכאן והלאה זו קונפיגורציה, ולא עיבוד מחדש של המודל.
לפני ההפעלה בזרם הייצור מריצים את ההיסטוריה שנצברה ובודקים אילו התראות המערכת הייתה נותנת — השוואה לתמונה הנוכחית מראה את מחיר הטעות מראש.
כיצד מתמודדים עם התראות שווא?
ספים מגדירים על ההיסטוריה, ולא לפי העין: החוקים חותכים רעש מוכר, והמודל תופס סטיות מהפרופיל הרגיל של השירות. חזרות של אותו אירוע מקובצות להתראה אחת, וחלון הדיכוי מונע מהתורן לקבל מפולת. בנפרד מחשבים את שיעור השווא מכלל ההתראות — לפיו רואים אם אפשר לסמוך על הפיד.
מה עם נתונים רגישים?
ההסוואה נעשית בצד המקור, לפני השליחה: שדות אישיים ותשלומיים אינם נכנסים לפירוק. הנתונים נשארים בסביבה שלכם, הגישה מופרדת לפי תפקידים, והפניות מתועדות ביומן. לניתוח אירוע אין צורך בייצוא של אירועים גולמיים החוצה.
האם המערכת תעמוד בזינוק חד בנפח?
הקליטה מתרחבת אופקית, והזינוק נבלם בחציצה. העדיפות לשירותים קריטיים: מקורות משניים מדוללים, והמערכת מדווחת על ההידרדרות במפורש, ולא מאבדת אירועים בשקט. בודקים זאת בהרצת עומס לפני ההפעלה, ולא ברגע האירוע.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהערכת הזמנים תהיה מדויקת ולא "לפי העין", אנו זקוקים להקשר על נוף הלוגינג הנוכחי. ספרו לנו מהיכן נאספות הרשומות — יישומים, מאזני עומסים, מסדי נתונים, תורים — אילו פורמטים בשימוש, כמה מקורות מעורבים ואיזה נפח יומי עובר. בנפרד מועיל להבין כיצד בנויות כעת ההתראות ולאן הן נשלחות.
תארו את אופי התקלות שצריך לתפוס: זינוקים נדירים של שגיאות, גידול הדרגתי בהשהיות, אנומליות לפי משתמש או צומת מסוים. ככל שהדוגמאות של אירועים קודמים מפורטות יותר, כך נדייק יותר בבחירת שיטות הזיהוי וספי ההפעלה.
אם קיימים לוגים היסטוריים ותיוג "תקין / אנומליה" לפחות לחלק מהתקופה — הדבר מקצר באופן ניכר את כיוונון המודל ומפחית את שיעור התראות השווא.
בתגובה אנו שולחים לא הצעת מחיר של שורה אחת, אלא תוכנית שלבים עם נקודות ביקורת:
- סכימת איסוף, אחסון ורוטציה של לוגים עם הצמדה לתשתית שלכם;
- רשימת מקורות ופורמטים שייכנסו לניתוח בשלב הראשון;
- הרכב מודל הזיהוי וחוקי ההתראות: ספים, חלונות, סדרי עדיפויות;
- לוח זמנים של העבודות: פיילוט על שירות אחד, הרחבה לשאר, והוצאה לפעולה;
- סדר האינטגרציה עם מערכות ההתראות ולוחות משמרות;
- קריטריוני קבלה — שיעור התראות השווא והזמן מהאירוע ועד להתראה;
- רשימת הרשאות, סביבות ונתונים שנדרשים מצדכם.
תארו את המשימה בצורה חופשית — נחזור עם הערכת זמנים, תוכנית שלבים ותחומי אחריות.