אנו מחפשים חריגות וחוזים כשלים באמצעות רשתות עצביות

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

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

מבוא

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

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

איור 1. ממשק ניטור גראפנה

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

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

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

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

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

שיטות לחיפוש חריגות בעת חיזוי כשלים במערכות תוכנה

קודם כל, כדאי לומר שהרעיון של חיזוי כישלונות היה בהשראת המאמר "למידת מכונה בניטור IT". כדי לבחון את יעילות הגישה בחיפוש אוטומטי אחר חריגות, נבחרה מערכת התוכנה Web-Consolidation שהיא אחד הפרויקטים של חברת NPO Krista. בעבר בוצע עבורה ניטור ידני על בסיס המדדים שהתקבלו. מכיוון שהמערכת מורכבת למדי, נלקחים עבורה מספר רב של מדדים: מחווני JVM (עומס אספן אשפה), אינדיקטורים של מערכת ההפעלה שתחתיה הקוד מבוצע (זיכרון וירטואלי, % עומס מעבד OS), מחווני רשת (עומס רשת ), השרת עצמו (עומס מעבד, זיכרון), מדדי זבוב פרא ומדדי היישום עצמו עבור כל תת המערכות הקריטיות.

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

איור 2. תכנית לאיסוף מדדים

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

1. המגמה משתנה לעתים קרובות. גרסאות שונות זמינות עבור מערכת תוכנה זו. כל אחד מהם מביא שינויים בחלק התוכנה של המערכת. בהתאם לכך, בדרך זו, מפתחים משפיעים ישירות על המדדים של מערכת נתונה ויכולים לגרום לשינוי מגמה;
2. תכונת היישום, כמו גם המטרות שלשמן לקוחות משתמשים במערכת זו, גורמות לרוב לחריגות ללא השפלה קודמת;
3. אחוז החריגות ביחס לכל מערך הנתונים קטן (<5%);
4. ייתכנו פערים בקבלת מחוונים מהמערכת. בכמה פרקי זמן קצרים, מערכת הניטור לא מצליחה להשיג מדדים. לדוגמה, אם השרת עמוס יתר על המידה. זה קריטי לאימון רשת עצבית. יש צורך להשלים את החסר באופן סינטטי;
5. מקרים עם חריגות רלוונטיים לרוב רק לתאריך/חודש/שעה ספציפיים (עונתיות). למערכת זו יש תקנות ברורות לשימוש בה על ידי המשתמשים. בהתאם לכך, המדדים רלוונטיים רק לזמן מסוים. לא ניתן להשתמש במערכת באופן קבוע, אלא רק בחלק מהחודשים: באופן סלקטיבי בהתאם לשנה. נוצרים מצבים שבהם אותה התנהגות של מדדים במקרה אחד יכולה להוביל לכשל של מערכת התוכנה, אך לא במקרה אחר.
   מלכתחילה נותחו שיטות לאיתור חריגות בנתוני ניטור של מערכות תוכנה. במאמרים בנושא זה, כאשר אחוז החריגות קטן ביחס לשאר מערך הנתונים, לרוב מוצע להשתמש ברשתות עצביות.

ההיגיון הבסיסי לחיפוש חריגות באמצעות נתוני רשת עצבית מוצג באיור 3:

איור 3. חיפוש חריגות באמצעות רשת עצבית

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

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

רשת נוירונים חוזרת

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

איור 4. דוגמה לרשת עצבית חוזרת עם תאי זיכרון LSTM

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

מקודד אוטומטי לחיזוי כשל

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

איור 5. דוגמה לפעולת מקודד אוטומטי

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

המשימה של המקודד האוטומטי היא למצוא את מדדי הזמן r0 ... rn המתאימים לאלמנטים החריגים בווקטור הקלט X. אפקט זה מושג על ידי חיפוש השגיאה בריבוע.

איור 6. מקודד אוטומטי סינכרוני

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

מנגנון למזעור תוצאות חיוביות כוזבות

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

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

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

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

איור 7. ערכת חיזוי כשל המבוססת על ניתוח מרחב מטרי

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

איור 8. ממשק מערכת הניטור הניסיונית

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

דוגמה לזיהוי חריגות המבוסס על ביצועי CPU באמצעות הרשת העצבית RNN LSTM (איור 9).

איור 9. גילוי RNN LSTM

מקרה פשוט למדי, למעשה חריג רגיל, אך מוביל לכשל במערכת, חושב בהצלחה באמצעות RNN LSTM. אינדיקטור האנומליה בפרק זמן זה הוא 85-95%; כל מה שמעל 80% (הסף נקבע בניסוי) נחשב לאנומליה.
דוגמה לזיהוי חריגות כאשר המערכת לא הצליחה לאתחל לאחר עדכון. מצב זה מזוהה על ידי המקודד האוטומטי (איור 10).

איור 10. דוגמה לזיהוי מקודד אוטומטי

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

מסקנה

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

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

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

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

מקור: www.habr.com