AIOps: הטמעת ניתוח לוגים ותקריות

פיתוח AIOps: מדוע מבחינים בתקלה רק בדיעבד

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

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

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

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

מה משתנה לאחר הטמעת ניתוח הלוגים

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

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

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

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

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

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

מצבי ניתוח לוגים: זורם, באצוות, היברידי

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

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

השוואה בין מצבי עיבוד הלוגים

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

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

שלבי ההטמעה: ביקורת, תכנית, פיתוח, בדיקה

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

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

מה אנו מוסרים לידיכם: קונפיגורציות, כללים, נהלים

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

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

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

מקרה בוחן: זמן גילוי התקריות לפני ואחרי ההטמעה

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

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

מה שינו

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

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

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

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

במה AIOps שונה מניטור לוגים קלאסי

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

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

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

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

ספקות טכניים לפני תחילת הפרויקט

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

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

כמה נתונים נצטרך לאחסן?

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

אילו הרשאות נדרשות למערכות שלנו?

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

כיצד זה ישתלב במערכות שלנו?

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

כמה זמן נמשכת ההטמעה?

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

נדון במשימה שלכם: מה נדרש להערכה

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

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

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