מדוע Cloud Monitoring ב-GCP לא מציג את סיבת התקלה
תמונה אופיינית: הגרפים ב-Cloud Monitoring מלאים, ההתראות מופעלות, אבל על השאלה "מדוע אצל חלק מהמשתמשים בקשות נופלות" אין תשובה.
המדדים נאספים לפי מופעים וסוגי משאבים, הלוגים נמצאים בנפרד, וקישור בין זינוק בהשהיה לבין בקשה מסוימת, גרסת בנייה או צומת מחייב עבודה ידנית תוך מעבר בין חלונות.
הסיבה אינה היעדר כלים, אלא פיזור המקורות. הנתונים מגיעים מכמה פרויקטים וסביבות, ולמדדים אין סכימת תוויות אחודה — שירות, סביבה, גרסה — ולכן אגרגציות מערבבות בין פרודקשן לסביבת בדיקות. הלוגים נכתבים בפורמט חופשי וללא מזהה בקשה, ולכן נראות התשתית נשענת על חיפוש טקסט ידני.
צוואר בקבוק נפרד בניטור — ספים פורמליים. התראה על עומס מעבד או זיכרון פנוי מופעלת כשהבעיה כבר גלויה למשתמשים, ואינה אומרת דבר על כך שדרך עיבוד כלשהי הידרדרה.
אבחון תקלה דורש מדדים ברמת הבקשה: שיעור שגיאות, השהיות לפי אחוזונים, רוויה של מאגר חיבורים — אחרת יש אות, אבל אין סיבה מאחוריו.
נסביר כיצד זה נסגר: סכימת תוויות אחודה, קישור בין מדדים, לוגים וטראסות לפי מזהה בקשה, התראות לפי סימפטומים עם בעלים ברור ולוח שמסביר בתוך דקה מה בדיוק נשבר.
מה נותנת נראות מקצה לקצה: מדדים, יומנים, התראות
ב-Google Cloud מדדים, יומנים והתראות חיים באותו מעגל: לחלק מהמדדים, רשומת יומן וכלל התראה יש סט תוויות משותף — שירות, סביבה, גרסה. לכן מצב של שירות בודד נאסף במסנן אחד, ולא במעבר בין לוחות מפוזרים. תוויות עוברות בירושה מהמשאב, כך שמופע חדש נכנס לניטור אוטומטית, בלי עריכה ידנית של דשבורדים.
החיבור המרכזי — קורלציה בין יומנים למדדים. הגרף עונה על "מה נשבר": ההשהיה עלתה, שיעור התגובות המוצלחות ירד. לאחר מכן במעבר אחד נפתחים היומנים לאותו פרק זמן ולאותו מסנן — ונראה "למה": חריגות בזמן ההמתנה לתלות חיצונית, שגיאות פענוח, כשלים בכתיבה.
התראות נבנות לפי שירות, לא לפי מכונה בודדת. הכלל מנוסח ברמת מדד איכות — זמינות, השהיה, שיעור שגיאות — ומופעל כאשר היעד של השירות כולו נשרף. זה מסיר את עיקר הקריאות הכוזבות: הפעלה מחדש מתוכננת, סקיילינג אוטומטי וזינוק קצר כבר לא מעירים את התורן.
נראות מקצה לקצה נמדדת בזמן גילוי התקלה. כאשר מדד, יומן והתראה קשורים לאותו שירות, האבחון מתחיל מהקשר מוכן, ולא מחיפוש לפי מארחים. בפועל זה מזיז את הגילוי משעות לדקות ומקצר את הניתוח: מיד רואים איזה שירות נפגע ובאיזו גרסה.
מצבי איסוף מדדים: סוכן, אמצעים מובנים, קולט משלך
שלושת המצבים נבדלים לא בנוחות, אלא במי שאחראי על אספקת הטלמטריה. אמצעים מובנים של Cloud Monitoring שולפים נתונים משירותים מנוהלים בלי להתקין דבר על הצמתים, הסוכן מוסיף עומק לפי מערכת ההפעלה והתהליכים, וקולט משלך נותן שליטה מלאה על הרכב וניתוב הנתונים. הבחירה נקבעת לא לפי "איזה כלי טוב יותר", אלא לפי אילו מגבלות אתם מוכנים לקבל במודע.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אמצעים מובנים | שירותים מנוהלים, מאזני עומס, מסדי נתונים, פלטפורמות קונטיינרים | סט המדדים קבוע, לא ניתן לקבוע תדירות דגימה, אין עומק לפי תהליכים |
| סוכן על צמתים | מכונות וירטואליות, נדרש חתך לפי דיסק, זיכרון, תורי תהליכים | דורש התקנה ועדכון אחידים, תוויות משלו, השהיות בכשל באספקה |
| קולט משלך | מקורות לא סטנדרטיים, כמה סביבות, המרת מדדים בכניסה | תפעול ועדכונים בצד שלכם, סף כניסה גבוה יותר, נדרש בקרת כשלים |
מה מגביל את האיסוף
המגבלה המרכזית בכל שלושת המצבים היא אחת — קרדינליות התוויות. מימד מיותר כמו מזהה בקשה הופך עשרה טורים למיליונים ועושה את השאילתות על ההיסטוריה לאיטיות.
לכן קולט משלך מתקינים לרוב לא לשם האיסוף עצמו, אלא לשם סינון ושינוי שמות תוויות בכניסה, ואת איסוף היומנים מנהלים בזרם נפרד עם כללי שמירה משלו.
סדר היישום: מביקורת ועד מסירת נהלים
שלבי היישום הולכים ברצף: כל צעד הבא נשען על הארטיפקטים של הקודם. אם מדלגים על ספירת מלאי — סכימת איסוף הנתונים תהפוך לאוסף ניחושים, וספי ההתראות לרעש שהתורן מפסיק לקרוא. להלן סדר עבודה והתוצאה של כל צעד.
- ביקורת נראות. אוספים רשימת שירותים, סביבות ובעלים: היכן מדדים מופעלים כברירת מחדל, היכן לוגים נכתבים לשום מקום, אילו התראות כפולות ואילו שותקות. התוצאה — מפת פערים עם עדיפויות.
- סכימת איסוף נתונים. מחליטים מה נלקח במדדים סטנדרטיים, מה משלימים מהיומנים, ואילו רשומות מחריגים כדי שהאחסון לא יגדל על זבל. קובעים מילון תוויות אחיד וגבולות גישה לפי פרויקטים.
- הגדרת איסוף ולוחות. פורסים סוכנים ב-Google Cloud, מגדירים מדיניות שמירה ושליפה, בונים דשבורדים: סקירה לפי שירותים ופירוט לפי צמתים.
- ספי התראות. בונים מדיניות מסימפטומים לסיבות: תחילה מה שהמשתמש חש, אחר כך המשאבים שהובילו לכך. קובעים רמות חשיבות, חלונות דיכוי וניתוב לפי תורנויות.
- בדיקת התראות. מבצעים תקלה מדומה: מכבים צומת או מציפים את היומן בשגיאות, ובודקים אם המדיניות הופעלה, אם הגיעה לתורן ובתוך כמה זמן. תיקוני התראות שווא מתבצעים לפני המסירה.
- מסירת נהלים. מוסרים תיעוד: מה הוגדר, מדוע הספים דווקא כאלה, כיצד לחבר שירות חדש ולאן לפנות כשההתראה מופעלת.
ארטיפקטים למסירה: קונפיגורציות, סכימות, נהלי תורנויות
לאחר מסירת העבודות בפלטפורמת הענן של הלקוח נשארת לא קבוצת צילומי מסך מהקונסולה, אלא קונפיגורציית נראות עובדת: היא ממשיכה לאסוף מדדים ולוגים כבר בלי הגישה שלנו. להלן מה בדיוק מועבר לפי פרוטוקול וכיצד זה נבדק בקבלה.
- קונפיגורציות ניטור — כללי בדיקות זמינות, ספים להשהיה ולשיעור שגיאות, קיבוץ משאבים ותנאי אגרגציה. נשמרות כקוד במאגר שלכם, ולא רק בקונסולת האינטרנט.
- סכימות זרימת נתונים — מהיכן מגיעים מדדים ולוגים, באילו חוליות הם עוברים, היכן נשמרים ואחרי כמה זמן נדחקים החוצה, עם תקופות שמירה לכל סוג.
- מדיניות גישה למדדים — תפקידים לתורנים, למפתחים ולקבלנים, הפרדת הרשאות לקריאה ולשינוי כללים, חשבונות שירות במקום חשבונות אישיים.
- נוהל תורנויות — רמות קריטיות, למי ובאיזה מועד נשלחת התראה, מה נחשב התראת שווא ומתי הכלל נכתב מחדש.
- תיעוד תחזוקה — כיצד להוסיף בדיקה חדשה, כיצד להחזיר שינוי לאחור ומה לעשות אם המערכת השתתקה והפסיקה לשלוח נתונים.
- הוראות לאירועים נפוצים — תרחישים צעד-אחר-צעד ל-4-6 כשלים טיפוסיים: מה לבדוק וכיצד לאשר התאוששות.
- מפת בעלות — מי אחראי לכל כלל וערוץ התראה, מתי נבחנים מחדש הספים וכיצד מועברים בעת החלפת אחראי.
הקבלה נעשית לפי צ'ק-ליסט: כל כלל נבדק בהפעלה מאולצת בסביבת בדיקות, ואת השינוי בקונפיגורציה מבצעים אתם בעצמכם — אם אי אפשר לשנות כלל בלעדינו, זו תלות, לא מסירה.
מקרה בוחן: קיצור זמן גילוי התקלה משעות לדקות
אצל הלקוח מדדים נאספו, אבל חיו בפיזור: חלק מהשירותים סיפקו לוחות ניטור משל עצמם, וחלק — רק לוגים טקסטואליים. ההתראות הוגדרו לפי סימנים טכניים — עומס מעבד, התמלאות דיסק, נפילה של צומת בודד. על ההידרדרות הצוות למד מפניות תמיכה: 3-4 שעות מהשגיאות הראשונות אצל המשתמש ועד שהאירוע הבחין.
הניתוח נתקע בנתונים: את התמונה הרכיבו ידנית משברי לוגים במקומות שונים, וזה לקח עד יומיים. שבע מתוך עשר הפעלות התבררו כרעש, ולכן הפסיקו לתת אמון בהתראות — וזה מסוכן יותר מהיעדרן.
מה שינו
איחדנו מדדים, לוגים וטראסות למעגל נראות אחד ב-Cloud Monitoring ו-Cloud Logging, עם תוויות משותפות של שירות, סביבה וגרסת שחרור. את הכללים כתבנו מחדש לפי סימנים שהמשתמש חש: שיעור שגיאות, זמן תגובה, זמינות תרחישים קריטיים.
הספים הוגדרו לפי קצב השינוי, לא לפי ערך מוחלט, התראות קשורות מקובצות, וחזרות מדוכאות על ידי חלון שקט.
מדדים לפני ואחרי
זמן גילוי האירוע — מ-3-4 שעות ל-5-7 דקות, שיעור התראות השווא — מ-70% ל-12-15%. חלק האירועים שהצוות למד עליהם לפני המשתמשים עלה מ-20% ל-85%.
ניתוח האירוע התקצר מיומיים ל-30-50 דקות: מההתראה יש קישור לחתך הלוגים הנדרש ולגרפי המדדים בתקופת ההידרדרות, והמהנדס רואה מיד איזה שחרור ואיזה צומת היו המקור. זה הערך המעשי של מקרה הנראות: לא לוחות לשם לוחות, אלא זמן תגובה צפוי.
במה שונה איסוף מדדים בסוכן מאמצעים מובנים
את השאלה בדרך כלל מציגים כדילמה: להתקין סוכן איסוף מדדים או להסתפק באמצעי איסוף מובנים. בפועל זה לא בחירה בין שניים — שכבות הטלמטריה פשוט שונות. אמצעים מובנים רואים את שכבת הפלטפורמה: מצב מופעים, דיסקים, רשת, מאזני עומס, אירועי אשכול. אותם אוספת התשתית עצמה, ואין לנו מה לתחזק — המדדים מופיעים יחד עם המשאב ומיד קשורים אליו.
סוכן איסוף מדדים נחוץ במקום שבו מתחילה האפליקציה. זה תהליך על המארח או לצד הקונטיינר: הוא שולף מדדים מהשירות עצמו ומהקולטים שלו ושולח אותם לאותו אחסון כמו המדדים הפלטפורמיים. רק כך מופיעים אורך תור, זמן תגובה של תלות חיצונית, שיעור שגיאות במטפל מסוים, תוויות עם גרסת בנייה וסביבה.
המחיר לכך — תקורה של איסוף: זיכרון וזמן מעבד בכל צומת, עדכוני סוכן, קונפיגורציות שיש לתעד בגרסאות יחד עם האפליקציה.
איסוף היברידי הוא הפתרון העובד: את הפלטפורמי לוקחים מובנה, את היישומי — בסוכן, ובממשק ביניהם מסכמים על מקור אמת אחד לכל מדד. בלי זה כללי ההתראות כפולים, והתיוג מתפצל, ואי אפשר להשוות מדדים בשאילתה אחת.
נוח לפרוס את כיסוי השירותים לפי שכבות. שירותים מנוהלים מכוסים באמצעים מובנים, אפליקציות משלכם — בסוכן, תלויות חיצוניות — בבדיקות זמינות נפרדות. אם מדדים נדרשים רק לפי תשתית, הסוכן מוסיף תחזוקה בלי תועלת: יש הוצאות, והאבחון לא משתנה.
מכאן הקריטריון: הסוכן מוצדק כאשר בלעדיו סיבת ההידרדרות אינה נראית. מדדים פלטפורמיים יראו שהשירות מגיב לאט יותר, אבל לא יראו באיזה שלב הוא עושה זאת. נבחן היכן עובר הגבול אצלכם, ונבנה סכימת איסוף בהתאם.
מגבלות וספקות טכניים לפני התחלה
הספקות לפני ההתחלה הם בדרך כלל הנדסיים: האם איסוף המדדים ישתלב בנוף הנוכחי, האם זרם היומנים לא יתפח, האם הרשאות חשבון השירות יספיקו ומתי המאמצים יתחילו להחזיר את עצמם. להלן ארבע שאלות שלרוב מעכבות את המעבר לנראות ב-Google Cloud.
התשתית לא אחידה — האם הקולט יתאים להכול?
סוכן האיסוף מותקן גם על מכונות וירטואליות וגם באשכול, ומדדי אפליקציות מתקבלים בפורמט חשיפה פתוח. יצואנים ולוחות קיימים נעשים בהם שימוש חוזר, ומעגלים מחוץ לענן מתחברים דרך ממסר.
היומנים יתפסו את כל האחסון?
הזרם מסונן בצד הסוכן: רמות דיבוג ובדיקות זמינות נחתכות לפני הכתיבה. השאר מונח בדליים עם תקופות שונות — חם קצר וארכיוני ארוך, ונפח הרשומות יורד פי כמה בלי לאבד את ניתוח האירועים מהתקופה הקודמת.
אילו הרשאות לתת ולא לפתוח יותר מדי?
לחשבון שירות — רק כתיבה של מדדים ויומנים, קריאה בתפקידים נפרדים לתורנים ולאנליסטים, ופניות לנתונים נרשמות ביומן ביקורת. מפתחות ארוכי טווח לא נשמרים, גישה ניתנת בחשבונות זמניים.
מתי המאמצים יחזירו את עצמם?
הסט הראשון של לוחות והתראות לשירותי הליבה עובד כבר בשבועות הראשונים לאחר החיבור. מדד התוצאה — שיעור הכשלים שהתורן רואה וסוגר לפני שהמשתמש פונה.
נדון במשימה: אילו נתונים נדרשים לתוכנית העבודה
כדי שההערכה תהיה עניינית ולא "פחות או יותר", נדרשים נתוני מקור על התשתית והדרישות לנראות. שלחו את מה שכבר קיים — אפילו סט חלקי מקצר את השיחה הראשונה ומסיר סבבי הבהרות מיותרים. להלן רשימה של מה שבאמת משפיע על תוכנית העבודה.
- רשימת שירותים ומעגלים: מה עובד בסביבת פיתוח, בסביבת בדיקות ובסביבת פרודקשן, אילו תהליכים קריטיים ואילו אפשר לא לכסות.
- מצב הניטור הנוכחי: לוחות קיימים, כללי הפעלה, ספים והמידה שאפשר לתת בהם אמון בניתוח אירועים.
- ציפיות לאותות: אילו תקלות צריך להבחין בהן לפני המשתמש, אילו ערכים נחשבים לנורמה ואילו לסטייה.
- הרכב היומנים ודרישות אחסון: תקופות, נפחים משוערים, האם נדרש ייצוא לניתוח אירועים ולבדיקות.
- גישות: חשבונות עם הרשאות קריאה בלבד, תפקידים ומגבלות לפי פרויקטים — זה מספיק לניתוח, ולא יהיה צורך לשנות דבר.
- ערוצי התראה: לאן צריכות להגיע ההתראות ומי תורן, כדי שהאות יגיע לאחראי ולא לצ'אט כללי.
נוח לדון במשימה עם מהנדס שיוביל את הפרויקט: השיחה נמשכת 40–60 דקות, מפרקים את הסכימה, מדייקים גבולות ועונים על שאלות טכניות בלי מילים כלליות.
אחריה נחזור עם תוכנית עבודה: אילו מדדים ולוגים נאסוף, כיצד בנויים הלוחות וכללי ההתראה, מהם שלבי היישום ולפי אילו קריטריונים נקבל את התוצאה. הצעד הבא — תארו את המשימה בצורה חופשית, ונחזור עם הערכה ותוכנית.