AI Log Analysis — ניתוח מיליוני Logs באמצעות LLM

מאת צוות מדיה דיל · 09.08.2026 · Technology · 8 דק׳

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

מהנדס מחפש למה בקשה ספציפית נכשלה. הוא כותב שאילתת חיפוש בכלי הלוגים - סוג הבקשה, קוד השגיאה, וחלון זמן משוער - ומקבל אלפי תוצאות, כי אותו קוד שגיאה מופיע גם ממקורות אחרים לגמרי. הוא מצמצם, מוסיף פילטר, מקבל שוב יותר מדי או פחות מדי. אחרי עשר דקות של ניסוי וטעייה עם שאילתות, הוא עדיין לא מצא את השורה הספציפית שהוא צריך. זו החוויה היומיומית של עבודה עם Logs בקנה מידה גדול - מיליוני שורות ביום, כלי חיפוש שדורש שליטה בתחביר מסובך, ופער עצום בין "מה שאני רוצה לדעת" לבין "השאילתה שתביא לי את זה". AI Log Analysis נועד לסגור את הפער הזה - לא רק לחפש טקסט, אלא להבין Logs ברמה סמנטית ולענות על שאלות בשפה טבעית.

למה חיפוש טקסטואלי קלאסי לא מספיק

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

הבעיה מחריפה כשלוגים מגיעים ממקורות שונים בפורמטים שונים - שירות אחד כותב JSON מובנה, שירות אחר כותב טקסט חופשי, שירות שלישי מדפיס stack traces בפורמט שונה לגמרי. חיפוש טקסטואלי לא "מבין" ששתי הודעות בפורמט שונה מתארות בעצם את אותה בעיה - "connection timeout to database" ו-"DB unreachable after 30000ms" הן, מבחינת מנוע חיפוש מבוסס מילות מפתח, שתי מחרוזות שונות לחלוטין, אף שלמעשה מדובר באותה תופעה.

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

ארכיטקטורת Pipeline לניתוח Logs עם LLM

ניתוח לוגים בקנה מידה גדול לא יכול להזין את כל הלוגים הגולמיים למודל שפה בכל שאילתה - זה יקר מדי, איטי מדי, וחורג ממגבלות ה-context window בקלות. ארכיטקטורה עובדת מבוססת על שכבת עיבוד מקדים שמנרמלת ומסכמת לוגים לפני שהם מגיעים למודל. שלב ראשון הוא Structured Parsing - זיהוי אוטומטי של תבנית בכל סוג לוג, כך שגם לוג טקסט חופשי הופך לרשומה מובנית עם שדות ברורים (רמת חומרה, שירות מקור, זמן, גוף ההודעה).

שלב שני הוא אינדוקס וקטורי - הודעות לוג מומרות ל-Embedding ונשמרות במסד נתונים וקטורי, מה שמאפשר חיפוש דמיון מהיר גם על נפחים גדולים. חשוב לא לשמור Embedding לכל שורת לוג בנפרד בזמן אמת - זה יקר ומיותר; רוב המימושים בונים אינדקס על דפוסי הודעות (Templates) ולא על כל מופע בנפרד, ומתייגים כל שורה חדשה לפי הדפוס הקרוב ביותר. הגישה הזו קרובה מבחינה עקרונית לChunking סמנטי שמשמש במערכות RAG.

שלב שלישי הוא השכבה שבה מודל השפה נכנס לתמונה - לא לקריאת כל הלוגים, אלא לניתוח תוצאות מסוננות ומצומצמות: "הבא לי את כל השורות עם רמת חומרה גבוהה בחלון הזמן הזה, מקובצות לפי דפוס". מודל השפה מקבל קלט מצומצם ומשמעותי, ויכול לספק ניתוח ותקציר בשפה טבעית - "יש עלייה של 40% בהודעות timeout מהשירות X, מתחילות ב-14:32, מתואמות בזמן עם דיפלוי". החלוקה הזו בין עיבוד מקדים זול לבין ניתוח LLM ממוקד היא המפתח לפתרון שעובד בקנה מידה בלי לקרוס מבחינת עלות.

