במסמך הזה מתואר איך תקופות ההתאמה וחלונות הבדיקה מחדש קובעים מתי מתקיים תנאי מסוים, איך מדיניות התראות משלבת כמה תנאים ואיך מדיניות התראות מחליפה נקודות נתונים חסרות. המאמר מתאר גם את המספר המקסימלי של התראות פתוחות לכל מדיניות, את מספר ההתראות לכל התראה ואת הסיבות לעיכובים בהתראות.
התוכן הזה לא רלוונטי למדיניות התראות שמבוססת על יומנים. מידע על מדיניות התראות שמבוססת על יומנים זמין במאמר מעקב אחרי היומנים.
תקופות התאמה וחלונות לבדיקה מחדש
Cloud Monitoring מעריך את תקופת ההתאמה ואת חלון הבדיקה מחדש כדי לקבוע אם התנאי של מדיניות ההתראות מתקיים.
תקופת ההתאמה
לפני שמדיניות התראות יכולה לעקוב אחרי נתוני סדרות זמן, צריך לבצע רגולריזציה של הנתונים כדי שמדיניות ההתראות תוכל להעריך נתונים עם מרווחים קבועים. תהליך הרגולריזציה נקרא התאמה.
תהליך ההתאמה כולל שני שלבים:
חלוקת סדרת הזמן למרווחי זמן קבועים, שנקראת גם חלוקת הנתונים לקטגוריות. האינטרוול הוא תקופת ההתאמה.
חישוב ערך יחיד לנקודות בתקופת ההתאמה. אתם בוחרים איך לחשב את הנקודה היחידה הזו. למשל, אפשר לסכום את כל הערכים, לחשב את הממוצע שלהם או להשתמש בערך המקסימלי. הפונקציה שממזגת את נקודות הנתונים נקראת פונקציית ההתאמה. התוצאה של השילוב נקראת ערך מיושר.
מידע נוסף על התאמה מופיע במאמר התאמה: רגולריזציה בתוך סדרה.
לדוגמה, אם תקופת ההתאמה היא חמש דקות, בשעה 13:00, תקופת ההתאמה מכילה את הדגימות שהתקבלו בין השעות 12:55 ל-13:00. בשעה 13:01, תקופת ההתאמה זזה בדקה אחת וכוללת את הדגימות שהתקבלו בין 12:56 ל-13:01.
המעקב מגדיר תקופת התאמה באופן הבא:
מסוף Google Cloud
כדי להגדיר את תקופת ההתאמה, בוחרים ערך בשדות הבאים בדף Alert conditions:
- חלון נע: מציין את טווח הזמן להערכה.
- פונקציית חלון נע: מציינת את הפונקציה המתמטית שתופעל על חלון של נקודות נתונים.
מידע נוסף על הפונקציות הזמינות מופיע במאמר Aligner במאמרי העזרה של ה-API. חלק מהפונקציות של הכלי להתאמת נתונים גם מתאימות את הנתונים וגם ממירות אותם מסוג או מסוג משנה אחד של מדד לסוג או לסוג משנה אחר. הסבר מפורט זמין במאמר סוגים, סוגים והמרות.
API
כדי להגדיר את תקופת ההתאמה, צריך להגדיר את השדות aggregations.alignmentPeriod ו-aggregations.perSeriesAligner במבנים MetricThreshold ו-MetricAbsence.
מידע נוסף על הפונקציות הזמינות מופיע במאמר Aligner במאמרי העזרה של ה-API. חלק מהפונקציות של הכלי להתאמת נתונים גם מתאימות את הנתונים וגם ממירות אותם מסוג או מסוג משנה אחד של מדד לסוג או לסוג משנה אחר. הסבר מפורט זמין במאמר סוגים, סוגים והמרות.
כדי להמחיש את ההשפעה של תקופת ההתאמה על תנאי במדיניות התראות, נתייחס לתנאי של סף מדד שעוקב אחרי מדד עם תקופת דגימה של דקה אחת. נניח שתקופת ההתאמה מוגדרת לחמש דקות ושהכלי להתאמה מוגדר ל-sum. בנוסף, נניח שהתנאי מתקיים כשהערך המיושר של סדרת הזמן גדול משניים למשך שלוש דקות לפחות, ושהתנאי נבדק בכל דקה.
בדוגמה הזו, חלון הבדיקה מחדש, שמתואר בקטע הבא, הוא של שלוש דקות. האיור הבא ממחיש כמה הערכות רצופות של התנאי:
כל שורה באיור ממחישה הערכה אחת של התנאי. מוצגים נתונים של פעולות על ציר הזמן. הנקודות בתקופת ההתאמה מוצגות כנקודות כחולות, והנקודות הישנות יותר מוצגות בשחור. בכל שורה מוצג הערך המותאם, ומוצג גם אם הערך הזה גדול מסף של שניים. בשורה עם התווית start, הערך המיושר הוא 1, שהוא נמוך מהסף.
בהערכה הבאה, סכום הדגימות בתקופת ההתאמה הוא 2.
בהערכה השלישית, הסכום הוא שלוש, ומכיוון שהערך הזה גדול מהסף, מתחיל טיימר לחלון הבדיקה מחדש.
חלונות בדיקה מחדש
לתנאי של מדיניות התראות יש חלון בדיקה חוזרת, שמונע את קיום התנאי בגלל מדידה או תחזית יחידה. לדוגמה, נניח שחלון הבדיקה מחדש של תנאי מסוים מוגדר ל-15 דקות. בהמשך מפורטת ההתנהגות של התנאי על סמך הסוג שלו:
- תנאי סף של מדדים מתקיימים כשכל מדידה מיושרת במרווח של 15 דקות בסדרת זמן יחידה חורגת מהסף.
- תנאים של היעדר מדדים מתקיימים כשלא מתקבלים נתונים עבור סדרת זמן במרווח של 15 דקות.
- תנאי התחזית מתקיימים כשכל תחזית שנוצרת במהלך חלון של 15 דקות חוזה שהסדרה העתית תעבור את הסף בתוך חלון התחזית.
במדיניות עם תנאי אחד, ההתראה נפתחת וההתראות נשלחות כשהתנאי מתקיים. ההתראות האלה יישארו פתוחות כל עוד התנאי ממשיך להתקיים.
מסוף Google Cloud
כדי להגדיר את חלון הבדיקה מחדש, משתמשים בשדה Retest window (חלון בדיקה מחדש) בשלב Configure alert trigger (הגדרת טריגר להתראה).
API
כדי להגדיר את חלון הבדיקה מחדש, צריך להגדיר את השדה duration במבנים MetricThreshold ו-MetricAbsence.
באיור הקודם מוצגים שלושה מצבים של הערכת תנאי של סף מדד. בזמן start + 2 minutes, הערך המותאם גדול מהסף, אבל התנאי לא מתקיים כי חלון הבדיקה מחדש מוגדר לשלוש דקות. האיור הבא מציג את התוצאות של ההערכות הבאות של התנאי:
למרות שהערך המותאם גדול מהסף בזמן start + 2 minutes, התנאי לא מתקיים עד שהערך המותאם גדול מהסף למשך שלוש דקות. האירוע הזה מתרחש בשעה start + 5 minutes.
חלון הבדיקה מחדש של תנאי מתאפס בכל פעם שמדידה או תחזית לא עומדות בתנאי. לכן, צריך להגדיר את חלון הבדיקה מחדש כך שיהיה ארוך מספיק כדי למזער את התוצאות החיוביות השגויות, אבל קצר מספיק כדי לוודא שההתראות נפתחות בזמן. ההתנהגות הזו מודגמת בדוגמה הבאה:
דוגמה
מדיניות ההתראות הזו מכילה תנאי של סף מדד שמציין חלון בדיקה מחדש של חמש דקות.
אם זמן האחזור של תגובת ה-HTTP גדול משתי שניות,
ואם זמן האחזור גדול מהסף במשך חמש דקות,
תיפתח התראה ויישלח אימייל לצוות התמיכה.
הדוגמה הבאה ממחישה איך חלון הבדיקה מחדש משפיע על הערכת התנאי:
- זמן האחזור של HTTP הוא פחות משתי שניות.
- במשך שלוש דקות רצופות, זמן האחזור של HTTP גדול משתי שניות.
- במדידה הבאה, זמן האחזור הוא פחות משתי שניות, ולכן התנאי מאפס את חלון הבדיקה מחדש.
במשך חמש הדקות הבאות ברציפות, זמן האחזור של HTTP גדול משתי שניות, ולכן התנאי מתקיים.
מכיוון שמדיניות ההתראות כוללת תנאי אחד, מערכת Monitoring שולחת התראות כשהתנאי מתקיים.
שיטות מומלצות להגדרת תקופת ההתאמה וחלון הבדיקה מחדש
תקופת ההתאמה קובעת כמה דגימות משולבות על ידי הכלי להתאמה. ההשפעה של הגדרת תקופת ההתאמה תלויה במרווח הדגימה, בעיכוב ההטמעה ובמספר הדגימות שרוצים לשלב:
תקופת ההתאמה לא יכולה להיות ארוכה מ-24 שעות פחות זמן ההשהיה של ההעברה.
מומלץ להגדיר את תקופת ההתאמה כך שתהיה ארוכה לפחות כמו העיכוב בהעברה. עם זאת, תקופת ההתאמה צריכה להיות תמיד לפחות באורך של מרווח הדגימה.
במקרים של תנאי סף של מדדים, הערך המקסימלי הטיפוסי של תקופת ההתאמה הוא 25 שעות פחות עיכוב ההטמעה של סוג המדד. לדוגמה, אם העיכוב בהוספה של מדד הוא 6 שעות, הערך המקסימלי של תקופת ההתאמה הוא 19 שעות. אפשר להשתמש ב-PromQL כדי להגדיר התראות על נתונים בני יותר מ-25 שעות. מידע נוסף זמין במאמר שימוש ב-PromQL ליצירת כללי התראה.
לדוגמה, אם העיכוב בהוספת נתונים לסוג מסוים של מדד הוא 6 שעות, מומלץ להשתמש בתקופת יישור של בין 6 ל-18 שעות. נניח שמרווח הדגימה הוא 60 שניות. אם מגדירים את תקופת ההתאמה ל-6 שעות ו-5 דקות, הכלי להתאמת נתונים משלב בממוצע 5 דגימות.
אם לסוג מדד יש עיכוב ארוך מאוד בהוספה, למשל 18 שעות, צריך להגדיר את תקופת ההתאמה כך שתהיה לפחות באורך מרווח הדגימה, אבל לכל היותר 24 שעות פחות העיכוב בהוספה.
משתמשים בחלון הבדיקה מחדש כדי לציין את רמת התגובה של ההתראה. לדוגמה, אם מגדירים את חלון הבדיקה מחדש ל-20 דקות עבור תנאי של היעדר מדד, לא יכולים להיות נתונים במשך 20 דקות לפני שהתנאי מתקיים. כדי שמדיניות ההתראות תהיה רגישה יותר, צריך להגדיר את חלון הבדיקה מחדש לערך קטן יותר. כדי שמדיניות ההתראות תהיה הכי רספונסיבית, צריך להגדיר את חלון הבדיקה מחדש לאפס בתנאים של סף המדד. ערך יחיד שמוגדר בהתאמה גורם לתנאים מהסוגים האלה להתקיים.
אם מגדירים את חלון הבדיקה מחדש, יכול להיות שתצטרכו לקצר את תקופת ההתאמה בגלל מגבלות של מדיניות התראות.
הערכת התנאים של כללי מדיניות התראות מתבצעת בתדירות קבועה. הבחירות שלכם לגבי תקופת ההתאמה וחלון הבדיקה מחדש לא קובעות את תדירות הערכת התנאי.
כללי מדיניות עם כמה תנאים
כלל מדיניות להתרעות יכול להכיל עד 6 תנאים.
אם אתם משתמשים ב-Cloud Monitoring API או אם מדיניות ההתראות שלכם כוללת כמה תנאים, אתם צריכים לציין מתי תיפתח התראה. כדי להגדיר איך משלבים כמה תנאים, מבצעים אחת מהפעולות הבאות:
מסוף Google Cloud
מגדירים את האפשרויות של ה-Combiner בשלב Multi-condition trigger (טריגר עם כמה תנאים).
API
מגדירים את האפשרויות של הכלי לצירוף באמצעות השדה combiner במבנה AlertPolicy.
בטבלה הזו מפורטות ההגדרות במסוף Google Cloud , הערך המקביל ב-Cloud Monitoring API ותיאור של כל הגדרה:
| ערך ההפעלה של המדיניות במסוףGoogle Cloud |
ערך משולב של Cloud Monitoring API |
משמעות |
|---|---|---|
| מתקיים אחד מהתנאים | OR |
התראה תיפתח אם מקור מידע כלשהו יגרום לאחד מהתנאים להתקיים. |
| כל התנאים מתקיימים גם אם מדובר במשאבים שונים לכל תנאי (ברירת מחדל) |
AND |
התראה נפתחת עבור כל תנאי שמתקיים כשכל התנאים מתקיימים, גם אם משאב אחר גורם לתנאים האלה להתקיים. |
| כל התנאים מתקיימים | AND_WITH_MATCHING_RESOURCE |
התראה נפתחת עבור כל תנאי שמתקיים כשכל התנאים מתקיימים, רק אם אותו משאב גורם לכל תנאי להתקיים. ההגדרה הזו היא ההגדרה המחמירה ביותר מבין האפשרויות לשילוב בחירה. |
בהקשר הזה, המונח התקיים מציין שההגדרה של התנאי מחזירה את הערך True. לדוגמה, אם ההגדרה היא Any time series is greater than 10 for 5 minutes, התנאי מתקיים כשההצהרה הזו מחזירה את הערך true.
דוגמה
נניח שיש Google Cloud פרויקט שמכיל שתי מכונות וירטואליות, vm1 ו-vm2. נניח שאתם יוצרים מדיניות התראות עם 2 תנאים:
- התנאי שנקרא
CPU usage is too highעוקב אחרי השימוש ביחידת העיבוד המרכזית (CPU) של המכונות. התנאי הזה מתקיים כששימוש המעבד (CPU) בכל מופע גדול מ-100ms/s למשך דקה. - התנאי שנקרא
Excessive utilizationעוקב אחרי ניצול המעבד של המופעים. התנאי הזה מתקיים אם ניצול המעבד של מופע כלשהו גדול מ-60% למשך דקה אחת.
בתחילה, נניח ששני התנאים מחזירים את הערך false.
לאחר מכן, נניח ששימוש המעבד (CPU) של vm1 חורג מ-100ms/s למשך דקה אחת. התנאי CPU usage is too high מתקיים כי השימוש במעבד גבוה מהסף למשך דקה אחת. אם התנאים משולבים עם Any condition is met, אז נוצרת התראה כי תנאי מסוים מתקיים. אם התנאים משולבים עם All conditions are met או עם All conditions are met even for different resources for each condition, לא נוצרת התראה. כדי להשתמש באפשרויות האלה, שני התנאים צריכים להתקיים.
עכשיו נניח ששימוש המעבד (CPU) במכונה vm1 נשאר גבוה מ-100ms/s ושהשימוש במעבד במכונה vm2 חורג מ-60% למשך דקה. התוצאה היא ששני התנאים מתקיימים. בהמשך מוסבר מה קורה בהתאם לאופן שבו התנאים משולבים:
כל תנאי מתקיים: נוצרת התראה כשמשאב גורם לתנאי להתקיים. בדוגמה הזו, vm2 גורם לתנאי
Excessive utilizationלהתקיים.אם מכונה וירטואלית vm2 גורמת לתנאי
CPU usage is too highלהתקיים, גם זה יוביל ליצירת התראה. התראה נוצרת כי vm1 ו-vm2 שגורמים לתנאיCPU usage is too highלהתקיים הם אירועים שונים.כל התנאים מתקיימים, גם אם מדובר במשאבים שונים לכל תנאי: נוצרת התראה כי שני התנאים מתקיימים.
כל התנאים מתקיימים: לא נוצרת התראה כי כדי שהמשלב הזה יפעל, אותו משאב צריך לגרום לכל התנאים להתקיים. בדוגמה הזו, לא נוצרת התראה כי vm1 גורם להשגת התנאי
CPU usage is too high, ו-vm2 גורם להשגת התנאיExcessive utilization.
נתוני מדדים חלקיים
אם נתוני סדרת הזמן מפסיקים להגיע או אם יש עיכוב בהגעת הנתונים, המערכת מסווגת את הנתונים כחסרים. נתונים חסרים יכולים למנוע את סגירת ההתראות. העיכובים בהגעת הנתונים מספקי ענן של צד שלישי יכולים להגיע ל-30 דקות, והעיכובים הנפוצים ביותר הם של 5 עד 15 דקות. עיכוב ממושך – ארוך יותר מחלון הבדיקה מחדש – עלול לגרום לתנאים להיכנס למצב 'לא ידוע'. כשהנתונים מגיעים בסופו של דבר, יכול להיות שחלק מההיסטוריה האחרונה של התנאים אבדה ב-Monitoring. בבדיקה מאוחרת יותר של נתוני הסדרות העיתיות יכול להיות שלא תזוהה הבעיה הזו, כי לא יהיו הוכחות לעיכובים אחרי שהנתונים יגיעו.
מסוף Google Cloud
אתם יכולים להגדיר איך כלי המעקב מעריך תנאי של סף מדד כשנתונים מפסיקים להגיע. לדוגמה, אם התקבלה התראה ולא התקבל מדד צפוי, האם אתם רוצים שההתראה תישאר פתוחה או שתיסגר מיד? באופן דומה, אם הנתונים מפסיקים להגיע ואין התראה פתוחה, האם רוצים שהתראה תיפתח? לבסוף, כמה זמן התראה צריכה להישאר פתוחה אחרי שהנתונים מפסיקים להגיע?
יש שני שדות שניתנים להגדרה ומציינים איך Monitoring מעריך תנאי סף של מדדים כשהנתונים מפסיקים להגיע:
כדי להגדיר איך כלי המעקב קובע את ערך ההחלפה של נתונים חסרים, משתמשים בשדה הערכה של נתונים חסרים שמוגדר בשלב הפעלת התנאי. השדה הזה מושבת אם חלון הבדיקה מחדש מוגדר לערך ללא בדיקה מחדש.
חלון הבדיקה מחדש הוא השדה שנקרא duration (משך) ב-Cloud Monitoring API.
כדי להגדיר כמה זמן יחכה המעקב לפני סגירת התראה פתוחה אחרי שהנתונים יפסיקו להגיע, משתמשים בשדה משך הזמן עד לסגירה אוטומטית של ההתראה. אתם מגדירים את משך הזמן של הסגירה האוטומטית בשלב ההתראה. משך הזמן שמוגדר כברירת מחדל לסגירה אוטומטית הוא שבעה ימים.
בהמשך מפורטות האפשרויות השונות לשדה הנתונים החסר:
| Google Cloud console השדה 'הערכה של נתונים חסרים' |
סיכום | פרטים |
|---|---|---|
| נתונים חסרים ריקים | התראות פתוחות נשארות פתוחות. התראות חדשות לא נפתחות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם התראה פתוחה לגבי התנאי הזה, ההתראה תישאר פתוחה. אם התראה פתוחה ולא מתקבלים נתונים, הטיימר לסגירה אוטומטית מתחיל לפעול אחרי השהיה של לפחות 15 דקות. אם חולף הזמן שהוגדר, ההתראה תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
| נקודות נתונים חסרות נחשבות כערכים שמפירים את תנאי המדיניות | התראות פתוחות נשארות פתוחות. אפשר לפתוח התראות חדשות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם התראה פתוחה לגבי התנאי הזה, ההתראה תישאר פתוחה. אם התראה פתוחה ולא מגיעים נתונים למשך הזמן של הסגירה האוטומטית בתוספת 24 שעות, ההתראה נסגרת. אם התנאים לא מתקיימים, ההגדרה הזו גורמת לתנאי של סף מדד להתנהג כמו |
| נקודות נתונים חסרות נחשבות כערכים שלא מפרים את תנאי המדיניות | ההתראות הפתוחות נסגרות. התראות חדשות לא נפתחות. |
אם התנאים מתקיימים, הם יפסיקו להתקיים כשהנתונים יפסיקו להגיע. אם התראה פתוחה לגבי התנאי הזה, ההתראה תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
API
אתם יכולים להגדיר איך כלי המעקב מעריך תנאי של סף מדד כשנתונים מפסיקים להגיע. לדוגמה, אם התקבלה התראה ולא התקבל מדד צפוי, האם אתם רוצים שההתראה תישאר פתוחה או שתיסגר מיד? באופן דומה, אם הנתונים מפסיקים להגיע ואין התראה פתוחה, האם רוצים שהתראה תיפתח? לבסוף, כמה זמן התראה צריכה להישאר פתוחה אחרי שהנתונים מפסיקים להגיע?
יש שני שדות שניתנים להגדרה ומציינים איך Monitoring מעריך תנאי סף של מדדים כשהנתונים מפסיקים להגיע:
כדי להגדיר איך כלי המעקב קובע את ערך ההחלפה לנתונים חסרים, משתמשים בשדה
evaluationMissingDataשל מבנהMetricThreshold. המערכת מתעלמת מהשדה הזה אם הערך בשדהdurationהוא אפס.כדי להגדיר כמה זמן מערכת Monitoring תמתין לפני סגירת התראה פתוחה אחרי שהנתונים מפסיקים להגיע, משתמשים בשדה
autoCloseבמבנה AlertStrategy.
בהמשך מפורטות האפשרויות השונות לשדה הנתונים החסר:
שדה APIevaluationMissingData |
סיכום | פרטים |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
התראות פתוחות נשארות פתוחות. התראות חדשות לא נפתחות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם אם הנתונים יפסיקו להגיע. אם יש התראה פתוחה לגבי התנאי הזה, ההתראה תישאר פתוחה. כשמתקבלת התראה ולא מגיעים נתונים, הטיימר לסגירה אוטומטית מתחיל לפעול אחרי השהיה של לפחות 15 דקות. אם הזמן שנותר בטיימר יתאפס, ההתראה תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
EVALUATION_MISSING_DATA_ACTIVE |
התראות פתוחות נשארות פתוחות. אפשר לפתוח התראות חדשות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם אם הנתונים יפסיקו להגיע. אם יש התראה פתוחה לגבי התנאי הזה, ההתראה תישאר פתוחה. אם התראה פתוחה ולא מתקבלים נתונים במשך משך הזמן לסגירה אוטומטית ועוד 24 שעות, ההתראה נסגרת. אם התנאים לא מתקיימים, ההגדרה הזו גורמת לתנאי של סף מדד להתנהג כמו |
EVALUATION_MISSING_DATA_INACTIVE |
ההתראות הפתוחות נסגרות. התראות חדשות לא נפתחות. |
אם התנאים מתקיימים, הם יפסיקו להתקיים כשהנתונים יפסיקו להגיע. אם התראה פתוחה לגבי התנאי הזה, ההתראה תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
כדי לצמצם את הבעיות שנובעות מנתונים חסרים, אפשר לבצע אחת מהפעולות הבאות:
- צריך ליצור קשר עם ספק שירותי הענן של צד שלישי כדי לזהות דרכים להפחתת זמן האחזור של איסוף המדדים.
- כדאי להשתמש בחלונות ארוכים יותר לבדיקה חוזרת בתנאים. החיסרון בשימוש בחלון בדיקה מחדש ארוך יותר הוא שמדיניות ההתראות תהיה פחות רספונסיבית.
מומלץ לבחור מדדים עם עיכוב נמוך יותר באיסוף:
- מעקב אחרי מדדי הסוכן, במיוחד כשהסוכן פועל במכונות וירטואליות בעננים של צד שלישי.
- מדדים מותאמים אישית, כשכותבים את הנתונים שלהם ישירות ל-Monitoring.
- מדדים מבוססי-יומנים, אם איסוף הרשומות ביומן לא מתעכב.
מידע נוסף זמין במאמרים סקירה כללית על סוכן תפעול, סקירה כללית על מדדים מוגדרים על ידי המשתמש ומדדים מבוססי-יומן.
מתי מערכת Monitoring שולחת התראות ויוצרת התראות
Cloud Monitoring שולח התראה כשסדרת זמן גורמת לתנאי להתקיים. ההתראה נשלחת לכל הערוצים של ההתראות. אי אפשר להגביל את ההתראה לערוץ ספציפי או לקבוצת משנה של הערוצים שכלולים במדיניות.
אם מגדירים התראות חוזרות, אותה התראה נשלחת מחדש לערוצי התראות ספציפיים במדיניות ההתראות.
יכול להיות שתקבלו כמה התראות ייחודיות שקשורות למדיניות התראות אחת, אם מתקיים אחד מהתנאים הבאים:
תנאי מסוים עוקב אחרי כמה סדרות זמן.
מדיניות מכילה מספר תנאים. במקרה כזה, ההתראות שתקבלו תלויות בערך של טריגר המדיניות ליצירת התראות עם כמה תנאים:
כל התנאים מתקיימים: כשכל התנאים מתקיימים, מדיניות ההתראות שולחת התראה ויוצרת התראה לכל סדרת זמן שבה מתקיים תנאי.
אי אפשר להגדיר את Cloud Monitoring כך שתישלח רק התראה אחת ורק התראה אחת כשמדיניות ההתראות מכילה כמה תנאים.
מתקיים תנאי כלשהו: מדיניות ההתראות שולחת התראה כשסדרת זמן גורמת לתנאי להתקיים.
מידע נוסף מופיע במאמר בנושא כללי מדיניות עם כמה תנאים.
מדיניות התראות שנוצרת באמצעות Cloud Monitoring API גם שולחת לכם התראה כשהתנאי מתקיים וכשהוא מפסיק להתקיים. מדיניות התראות שנוצרה באמצעות מסוף Google Cloud לא שולחת הודעה כשהתנאי מפסיק להתקיים, אלא אם הפעלתם את ההתנהגות הזו.
מתי המערכת של Google Cloud Monitoring לא שולחת התראות או יוצרת התראות
במצבים הבאים, המערכת של Monitoring לא יוצרת התראות ולא שולחת הודעות כשהתנאים של מדיניות ההתראות מתקיימים:
- מדיניות ההתראות מושבתת.
- כלל מדיניות ההתראות מושהה.
- הגעתם למגבלה של מספר ההתראות הפתוחות המקסימלי.
כללי מדיניות התראות שהושבתו
התראות לא נשלחות על ידי המעקב אם כללי המדיניות להתרעות מושבתים. עם זאת, המערכת ממשיכה להעריך את התנאים של מדיניות התראות מושבתת.
כשמפעילים מדיניות שהושבתה, המערכת של Monitoring מעריכה את הערכים של כל התנאים במהלך חלון הבדיקה מחדש האחרון. יכול להיות שחלון הבדיקה מחדש האחרון יכלול נתונים שנאספו לפני, במהלך ואחרי הפעלת המדיניות. התנאים של מדיניות מושבתת יכולים להתקיים מיד אחרי חידוש המדיניות, גם אם חלונות הבדיקה מחדש גדולים.
לדוגמה, נניח שיש לכם מדיניות התראות שעוקבת אחרי תהליך ספציפי והשבתתם את המדיניות הזו. בשבוע שלאחר מכן, התהליך נכשל, ואתם לא מקבלים על כך התראה כי מדיניות ההתראות מושבתת. אם מפעילים מחדש את התהליך ומפעילים את מדיניות ההתראות באופן מיידי, המערכת של Monitoring מזהה שהתהליך לא פעל בחמש הדקות האחרונות ופותחת התראה.
ההתראות שקשורות למדיניות התראות מושבתת יישארו פתוחות עד שתוקף משך הסגירה האוטומטית של המדיניות יפוג.
כללי מדיניות התראות שהושהו
המעקב לא שולח התראות ולא יוצר התראות לגבי מדיניות התראות שמושהית. מומלץ להשהות את מדיניות ההתראות כשרוצים למנוע ממדיניות התראות לשלוח התראות רק למשך פרקי זמן קצרים. לדוגמה, לפני שמבצעים תחזוקה במכונה וירטואלית (VM), אפשר ליצור השהיה ולהוסיף לקריטריונים של ההשהיה את מדיניות ההתראות שמנטרת את המופע.
כשמעבירים מדיניות התראות למצב שינה, Monitoring סוגר את כל ההתראות הפתוחות שקשורות למדיניות. המעקב יכול לפתוח התראות חדשות אחרי שההשהיה מסתיימת. מידע נוסף מופיע במאמר השהיית התראות והודעות.
מגבלות על התראות והתראות פתוחות
מדיניות התראות יכולה לחול על משאבים רבים, ובעיה שמשפיעה על כל המשאבים יכולה לגרום למדיניות ההתראות לפתוח התראות לכל משאב. התראה נפתחת לכל סדרת זמן שבה מתקיים תנאי.
כדי למנוע עומס יתר על המערכת, מספר ההתראות שמדיניות אחת יכולה לפתוח בו-זמנית מוגבל ל-1,000.
לדוגמה, נניח שיש מדיניות שחלה על 2,000 מכונות ב-Compute Engine, וכל מכונה גורמת לתנאי ההתראה להתקיים. המעקב מגביל את מספר ההתראות הפתוחות ל-1,000. כל התנאים הנותרים שמתקיימים מתעלמים מהם עד שחלק מההתראות הפתוחות לגבי המדיניות הזו נסגרות.
כתוצאה מהמגבלה הזו, ערוץ התראות יחיד יכול לקבל עד 1,000 התראות בבת אחת. אם במדיניות ההתראות שלכם יש כמה ערוצי התראות, המגבלה הזו חלה על כל ערוץ התראות בנפרד.
זמן אחזור
זמן האחזור הוא העיכוב בין הרגע שבו Monitoring דוגם מדד לבין הרגע שבו נקודת הנתונים של המדד הופכת לגלויות כנתונים בסדרת זמנים. ההשהיה משפיעה על מועד שליחת ההתראות. לדוגמה, אם מדד שנמצא במעקב כולל זמן אחזור של עד 180 שניות, מערכת המעקב לא תיצור התראה למשך עד 180 שניות אחרי שהתנאי של מדיניות ההתראות יחזיר את הערך True. מידע נוסף זמין במאמר בנושא זמן האחזור של נתוני המדדים.
האירועים וההגדרות הבאים משפיעים על זמן האחזור:
השהיה באיסוף המדדים: הזמן שנדרש ל-Monitoring כדי לאסוף את ערכי המדדים. במקרה של ערכי Google Cloud , רוב המדדים לא מוצגים במשך 60 שניות אחרי האיסוף. עם זאת, משך העיכוב תלוי במדד. החישובים של כללי מדיניות ההתראות מתבצעים עם עיכוב נוסף של עד 5 דקות ו-30 שניות. במדדים של AWS CloudWatch, יכול להיות עיכוב של כמה דקות בהצגת הנתונים. בבדיקת זמני פעילות, זה יכול להיות ממוצע של שתי דקות (מסוף חלון הבדיקה מחדש).
חלון הבדיקה מחדש: החלון שהוגדר לתנאי. התנאים מתקיימים רק אם התנאי הוא TRUE לאורך כל חלון הבדיקה מחדש. לדוגמה, אם הגדרתם חלון בדיקה מחדש של חמש דקות, יהיו עיכובים בהתראה של חמש דקות לפחות מהרגע שבו האירוע מתרחש בפעם הראשונה.
הזמן שנדרש עד שההתראה מגיעה: יכול להיות שיהיו עיכובים ברשת או עיכובים אחרים בערוצי התראות כמו אימייל ו-SMS (שלא קשורים למה שמועבר), ולפעמים העיכובים האלה יכולים להגיע לכמה דקות. בערוצים מסוימים – כמו SMS ו-Slack – אין ערובה שההודעות יימסרו.
המאמרים הבאים
למידע על יצירת מדיניות התראות, אפשר לעיין במסמכים הבאים:
במאמר מדיניות לדוגמה מופיע מגוון של כללי מדיניות להתראות.