הגדרת Yandex Monitoring: מדוע התראות מגיעות באיחור
מדדים נאספים, לוחות מחוונים נפתחים, כללי התראה מוגדרים — אך הראשון שמדווח על תקלה הוא המשתמש.
כך נראית התמונה האופיינית כאשר הגדרת Yandex Monitoring נעשית באופן פורמלי: איסוף המדדים עובד, אך הדרך מתחילת ההידרדרות ועד לאות נמדדת בעשרות דקות, וכל אותו זמן התקלה מצטברת בתורים, בפעולות שלא הושלמו ובכשלים שלקוחות כבר חוו.
התראות מאוחרות על תקלה הן תוצאה לא של איסוף הנתונים, אלא של הכלל. חלון ממוצע של כמה דקות מחליק את הזינוק, תקופת החישוב מוסיפה עוד אותה כמות, והסף מוגדר על ערך מוחלט, בלי קו בסיס ובלי עונתיות יומית של השירות הספציפי.
מכאן שני אפקטים בבת אחת: האות מגיע כשהמונה כבר עבר את הסימן הקריטי, וחלק מהתנודות יוצר התראות שווא — ובערוץ ההתראות מתחילים להתעלם בהדרגה.
הלאה — סוגי תקלות שאינם נראים כלל. תקלות שירות שהוחמצו נראות בדרך כלל כמדד "ירוק" בזמן הידרדרות אמיתית: התור של משימות רקע גדל, שיעור התגובות המוצלחות בנתיב מסוים יורד, המטפל נתקע, רק מופע אחד מתוך כמה מגיב.
סיבה שנייה — מדדים ויומנים חיים ללא קשר: העלייה במספר השגיאות נראית ברשומות, אך אינה מוזנת למונה, ובאמצעות היומן אי אפשר להבדיל בין תקלה מערכתית לבין הודעות בודדות.
להלן נסביר כיצד זה נסגר: שילוב של מדדים, רשומות יומן וכללים עם חלון נכון, תיוג לפי שירותים וסביבות, וכן הסלמה שלא מותירה תקלת לילה ללא כתובת.
מה משתנה לאחר ההטמעה: גילוי, ניתוח, תורנות
לפני ההטמעה את התקלה מבחין המשתמש: הוא כותב לתמיכה, התמיכה מחפשת את התורן, התורן פותח את המסוף — הזמן עד לגילוי נמדד בעשרות דקות ותלוי במי שהבחין ראשון.
לאחר ההטמעה מדדים נאספים מהאפליקציות, מהצמתים וממאזן העומס, הכללים משווים אותם לקו הבסיס, והאות על הידרדרות מגיע לתורן בתוך דקות — לפני שהבקשות החלו להיכשל.
האפקט השני — רעש. הספים מחושבים לפי אחוזונים, לא לפי ממוצעים, הכלל דורש סטייה יציבה בכמה חלונות רצופים, וכפילויות של אותה תקלה מתמזגות לאירוע אחד. שיעור התראות השווא יורד ממחצית לאחוזים בודדים, וערוץ התורנות מפסיק להיות מוזנח.
הנראות של השירותים מתלכדת למעגל אחד: מדדים, יומנים ועקבות מקושרים באמצעות מזהה בקשה משותף, ולכל שירות — לוח עם תלויות ושהיות. ב-Yandex Monitoring נמצאים המדדים והכללים, ולצידם — יומני האפליקציות והצמתים, ולכן הדרך מהכלל שהופעל ועד לבקשה הספציפית אורכת דקות.
ניתוח אירוע לפי יומנים מפסיק להיות ארכיאולוגיה: הרשומות מובנות, החיפוש מתבצע לפי שדות — קוד תגובה, נתיב, מזהה בקשה, משך. שיעור האירועים שבהם ההקשר מוכן ברגע ההפעלה עולה משליש לרוב.
התורנות הופכת לצפויה: במקום שטף רעש המהנדס מקבל תיאור של הבעיה, גרף וקישור ליומנים, ולאחר סגירת האירוע הכלל משופר — התקלה הבאה מאותו סוג נתפסת מוקדם יותר.
אפשרויות לאיסוף טלמטריה: מה מתאים למעגל שלכם
אופן איסוף הטלמטריה נבחר לא לפי נוחות, אלא לפי מהיכן פיזית ניתן לקחת את הנתונים. אל Yandex Monitoring ו-Cloud Logging הם מגיעים בארבעה דרכים: סוכן מהצומת, ממשק תכנותי של הספק, פרסום מהאפליקציה עצמה ושילוב של דרכים אלה.
במעגל אחד השיטות обычно משולבות, ולכן אין צורך לבחור "אחת להכל" — חשוב יותר להבין את המגבלות של כל אחת. להלן השוואה לפי תנאי התאמה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| איסוף מדדים באמצעות סוכן | מכונות וירטואליות ואשכולות: מדדי צומת, דיסק, רשת, מונים מקבצי מערכת | הסוכן מותקן על כל צומת, דורש הרשאות, אינו עובד בסביבות נטולות שרת |
| איסוף יומנים ללא סוכן | שירותים מנוהלים ללא גישה למארח: מאזן עומס, בסיס נתונים, אחסון אובייקטים | זמינים רק מקורות שהספק מספק; אין מדדי אפליקציה |
| ייצוא מדדים מהאפליקציה | יש צורך במדדי לוגיקה עסקית: זמן פעולות, תורים, פגיעות במטמון | דורש שינויים בקוד; לא יציג מיצוי משאבי הצומת |
| סכימת איסוף טלמטריה היברידית | פרודקשן עם עומס הטרוגני — אפשרות בסיסית לרוב המעגלים | נדרשים שמות תגיות אחידים ותקופות אחסון, אחרת אי אפשר לאחד את הנתונים בגרף אחד |
שלבי ההטמעה: מביקורת מקורות ועד מסירה לתפעול
ניטור לא מתחיל בהתקנת סוכן — הוא מתחיל במיפוי של מה בכלל ניתן לאסוף, ובמענה לשאלה אילו אותות באמת מעידים על הידרדרות השירות ואילו סתם מרעישים. סדר העבודה שלנו נשאר אחיד, ורק סט המקורות ומצבי האיסוף משתנים.
- ביקורת מקורות טלמטריה. עוברים על שירותים, בסיסי נתונים, תורים, מאזני עומס, מכולות ומכונות וירטואליות; מתעדים היכן מדדים ויומנים כבר מסופקים כחלק מהתקן, היכן יש צורך בייצואן, והיכן יהיה צורך להוסיף נקודות איסוף בקוד.
- סכימת איסוף מדדים ויומנים. מפרידים בין מה שנאסף בסקר לבין מה שנשלח מהאפליקציה, אילו תגיות נדרשות לפילוח לפי שירות, סביבה ותפקיד צומת, קובעים תקופות אחסון וצבירת מונים.
- פריסת איסוף ומסלולים. מרימים סוכנים, מקלטי יומנים וכללי ניתוב: חיפוש חם בנפרד מאחסון ארוך טווח, זרמי דיבאג נחתכים בכניסה כדי שהנפח לא יגדל ללא בקרה.
- הגדרת ספי התראות. את הספים מחשבים מפרופיל עומס רגיל, לא "בעין": שגיאות, השהיה, רוויה של דיסק וזיכרון, אי-זמינות. לאחר מכן — מסלולי תורנויות, קיבוץ ודיכוי כפילויות, כדי שהתורן יקבל שיחה אחת על אירוע.
- קישור מדדים ליומנים ולוחות. מהגרף עוברים לחלון יומנים ספציפי לפי זמן ותגיות — הניתוח מתבצע ללא הצלבה ידנית של ייצואים ממערכות שונות.
- בדיקה בתרחישי חירום. מכבים צומת, ממלאים דיסק, מפילים תלות, מוסיפים השהיה. בודקים אם האות הופעל, האם הגיע לתורן הנכון והאם היו מספיק נתונים כדי להבין את הסיבה.
- מסירה לתפעול. הוראות לתגובות טיפוסיות, תקנון תורנויות, כללים לבחינה מחודשת של ספים והדרכת הצוות.
לאחר המסירה המעגל ממשיך לחיות בלעדינו: צוות הלקוח מוסיף שירותים חדשים לסכימת האיסוף בעצמו, לפי כללי התיוג והניתוב שתוארו.
מה נשאר במעגל שלכם: ארטיפקטים ותקנונים
הפריסה לא מסתיימת בסימני וי ירוקים בממשק, אלא בכך שצוות הלקוח יכול בעצמו להרים את המעגל, להסביר למהנדס התורן מדוע הופעלה התראה, ולהוסיף שירות חדש לניטור בלי מעורבותנו.
לכן את כל מה שאנו מגדירים אנו מוסרים כקבצים וטקסטים במאגר ובבסיס הידע שלכם — עם היסטוריית שינויים ובעלים ברור לכל ארטיפקט.
- תצורות איסוף. תיאור מקורות מדדים ויומנים, כללי פענוח שורות, תקופת אחסון ורוטציה, שיוך שירותים לפרויקטים ולסביבות — כקבצים שמונחים לצד הקוד ועוברים סקירה כשינוי רגיל.
- תצורות התראות. ספים, חלונות מיצוע, קיבוץ אותות קשורים, ניתוב לפי ערוצים וכללי דיכוי כפילויות: ברור איזה תנאי נחשב לאירוע ואיזה לרקע.
- מדיניות גישה ליומנים. תפקידים לפי פרויקטים וצוותים, הפרדה של שדות רגישים, הסוואת נתונים אישיים בכניסה ותקופת אחסונם — עם נימוק מדוע נבחר גבול נראות כזה.
- סכימת זרמי טלמטריה. מנקודת האיסוף ועד ללוח ולמקבל ההתראה, עם צווארי בקבוק מסומנים והתנהגות בעת אי-זמינות של חוליה ביניים.
- לוחות לפי שירותים. ערכות גרפים עם ספים, משויכות לבעלים: התורן רואה את מצב השירות במסך אחד, ולא מרכיב תמונה מעשרה שאילתות.
- תקנון תורנות. לוח זמנים, תחומי אחריות, סדר הסלמה, זמן תגובה לפי מחלקות אירועים והכלל שלפיו האות עובר הלאה מהקו הראשון.
- הוראות לניתוח אירועים. סדר פעולות שלב אחר שלב, תרחישים טיפוסיים עם שאילתות מוכנות למדדים וליומנים, מקומות לתיעוד המסקנה וניתוח לאחר סגירה.
- מסירה לתפעול. הרשאות עם הפרדת זכויות, בדיקות קבלה לתקלת צומת, הדרכה קצרה למשמרת התורנות ורשימת משימות שנשארות בצד שלכם.
כל האמור — לא נספח לדוח, אלא מעגל עבודה: אפשר להעביר אותו למשמרת חדשה, לבדוק בתרגילים ולהרחיב ככל שהשירותים גדלים. תארו את המשימה — נחזור עם הערכה ותוכנית באיזה סדר זה נפרס בתשתית שלכם.
מקרה בוחן: כיצד קיצרנו את הזמן עד לגילוי תקלה
לפני: את התקלה גילו לפי תלונות
אצל הלקוח — שירות עם זרם בקשות קבוע, אך את זינוק השגיאות הבחינו לא התורנים אלא המשתמשים. המהנדס פתח יומנים לפי זמן התלונה והצליב ידנית רשומות מכמה שירותים: הזמן עד לגילוי הגיע ל-40–50 דקות, והסיבה לעיתים קרובות נותרה לא ברורה, משום שמדדים כלל לא נאספו. שחזורים ארוכים ותקלות חוזרות מאותה סיבה היו נורמה.
מה הוקם
הגדרנו איסוף מדדים של האפליקציה והצמתים ב-Yandex Monitoring, ואת היומנים ריכזנו ב-Cloud Logging עם שדות בקשה ועקבה אחידים. התקבל לוח ניטור אחד: שיעור התגובות השגויות, השהיה בקריאות איטיות, עומק התורים, כשלים של תלויות חיצוניות — לצד גרף הגרסאות והעומס. התראות תלינו על סימפטומים, ולא על כל צומת לא תקין, כדי שהתורן יראה אות אחד במקום מפולת.
מדדים לפני ואחרי
גילוי — 3–5 דקות במקום 40: האות מגיע מהמערכת, לא מהתמיכה. שיעור האירועים שהתגלו לפני פניות משתמשים עלה לתשעה מתוך עשרה. ניתוח הסיבה הצטמצם משעות לדקות — לפי העקבה רואים איזו קריאה ואיזו גרסה גרמו לירידה. תקלות חוזרות כמעט נעלמו: לאחר האות הראשון הסף וכלל ההתראה מתחדדים, ואותה סיטואציה נתפסת מוקדם יותר.
במה שונה התראה מלוח ניטור ומה להטמיע ראשון
לוח ניטור והתראה — כלים שונים, ובלבול ביניהם יקר. הלוח עונה על השאלה "מה קורה ולמה", ההתראה — על השאלה "מי ומתי צריך להתערב". הלוח פסיבי: הוא ממתין שמישהו יסתכל עליו, ובלילה אין מי שיסתכל.
לכן סדר ההטמעה של נראות ואיסוף טלמטריה מתחיל לא בגרפים. תחילה מדדים ויומנים — בלעדיהם אין מה להשוות. לאחר מכן 3–5 כללים על הסימפטום הבולט ביותר למשתמש: עלייה בשיעור השגיאות, ירידה בזמינות, זמן תגובה גבוה מהרגיל. ורק אחרי זה — לוחות שהופכים את ניתוח האירוע למהיר.
ההתראה נבנית על סימפטום, לא על סיבה. המשתמש מבחין בעלייה בזמן התגובה, לא בדיסק מלא — לכן הכלל מוגדר על השהיה ושיעור שגיאות, עם חלון אישור, כדי שזינוק בודד לא יעיר את התורן לשווא.
יומנים נשמרים לצד מדדים, באותו מעגל Yandex Monitoring: לפי האות מיד רואים איזה צומת או גרסה היו המקור. את הסיבות מנתחים כבר לפי הלוח.
שתי הקיצוניות מסוכנות. לוחות בלי התראות יוצרים תחושת שליטה: הגרפים יפים, אבל על התקלה אתם לומדים מהלקוח. התראות בלי לוחות נותנות אפקט הפוך — התורן מקבל אות, אך מחפש את המקור בעיוורון, והשחזור מתארך.
קריטריון המוכנות של המעגל פשוט: לכל תרחיש קריטי יש גם כלל וגם לוח, והבדיקה — תקלה מתוכננת שמביאה להתראה לאדם הנכון. כדאי להתחיל משירות אחד ולהרחיב את המעגל ככל שהקודם מפסיק להרעיש.
ספקות טכניים לפני ההתחלה: עונים לגופו של עניין
לפני ההתחלה עולים אותם שאלות — מהתשובות תלוי היקף העבודה ואיך המערכת תתנהג בעוד חצי שנה. להלן תשובות קצרות לגופו של עניין.
האם צריך סוכן על השרתים?
עבור מדדים — כן, סוכן קל מותקן על המארחים; עבור חלק משירותי הענן די באינטגרציה מובנית. יומנים נאספים על ידי סוכן מהדיסק או נשלחים מהאפליקציה ישירות — בוחרים לפי פרופיל העומס.
כבר פרוס אצלנו איסוף של צד שלישי. להעתיק הכל מחדש?
לא. מעגל פעיל נשאר מקור, אנחנו מחברים אותו ל-Yandex Monitoring ומעבירים בהדרגה את כללי הבדיקה. את האיסוף הקודם לא נוגעים עד לרגע ההוצאה משימוש — חזרה אליו אורכת דקות.
היכן וכמה זמן לאחסן יומנים?
התקופה נקבעת לפי מדיניות אחסון לפי סוגי אירועים: תפעוליים נשמרים לזמן קצר יותר, ביקורת ואירועי גישה — לזמן ארוך יותר. רוטציה, דחיסה והעברה לאחסון קר מוגדרות מיד, כדי שהנפח לא יגדל ללא בקרה.
איך להסיר רעש בהתראות?
את הסף מחשבים לפי סטייה מקו הבסיס, ולא כסף סטטי, הפעלות קשורות מקובצות להתראה אחת וממוינות לפי חומרה. התורן מקבל בודדות של הודעות במשמרת במקום מאות.
מי מתחזק את המערכת לאחר המסירה?
אנחנו מוסרים תצורות, סכימות ותקנון תורנות; כללים מתוארים כקוד ומנוהלים בגרסאות. בהמשך אותם מובילה הקבוצה שלכם — או שאנחנו נשארים בתחזוקה לפי מצב מוסכם.
נדון במשימה — נחזור עם הערכה ותוכנית עבודה
כדי שהשיחה תיערך במפגש אחד ותיתן מיד הערכה, ולא סדרה של שאלות הבהרה, כדאי להכין נתוני פתיחה על התשתית. להלן צ'ק-ליסט לפני ההתחלה: הוא מכסה את מה שבאמת משפיע על היקף העבודה בהגדרת Yandex Monitoring ו-Cloud Logging.
- רשימת שירותים ומעגלים שדרוש עליהם שליטה: פרודקשן, סביבת טרום-פרודקשן, סגמנטים מבודדים.
- מה כבר נאסף: מקורות מדדים ויומנים, לאן הם נכתבים, במה נאספים — סוכנים בהתאמה אישית או אמצעי הפלטפורמה הסטנדרטיים.
- תרחישים קריטיים: אילו תקלות צריכות להעיר את התורן לפני שהמשתמש יכתוב עליהן, ולפי אילו סימנים לתפוס אותן.
- הרשאות ותפקידים: חשבונות שירות, מי מהצוות רואה מה, האם נדרש בידוד בין מחלקות.
- דרישות אחסון: תוחלת חיים של יומנים ומדדים, האם יש צורך להחזיק נתונים בתוך המעגל.
- נוהג תורנויות נוכחי: איך מגיעות התראות ולאן — דואר, מסרים מיידיים, טלפון של התורן.
להלן הסדר פשוט. דנים במשימת הנראות: אילו אותות חשובים, מה כבר מוגדר, היכן צווארי בקבוק. חוזרים עם הערכה ותוכנית עבודה — לפי שלבים, עם הרכב לוחות הניטור, כללי ההתראה ולוחות זמנים ברורים. לאחר הסכמה על ההיקף מתחילים: תחילה איסוף בסיסי של מדדים ויומנים, אחר כך התראות וטיפול בהתראות שווא.