ניהול עלות: הבעיה שמפילה הטמעות

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

טכניקה נוספת שמצמצמת עלות משמעותית היא Prompt Caching - כשחלק גדול מהקונטקסט חוזר על עצמו בין שאילתות (למשל, הגדרת הפורמט שבו הלוגים מנורמלים), אפשר לשמור את החלק הזה במטמון ולחסוך עיבוד חוזר. הנושא מפורט לעומק במדריך Prompt Caching ומתחבר לעקרונות הרחבים יותר של AI Cost Engineering. בפועל, ארגונים שמיישמים את שתי הטכניקות יחד - סינון מוקדם וקיבוץ - מדווחים על ירידה דרמטית בעלות ביחס לגישה נאיבית של "שלח הכל למודל".

מציאת קורלציות בין שירותים שונים

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

המשמעות המעשית היא שסוכן AI שמנתח לוגים יכול לענות על שאלה כמו "מה קרה לפני שהשירות הזה התחיל לזרוק שגיאות" ולא להסתפק בהצגת השגיאות עצמן - הוא בוחן את הלוגים של השירותים שהשירות הזה תלוי בהם, ומחפש חריגה שקדמה בזמן להתחלת השגיאות. היכולת הזו מתחברת ישירות לניתוח שורש בעיה שמפורט במדריך AI Root Cause Analysis, וגם משמשת בסיס לתדריכי תקלה שמתוארים במדריך AI Incident Response.

שאילתות בשפה טבעית: מה זה נותן בפועל

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

חשוב לתכנן את שכבת התרגום הזו בזהירות - מודל שפה שמתרגם שאלה בשפה טבעית לשאילתה על מסד נתונים גדול חייב לכלול בקרות שמונעות שאילתות שגורמות לעומס חריג (כמו "תביא לי את כל הלוגים משנה האחרונה" בלי הגבלה). הנושא הזה - תרגום שפה טבעית לשאילתה מובנית - מפורט בהרחבה במדריך Natural Language to SQL, שהעקרונות בו רלוונטיים ישירות גם לשאילתות על מערכות לוגים.

מדד השוואה מתמשך: הלוג של אתמול מול הלוג של היום

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

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

טעויות נפוצות

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

דוגמה מהשטח: איתור תקלה שהוסתרה מאחורי הודעות שונות

צוות שמתחזק פלטפורמת מסחר אלקטרוני שילב שכבת ניתוח לוגים סמנטית אחרי שחוו קושי חוזר באיתור תקלות שהתבטאו בהודעות שגיאה משתנות. במקרה אחד, מהנדס חיפש "payment failed" וקיבל תוצאות חלקיות בלבד - חלק מהמופעים נרשמו כ-"charge declined", אחרים כ-"transaction timeout at gateway", ואף אחד מהם לא הכיל את המחרוזת המדויקת שהוא חיפש. שכבת החיפוש הסמנטי זיהתה ששלושת הביטויים האלה קרובים מבחינה סמנטית, והציגה אותם יחד כתופעה אחת - עלייה משמעותית בכשלי תשלום שהחלה בשעה מסוימת.

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

שאלות נפוצות

האם צריך להחליף את מערכת הלוגים הקיימת כדי ליישם את זה?

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

איך מתמודדים עם נפח לוגים שגדל כל הזמן?

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

מה רמת הדיוק של חיפוש סמנטי בהשוואה לחיפוש טקסטואלי מדויק?

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

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

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

כמה זמן לוקח להטמיע שכבת ניתוח כזו על מערכת קיימת?

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

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

תגיות: AI Log Analysis · ניתוח Logs · LLM Observability · חיפוש סמנטי בלוגים · Log Aggregation · ניטור מערכות

← חזרה לבלוג · צור קשר