Azure Monitor: היכן נשברת היכולת לצפות במערכת בפרודקשן
רוב ההטמעות של Azure Monitor נשברות לא בגלל היעדר כלי, אלא בגלל האופן שבו הוא נבנה. סוכנים מותקנים על חלק מהמכונות, הגדרות אבחון מופעלות באופן סלקטיבי לפי שירותים, חלק מהמטריקות עוברות במוני פלטפורמה, וחלק — באמצעות קולט עצמאי.
לשאלה «מה קרה בליל יום רביעי» אין תשובה אחודה: הנתונים מפוזרים בין כמה סביבות עבודה (workspaces) של Log Analytics עם עומק שמירה שונה והרשאות גישה שונות.
צוואר הבקבוק השני הוא הזמן. מכונות וירטואליות, אשכולות ובסיסי נתונים מחזירים רשומות ב-UTC, האפליקציה כותבת באזור זמן מקומי, וחלק מהשירותים — בכלל באזור זמן משל עצמם.
בעת ניתוח תקרית, איסוף המטריקות ואיסוף הלוגים מפסיקים להתלכד: המתאם (correlation) נסחף בשעות, והמהנדס מבזבז זמן על חשבון במקום על מציאת הסיבה.
השלישי — ההתראות. הסף נקבע לפי ממוצע על פני חלון ארוך, כלל האגרגציה בולע פיק קצר, וההתראה נשלחת לערוץ שאף אחד לא תורן בו. ההפעלה מגיעה רק לאחר שהלקוחות כבר שמו לב לתקלה: ה-observability קיים רשמית, אבל זיהוי התקריות לא עובד.
את זה מתקנים לא עם דשבורד חדש, אלא עם מבנה: סביבת עבודה אחודה, כללי איסוף נתונים עם מערך מקורות מוגדר, אזורי זמן מתואמים, ספים לפי זנב ההתפלגות וניתוב התראות לפי תורנויות. נפרט כיצד זה נסגר.
מה משתנה לאחר הגדרת איסוף מטריקות מקצה לקצה
בעבר התמונה הורכבה מאותות מפוזרים: מטריקות של מכונות במקום אחד, לוגים של האפליקציה במקום אחר, שגיאות בכניסה — רק בלוג של מאזן העומסים. הבעיה התגלתה רק כשהמשתמש הבחין בה, והניתוח החל בשאלה «מה בעצם נשבר». זהו התרחיש היקר ביותר: בזמן שאוספים את הנתונים חלק-חלק, חלון התקלה גדל.
מעגל תצפית אחוד מסיר את הפיצול הזה. מטריקות, לוגים וטראסים מגיעים למאגר משותף ומקושרים לפי אותם ממדים — מזהה בקשה, שם השירות, גרסת הבילד, מופע הצומת. Azure Monitor פועל כאן כנקודת איסוף: המקורות מתחברים באופן מתואם, ולא כאוסף של סוכנים נפרדים.
זמן הזיהוי משתנה ראשון. הספים נקבעים לא לפי עומס המעבד, אלא לפי סימני דעיכה של השירות — שיעור השגיאות, זמן התגובה בנתיבים משמעותיים, אורך התור. האות מגיע לפני שהמשתמש מבחין בתקלה, והקטגוריה «נודע לנו מהמשתמש» מפסיקה להיות המקור העיקרי לפניות.
ניתוח התקרית מואץ מאותה סיבה. טראסינג מקצה לקצה מציג את מסלול הבקשה דרך השירותים: במקום סקירה עוקבת של חמישה דשבורדים, המהנדס רואה את הקטע שבו עלו הזמן או השגיאות.
הסיבות השורשיות מאומתות בנתונים — השוואת מטריקות לפני ואחרי הדיפלוי מבדילה בין רגרסיה של הריליס לבין תקלת רשת או כשל של תלות.
קיים גם אפקט מצטבר: שמירה אחודה של מטריקות ולוגים משאירה את ניתוחי התקריות הקודמות ניתנים לשחזור. תקלות חוזרות נסגרות בכללי ניטור, ולא בסיבות שמתגלות מחדש.
מצבי איסוף נתונים וסוכנים: השוואת אפשרויות
Azure Monitor אוסף טלמטריה בכמה נתיבים בלתי תלויים, והנתיב הנבחר קובע לא רק את מערך השדות, אלא גם את סכמת הטבלאות בסביבת העבודה. טעות כאן יקרה: חלק מהנתונים לא ניתן יהיה להשלים בדיעבד, והחלפת שיטת האיסוף על פארק מכונות פעיל דורשת פריסה מחדש בכל צומת.
ההחלטה מצטמצמת לשלוש נקודות הסתעפות: האם נדרשת גישה מתוך מערכת האורח, האם תעבורה יוצאת ישירה לענן מותרת, והאם קיימים מקורות אירועים עצמאיים. להלן האפשרויות שביניהן באמת בוחרים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סוכן על הצומת | לוגים של המערכת והאפליקציות, מונים, מקורות עצמאיים | ההרחבה מתוחזקת בכל מכונה, נדרשת תעבורה יוצאת, מתעדכנת רק דרך מדיניות |
| איסוף ללא סוכן | לוגים של משאבים ברמת הפלטפורמה, מטריקות של שירותים, ביקורת שינויים | אין נתונים מתוך המערכת, מערך השדות נקבע על ידי הפלטפורמה, לוגים עצמאיים אינם זמינים |
| שער מתווך | סגמנטים סגורים ללא יציאה ישירה החוצה, זרימה אחת עבור מכונות רבות | השער הוא נקודת כשל בודדת, מוגבל ברוחב פס, חלק מסוגי הנתונים אינם עוברים דרכו |
| מחבר חיצוני | התקני רשת ומערכות צד שלישי שמחזירים אירועים כזרימה | נדרשת נרמול פורמט, ההשהיה גבוהה יותר, הכול תלוי ביציבות הערוץ |
האפשרויות אינן סותרות זו את זו: במעגל אחד פועלות בדרך כלל שתיים-שלוש במקביל. לפני הפריסה אנחנו בודקים על צומת פיילוט אילו שדות מגיעים ובאיזו השהיה.
שלבי ההטמעה: מביקורת מקורות ועד מסירה
העבודה מתבצעת בסדר קפדני: תחילה מתארים את מה שכבר קיים, לאחר מכן מתכננים את מסלולי הנתונים, ורק אחר כך מפעילים את ההתראות. סדר הפוך מייצר רעש בלוגים, הפעלות שווא ודשבורדים שאיש אינו משתמש בהם.
- ביקורת תשתית ומקורות. עוברים על המנויים, המכונות הווירטואליות, האשכולות, בסיסי הנתונים והשירותים היישומיים; מסמנים מי כבר מחזיר מטריקות ולוגים, מי שותק, והיכן הנתונים משוכפלים.
- תרשים זרימות נתונים. עבור כל מקור קובעים סביבת עבודה, תקופת שמירה, הפרדה לפי סביבות וצוותים, ומעריכים את נפח ההגעה היומי — המאגר לא צריך לגדול ללא בקרה.
- הגדרת האיסוף. מחברים סוכנים והגדרות אבחון, קובעים כללי שמות אחודים לטבלאות ולתגים, כך שהשאילתות יעבדו באופן זהה בסביבת הבדיקות ובסביבת הפרודקשן.
- כללי התראה. את הספים מחשבים מקו הבסיס בפועל, ולא לפי הערכה: מגדירים דחיפות, ניתוב לתורנים ודיכוי כפילויות בזמן עבודות מתוכננות.
- בדיקה על תקרית תרגול. בסביבת הבדיקות מפילים שירות בכוונה ובוחנים את כל המסלול: האם התנאי הופעל, תוך כמה דקות הגיע האות, והאם הגיע לתורן הנכון.
- מסירה לתפעול. דשבורדים, שאילתות שמורות, נוהל לבחינה מחודשת של ספים והוראות לחיבור מקורות חדשים; מכשירים את המשמרת ונשארים בקשר בתקופת הליווי.
מארז האספקה: קונפיגורציות, תרשימים, נהלים
מארז האספקה אינו תיקייה עם קבצים, אלא מערך של ארטיפקטים שלפיהם אפשר להעביר את מעגל Azure Monitor לצוות אחר או לשחזר אותו בסביבה חדשה. כל מסמך קשור לפעולה מוגדרת: לפרוס, לבדוק, לחזור אחורה, לנתח תקרית.
להלן מה בדיוק נשאר בידיכם לאחר העלייה לאוויר.
- קובצי קונפיגורציה — תיאורים דקלרטיביים של סביבות עבודה, כללי איסוף ותקופות שמירה של טלמטריה; פריסה חוזרת בסביבה חדשה מתבצעת ללא הגדרה ידנית.
- תרשים זרימות הטלמטריה — אילו מקורות מחזירים מה, באילו מסלולים עוברים הנתונים, היכן הם מסוננים, היכן נשמרים וכמה זמן חי כל סוג של רשומה.
- מדיניות גישה — למי ובאיזו רמה נראים הלוגים, מי רשאי לשנות כללים ולמחוק נתונים; מעוגן בתפקידים, ולא בהסכמות בעל פה.
- תפקידי המהנדסים — מטריצת «תפקיד / תחום אחריות / הרשאות נדרשות», שלפיה מכניסים אדם חדש למעגל בתוך יום, ולא בתוך חודש.
- תיאור כללי ההתראה — תנאים, ספים, נמענים ורמות דחיפות; בנפרד מפורט אילו התראות אינן נשלחות במכוון, כדי שרעש לא יעיר את התורן.
- נוהל תורנויות — לוח זמנים, סדר הסלמה, זמן תגובה לפי רמות קריטיות ופעולות חובה לפני העברת משמרת.
- תיעוד — הוראות לפעולות שגרתיות: לחבר שירות חדש, לשנות כלל, לנתח תקרית, לחזור לקונפיגורציה קודמת.
מקרה בוחן: כיצד קיצרנו את זמן זיהוי התקלות
הלקוח הגיע עם מעגל תצפית מפוזר: מדדי המכונות הווירטואליות — בדשבורד אחד, לוגים של האפליקציות — במאגר נפרד, אירועי תורים ומאזן העומסים — בתיבת המייל של התורן. בעת תקלה המהנדס השווה ידנית שלושה מקורות, ועד להבנה מה בדיוק דעך חלפו 40-60 דקות.
מה שינינו
כינסנו הכול למעגל אחוד ב-Azure Monitor וב-Log Analytics: סביבת עבודה אחת ללוגים, איסוף מדדים מצמתים, אפליקציות ושירותי רשת, כללי התראה הקשורים לסימפטומים ולא למונים בודדים. את הספים קבענו לפי סטייה מקו הבסיס — התראות הלילה הפסיקו להעיר את הצוות בגלל פיקי עומס שגרתיים.
הוספנו workbooks עם חתכים מוכנים לפי סוגי תקלות וניתוב תורנויות: ההודעה מגיעה למי שאחראי על השירות, יחד עם קישור לחתך הרלוונטי. ניתוח התקרית, במקום הרכבת נתונים מאפס, הפך לבדיקה של כרונולוגיה מוכנה — מהסטייה הראשונה ועד ההתאוששות.
התוצאה: זמן הזיהוי הממוצע ירד מ-45 דקות ל-5-7, ניתוח ידני אורך כ-20 דקות במקום שעתיים, ושיעור התקלות החוזרות ירד בערך פי שלושה — כל ניתוח הסתיים בכלל שתופס מראש את אותו סוג תקלה.
במה שונה Azure Monitor מ-Log Analytics?
Azure Monitor הוא פלטפורמת טלמטריה: אוסף נתונים מכל המשאבים במנוי, שומר, מעבד ומפיץ אותות. Log Analytics הוא חלק ממנה: סביבת עבודה שבה מאוחסנים לוגי האירועים ומבוצעות שאילתות על הלוגים.
הגבול עובר לא לפי כלים, אלא לפי סוג הנתונים: מטריקות מספריות וטקסט של אירועים נשמרים בנפרד, עם תקופת חיים שונה ומהירות תגובה שונה.
מטריקות הן טורים מספריים בצעד קבוע: עומס הצומת, מספר החיבורים, עומק התור. אותן כותבת הפלטפורמה עצמה, הן מוחזרות תוך שניות ומשמשות בסיס לכללי התראה ולגרפים. לוגי אירועים הם רשומות על מה שקרה, עם סכמה חופשית; יש לנתב אותם במפורש לסביבת העבודה דרך קטגוריות אבחון.
| שכבה | על מה אחראית | מתי להשתמש |
|---|---|---|
| מטריקות | טורים מספריים לפי משאבים, אותות מהירים | תגובה לסף: כשל צומת, עלייה בהשהיה |
| לוגי אירועים | רשומות חופשיות בסביבת העבודה | ניתוח תקרית, ביקורת, מתאם בין שירותים |
| שאילתות על לוגים | שליפה וצירוף אירועים | סיכומים, מציאת סיבה, שמירה ארוכת טווח |
טעות נפוצה היא לייצא מטריקות לסביבת העבודה «ליתר ביטחון», ובמקביל לכתוב ללוגים את מה שכבר קיים שם. נפח הקליטה גדל פי שניים, אבל ההתראות מבוססות המטריקות בכל זאת נשארות מהירות ואמינות יותר. הכלל פשוט: מונים — למטריקות, הקשר וטקסט — ללוגים.
אזורי האחריות בממשק מתחלקים כך: על המטריקה אחראי המשאב עצמו, על איסופה — הגדרות האבחון, ועל הלוגים — סביבת העבודה עם תקופת השמירה, ההרשאות ומערך הקטגוריות שלה. כשהחלוקה הזו מעוגנת בתיעוד, התורן יודע היכן להסתכל על המספר והיכן על הסיבה.
ספקות טכניים ומגבלות
ההסתייגויות מהטמעת ניטור ב-Azure הן בדרך כלל אותן הסתייגויות: האם יהיה צורך לבנות מחדש מאגרי לוגים שכבר פועלים, כיצד לרסן את גידול הנפח והאם להרשאות הצוות יספיקו. להלן תשובות ישירות, שמהן אנחנו מתחילים את ניתוח המשימה.
אנחנו כבר אוספים לוגים בדרך אחרת — יהיה צורך לכתוב הכול מחדש?
האיסוף מוגדר לצד המקור הקיים: הנתונים עוברים לסביבת העבודה, והקולטים הישנים ממשיכים לפעול עד שהדשבורדים החדשים יתחילו לספק את אותה תמונה. מעבירים בהדרגה — תחילה מעגל אחד, אחר כך את השאר.
כיצד להגביל את נפח שמירת הלוגים?
תקופת השמירה נקבעת לכל טבלה בנפרד: לוגי אבחון נשמרים לזמן קצר, לוגי אבטחה — לזמן ארוך יותר. כללי שליפה בצד המקור חותכים את הרעש לפני הכתיבה, ולכן לא הנפח גדל, אלא שיעור האירועים המועילים.
האם צריך לשנות את קוד האפליקציה?
עבור מטריקות בסיסיות — לא, הן נלקחות מהפלטפורמה. מונים עצמאיים מתווספים בספרייה תקנית, בלי לכתוב מחדש את הלוגיקה ובלי לעצור שירותים — מפרסים יחד עם הריליס הקרוב.
כיצד להפריד גישה לפי תפקידים?
ההרשאות ניתנות ברמת המנוי, קבוצת המשאבים וסביבת העבודה המוגדרת: מפתח רואה את הלוגים של השירות שלו, התורן — רק התראות, וביקורת אינה קוראת נתוני אפליקציות. את החשבונות יוצרים דרך הספרייה הקיימת.
נדון במשימה ונחזור עם תוכנית
שיחה על ניטור הופכת עניינית כשמולה רואים את מצב התשתית הנוכחי. אין צורך להכין דוח — די במה שכבר יש בהישג יד: תרשימים, רשימות, היסטוריית תקלות. אספו זאת לפני הדיון במשימה, ונחזור לא עם שאלות הבהרה, אלא עם תוכנית עבודה והערכת לוחות זמנים.
- רשימת השירותים: מה פועל, מי הבעלים של כל משאב, אילו רכיבים כבר מחזירים מטריקות ל-Azure Monitor ואילו נותרו «קופסה שחורה».
- תרחישים קריטיים: אילו שרשראות (בסיס נתונים, אפליקציה, ממשק חיצוני) נשברות ראשונות, מה נחשב להשבתה בלתי קבילה, ומה יכול לחכות עד הבוקר.
- דרכי ההתראה הנוכחיות: לאן מגיעות ההתראות, מי קורא אותן, לפי אילו ספים הן מופעלות ובאיזו תדירות הן מתבררות כשווא.
- מפת התלויות בין השירותים ונקודות הכשל הידועות — מתאימה אפילו רשימת קשרים מצוירת ביד.
- היסטוריית תקלות קודמות: כיצד הבחינו בבעיה, כמה זמן ארכה ההתאוששות, ומה חסר לאבחון מהיר.
- מגבלות: דרישות לשמירת נתונים, תפקידי גישה, מה אסור לשנות בלי אישור ובאילו חלונות זמן מותר לבצע עבודות.
עם המערך הזה נקבע אילו מטריקות ולוגים לאסוף, כיצד להפריד ספים לפי קריטיות, לאן לנתב התראות וכמה זמן לשמור היסטוריה. תארו את המשימה — נחזור עם תוכנית עבודה, הערכת לוחות זמנים ותחום אחריות ברור בכל שלב.