AI Infrastructure Monitoring — Monitoring חכם במקום Thresholds בלבד

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

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

מהנדס מגדיר כלל התראה: אם זמן התגובה של ה-API עולה מעל 500 מילישניות, שלח התראה. הכלל עובד מצוין בימי שגרה. אבל בשעות השיא, כשהתעבורה כפולה מהרגיל, זמן התגובה עולה באופן טבעי ל-450 מילישניות - ולא, זו לא תקלה, זו התנהגות צפויה לגמרי בעומס גבוה. יום אחד, בשעת שיא, זמן התגובה מגיע ל-490 מילישניות בגלל בעיה אמיתית - אבל הכלל לא מתריע, כי עדיין לא חצינו את ה-500. זה בדיוק הכשל המובנה בניטור מבוסס Threshold קבוע - הוא עיוור להקשר. AI Infrastructure Monitoring מציע גישה אחרת: שכבת ניטור שלומדת מה "רגיל" בכל הקשר נתון, ומתריעה על סטייה אמיתית מהדפוס, לא על חציית מספר קבוע שנקבע פעם אחת ונשכח.

הבעיה המובנית בכללי סף קבועים

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

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

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

איך נראית התייחסות מבוססת הקשר

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

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

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

למידה מדפוסים לעומת הגדרה ידנית

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

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

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

עדכון רציף מול הכשרה חד-פעמית של המודל

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

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

ניטור בקנה מידה: כשיש אלפי מדדים ומאות שירותים

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

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

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

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

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

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

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

שאלות נפוצות

האם צריך לוותר לגמרי על כללי Threshold קבועים?

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

כמה זמן לוקח למודל ללמוד את הדפוסים הרגילים של מערכת חדשה?

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

מה קורה כשהמערכת עצמה משתנה משמעותית (למשל אחרי שדרוג גדול)?

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

איך מסבירים לצוות התורן למה הוא מקבל התראה שלא הייתה מגיעה בעבר?

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

האם ניטור מבוסס AI יקר יותר מניטור קלאסי?

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

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

תגיות: AI Infrastructure Monitoring · ניטור חכם · Threshold Monitoring · זיהוי אנומליות · Observability · AIOps

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