הגדרת Datadog Watchdog: מדוע אנומליות חומקות
סף סטטי עונה רק על השאלה «האם חצינו את הגבול», אך אינו אומר דבר על כיוון התנועה. דגרדציה של שירות לעיתים רחוקות נראית כמו קריסה: זמן התגובה עולה באחוזים בודדים ביום, שיעור השגיאות בפעולות מסוימות מטפס, תור הכתיבה מצטבר לאט — וכל מטריקה נשארת באזור הירוק.
בדרך כלל קובעים את הסף לפי השיא של התקרית הקודמת בתוספת מרווח, והכלל מתעוור. תנודות עונתיות ומהדורות יוצרות התראות שווא, הספים מועלים עוד יותר, וחלק מהכללים מועברים למצב «התראה בלבד». כך נוצרת עייפות התראות: התורן אינו פותח את ההתראה, מפני שתשע מתוך עשר אינן דורשות פעולה.
התוצאה צפויה — התקרית עולה ממשתמשים בתמיכה, ולא מהמערכת. עד לרגע שבו יש מספיק פניות לתגובה, הדגרדציה נמדדת בשעות, אזור החיפוש — בעשרות שירותים, וגרסת הדיפלוי שאחריה הכול התקלקל נזכרת מלוגים של מהדורות.
הגדרת Datadog Watchdog בנויה על היגיון הפוך: המערכת לומדת את התנהגות המטריקה לפי שעות היום, ימי השבוע ושינויים אחרונים בקוד, לכן גילוי אנומליות מופעל על סטייה מהנורמה של השירות עצמו, ולא מקו קשיח. נסביר כיצד זה נסגר בפועל.
מה נותן גילוי אנומליות לפי התנהגות מטריקות
כללי סף תופסים רק את מה שעבורו הוגדר מראש גבול: «דיסק תפוס מעל 85%», «תור ארוך מערך הסף». סוג כשלים שמתפתח בהדרגה — עלייה בהשהיה באחד המקטעים, ירידה בתפוקה בשעות שיא — אינו נכנס תחת הסף עד לרגע שבו המשתמש כבר רואה את הדגרדציה. גילוי לפי התנהגות מטריקות סוגר בדיוק את הפער הזה.
אנומליה נבנית על תחזית: עבור כל מטריקה המערכת מחזיקה פרופיל רגיל שלה — עונתיות יומית ושבועית, מגמה, קשר עם אותות שכנים — ומסמנת סטייה מהמסלול הצפוי. בגלל זה הזמן עד לגילוי מתקצר משעות לדקות: האות מגיע בקטע המוקדם של העקומה, כאשר הסטייה עדיין אינה נקראת בעין בגרפים.
התראות שווא פוחתות מפני שהמסגרות מחושבות מחדש יחד עם התנהגות המערכת, ואינן נשארות קבועות ברמה שנקבעה לפי תעבורה של השנה שעברה. פחות רעש — פחות קמות לילה: העומס על התורן יורד, והקשב עובר לניתוח תקלות אמת, ולא לאישור תנודות רגילות.
יש גם תופעת לוואי שלא שמים לב אליה מיד: מטריקות שאף אחד לא עקב אחריהן, מפני שלא היה מה להציב עבורן סף, נכנסות למעקב אוטומטית. זה משנה לא רק את מהירות התגובה, אלא גם את עצם רשימת הדברים שהצוות מסוגל להבחין בהם לפני תלונה.
אפשרויות לגילוי אנומליות והגדרתן
לפני הגדרת Datadog Watchdog יש להחליט לפי איזה סימן המערכת מחשיבה מטריקה כחריגה מהנורמה. ארבע גישות נבדלות ברגישות, בשיעור התראות השווא ובהיקף העבודה הידנית בתחזוקה — אין ביניהן אחת אוניברסלית.
בפועל בוחרים את הגישה לפי אופי העומס, ולא לפי «מתקדמות» השיטה. לרוב בסביבת עבודה מתקיימות כמה גישות בעת ובעונה אחת: תוכנית היברידית מסירה את המגבלות של כל אחת בנפרד, אך נשענת על תגיות אחידות וכללי התראה.
השוואה לפי עומס
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ספים סטטיים | עומס אחיד ומגבלות קשיחות: מילוי דיסק, אורך תור, זיכרון. מוגדרים בכללי התראה, אין צורך בלמידה | אינם סובלים עונתיות: ירידת לילה ושיא מתוארים במספר אחד — מכאן או החמצת תקלה, או התראות מתמשכות |
| סטייה מקו בסיס | מטריקות עם קצב יומי ושבועי: זמן תגובה, מספר בקשות, שיעור שגיאות | קו הבסיס נבנה מחדש אחרי מהדורות גדולות, דורש היסטוריה להצטברות ומחליק תנודות חדות נדירות |
| מודלים התנהגותיים | שירותים רבים שבהם חשובים הקשרים בין מטריקות, ולא ערכים בודדים; אנומליות מתגלות ללא ספים ידניים | נדרש היקף נתונים וזמן ללמידה; סיבת ההתראה פחות שקופה מאשר אצל סף |
| תוכנית היברידית | עומס מגוון: ספים מכסים משאבים, קו בסיס — מטריקות קצביות, מודלים — קשרים בין שירותים | נשענת על משמעת בתיוג: בלי תגיות אחידות ההתראות משוכפלות, וניתוח התקלה מתארך |
שלבי הטמעה: מביקורת מטריקות ועד נוהל
לפני הפעלת גילוי אנומליות אוטומטי ב-Datadog Watchdog, יש להבין מה בכלל קיים במערכת. בלי מלאי של שירותים ומטריקות, הכלי מתחיל לאותת על מה שלא חשוב לעסק, והתורנים מפסיקים להגיב להתראות. לכן העבודה מתנהלת ברצף — מתיאור המערכת לנוהל.
- ביקורת מטריקות ומלאי שירותים. אוספים רשימת שירותים, הבעלים שלהם ומטריקות שמתארות באמת את הבריאות: זמן תגובה, שיעור שגיאות, אורך תור, רוויה של משאבים. מטריקות מיותרות פוסלים — הן מרעישות את קווי הבסיס.
- מפת שירותים ותלויות. מתעדים מי קורא למי: סטייה ברמה התחתונה מסבירה תנודה ברמה העליונה. בלי מפה אירוע אחד ייצור עשרה התראות.
- הגדרת קווי בסיס. עבור כל מטריקה מתארים התנהגות תקינה בהתחשב בעונתיות יומית ושבועית, ולא בממוצע על פני כל תקופת התצפית.
- הגדרת רגישות. בוחרים סף לפי מחיר ההחמצה ומחיר התראת השווא: מסלולים קריטיים — מחמירים יותר, משניים — מקלים יותר.
- בדיקה על נתונים היסטוריים. מריצים את הכללים על מטריקות מצטברות ומשווים לאירועים אמיתיים: כמה נמצאו, כמה הוחמצו, כמה היו שווא.
- נוהל תורנויות. קובעים מי ומתי מגיב, אילו התראות מעירות בלילה ואילו ממתינות לבוקר.
- מסירה והדרכת תורנים. מנתחים את ההתראות הראשונות יחד עם הצוות ומדייקים ספים: קווי הבסיס מבשילים לאחר כמה שבועות של הפעלה.
מדיניות התראות וארטיפקטים למסירה לצוות
גילוי אנומליות מוגדר עובד בדיוק עד לרגע שבו הספים והמסלולים שלו מובנים למי שיוצא לתורנות. לכן יחד עם הקונפיגורציה אנחנו מוסרים תיאור שירותים, שיוך בעלים וכללים שלפיהם ההתראה מגיעה לאדם הנכון, ולא לערוץ כללי. להלן — סט שנשאר אצל הלקוח לאחר ההטמעה.
- קטלוג שירותים עם בעלים ותורנים: עבור כל אחד — קריטיות, מערכות תלויות, אחראי ומחליף.
- מפת הגדרות גילוי: אילו מטריקות ואירועים נמצאים במעקב, חלונות השוואה, רגישות, חריגים ידניים והצדקה לכל סטייה מקו הבסיס.
- כללי ניתוב התראות: חלוקה לפי עדיפויות, תנאי הסלמה, ערוצי התראה, הגבלות על התראות לילה.
- תרשים תלויות שירותים — כדי שבתקלה יראו מיד מה המקור ומה התוצאה.
- נוהל תגובה: מי עושה מה בדקות הראשונות, מתי מגייסים פיתוח, מתי מופעל שחזור אוטומטי.
- תיעוד ניטור: אילו מסלולים מכוסים בבדיקות, היכן יש פערים מודעים ומדוע.
- יומן שינויים של ספים עם תאריך, מחבר וסיבת עריכה — אחרת בעוד חודש איש לא יסביר מאין הגיע הערך הנוכחי.
- הוראה להוספת שירות חדש למעקב: תבנית, סדר שיוך בעלים, בדיקת מסלול.
אנחנו מבצעים מסירה יחד עם צוות הלקוח: מנתחים תקרית אמיתית אחת על הנתונים שלהם, מציגים כל ארטיפקט ומתעדים מה נותר להשלים. תארו את המשימה — נחזור עם הערכה ותוכנית, כולל הרכב החבילה הזו עבור התשתית שלכם.
מקרה בוחן: זמן תגובה לדגרדציה לפני ואחרי
הלקוח הגיע עם תמונה אופיינית: ההתראות מוגדרות לפי ספים סטטיים, והן גם מרעישות וגם מחמיצות. הספים הוגדרו ידנית לעומסי שיא, לכן בלילה כל תנודה הפעילה התראה, ואילו עלייה הדרגתית בהשהיות במשך חצי שעה לא חצתה את הגבול ונשארה בלתי מורגשת עד לפניות משתמשים.
מה שינו
הסרנו ספים סטטיים ממטריקות שיש להן עונתיות יומית ושבועית — השהיית תגובה, שיעור שגיאות, רוויה של תורים — והזנו אותן ל-Datadog Watchdog כפרופילי נורמה לדוגמה. ספים השארנו רק כרשת ביטחון ברמה העליונה. בנפרד ניתחנו התראות שאיש לא קרא: חלקן כיבינו, חלקן העברנו לסיכום עם חלון המתנה.
| מטריקה | לפני | אחרי |
|---|---|---|
| זמן גילוי ממוצע של דגרדציה | 18 דקות | 4 דקות |
| שיעור התראות שווא | 58% | 12% |
| דגרדציות שהוחמצו ברבעון | 7 | 1, עם סיבה ידועה |
| תקלות שהתגלו לפני פניית משתמשים | 41% | 88% |
האפקט נשען לא על ההגדרה עצמה, אלא על הניתוח: כל התראת שווא נותחה פעם בשבוע, ואז או דייקו את הפרופיל, או הסירו את המטריקה מהמעקב. כעבור חודשיים ההחמצות ירדו לאפס תוך שמירה על רגישות — סטיות של 15–20% מהנורמה נתפסות, ושיאים עונתיים כבר לא מעירים את התורן. זה המקרה שבו העבודה נמדדת לא במספר הכללים שהוגדרו, אלא במהירות שבה רואים את הדגרדציה לפני המשתמש.
מה לעשות אם הניטור כבר פרוס אבל מרעיש
אם התורן קודם כול משתיק את ערוץ ההתראות, הבעיה אינה בניטור אלא בכללים: הם נכתבו בשלב ההטמעה «לכל המקרים», וכעת האות מופעל עשרות פעמים במשמרת. המחיר — שעות של ניתוח התראות שווא ונפילה אמיתית שטובעת בזרם הכללי. הגדרת Datadog Watchdog בלי ביקורת כללים נותנת בדיוק את אותו רעש כמו כל כלי אחר.
ביקורת כללים מתחילה בספירה: עבור כל כלל מחשבים תדירות הפעלה, שיעור שווא, קיום בעלים ופעולה קונקרטית של התורן. כלל בלי בעלים והוראה — למחיקה; מה שמופעל יותר מפעם ביום וכמעט תמיד נסגר בלי פעולה, מעבירים להתראה במקום קריאה.
הלאה, סף הרגישות. סף סטטי בערך קבוע יוצר זינוק של שווא בתנודות עומס עונתיות, לכן בונים קו בסיס לפי יממה ושבוע, וההפעלה — לפי סטייה ממנו. אותות קשורים על שירות אחד אוספים לתקרית אחת עם רמת חשיבות: נפילה אחת לא צריכה להעיר את התורן חמש פעמים.
השתקת התראות נשארת, אבל מנוהלת: חלון שקט בזמן עבודות מתוכננות עם מועד תפוגה מחייב ורישום ביומן. השתקה «ליתר ביטחון» בלי מועד הופכת לתקלה סמויה, לכן אפשרות כזו לא צריכה להיות במערכת.
האמון באותות חוזר לפי מדד: שיעור ההתראות שהתורן ביצע בהן פעולה עולה מעל שמונה מתוך עשר. אז מפסיקים להשתיק את הערוץ, זמן התגובה יורד, וניתוח השווא יוצא מהמשמרת לרטרוספקטיבה. אנומליה שוב משמעה תקרית, ולא רקע.
ספקות טכניים: רגישות, רעש, כיסוי
ספקות הנדסיים סביב גילוי אנומליות אוטומטי מצטמצמים לשלוש שאלות: האם נדרש תיוג מוקדם של ההיסטוריה, כיצד להפריד דגרדציה אמיתית מתנודת עומס והאם אפשר לצמצם את הכיסוי לשירותים בודדים. להלן — תשובות קצרות שאיתן אנחנו מגיעים לדיון על המשימה.
האם נדרש תיוג היסטורי?
לא, אין צורך לתייג ידנית תקופות «תקינות» ו«חירום». קו הבסיס נבנה לפי התנהגות מצטברת של מטריקות תוך התחשבות בעונתיות יומית ושבועית — תנודות תעבורה שגרתיות מפסיקות להיראות כאנומליה כבר אחרי כמה מחזורי תצפית. תיוגים ידניים נשארים כהבהרה: כדאי לסמן עבודות מתוכננות כדי שלא ייכנסו ללמידה כתקן של נורמה.
איך מפרידים בין דגרדציות לתנודות עומס?
הסטייה נחשבת לא מהערך המוחלט, אלא מהתחזית לשעה מסוימת וליום מסוים בשבוע. עלייה בבקשות בזמן שהשהיה ושיעור השגיאות אינם משתנים אינה נחשבת לאנומליה — העומס גדל, ולא הכשל. האות מופעל כאשר מדדים קשורים מתפצלים: זמן התגובה והשגיאות עולים בזמן שהתפוקה יורדת. הגדרת רגישות היא סף הסטייה ומשך מינימלי: פליטה קצרה של מרווח אחד-שניים נחתכת, סחיפה יציבה עוברת.
האם אפשר להגביל את הכיסוי לשירותים בודדים?
כן. הגילוי מופעל ומכובה לפי שירותים וסוגי אותות, לכן במעקב נשארים אלה שיש להם בעלים ותגובה ברורה להתראה. השאר מועברים למצב איסוף נתונים בלי התראות: התמונה נאספת, אבל לא מפריעים לתורן. צמצום הכיסוי מסיר רעש באופן אמין יותר מכיוונון ספים, ונעשה במעבר הראשון.
נדון במשימה: ממה מתחילה ההטמעה
ההטמעה מתחילה לא בגישות לפאנל, אלא בשיחה על איך בנוי המערך שלכם: בלי זה כל הגדרה הופכת לניחוש. די לנו בחצי שעה של שיחה וברשימת שירותים כדי להבין את היקף העבודה ואת סדר החיבור — מה ניקח בשלב הראשון ומה סביר לדחות.
מה יידרש מכם:
- רשימת שירותים וסביבות שצריך לעקוב אחריהם, והקשרים ביניהם;
- מקורות נתונים: סוכנים על מארחים, מייצאים של מטריקות, אינטגרציות עם ענן ותורים;
- איך מוגדרות כעת ההתראות ומי מגיב להפעלות מחוץ לשעות העבודה;
- ספים פעילים ומקומות שבהם כבר נתפסו התראות שווא;
- מגבלות: מערכות שאסור לגעת בהן, וחלונות מותרים לשינויים;
- מי מצדכם מתאם החלטות ומאשר את התוצאה.
בשיחה נבהיר כמה שירותים ייכנסו למערך הראשון, אילו מטריקות נחשיב כעוגן ואיך להפריד בין תנודות עומס עונתיות לסטיות אמיתיות.
לאחר מכן נחזור עם תוכנית עבודה: שלבים, סדר הפעלת Datadog Watchdog במצב תצפית לפני מעבר להתראות, נקודות שחזור וסימנים שלפיהם נחשיב שאנומליות נתפסות, והרעש מהתראות שווא פחת.
השלב הבא — תארו את המשימה ושלחו את מה שכבר קיים במערך. נחזור עם הערכת היקף ותוכנית עבודה.