במסמך הזה מוסבר איך תקופות ההתאמה וחלונות הבדיקה מחדש קובעים מתי מתקיים תנאי מסוים, איך מדיניות ההתראות משלבת כמה תנאים ואיך מדיניות ההתראות מחליפה נקודות נתונים חסרות. בנוסף, מוסבר שם מהו המספר המקסימלי של אירועים פתוחים לכל מדיניות, מהו מספר ההתראות לכל אירוע ומה גורם לעיכובים בהתראות.
התוכן הזה לא רלוונטי למדיניות התראות שמבוססת על יומנים. מידע על מדיניות התראות שמבוססת על יומנים זמין במאמר מעקב אחרי היומנים.
תקופות התאמה וחלונות בדיקה מחדש
Cloud Monitoring מעריך את תקופת ההתאמה ואת חלון הבדיקה מחדש כדי לקבוע אם התנאי של מדיניות ההתראות מתקיים.
תקופת ההתאמה
לפני שמדיניות התראות עוקבת אחרי נתוני סדרות זמן, צריך לבצע רגולריזציה של הנתונים כדי שמדיניות ההתראות תוכל להעריך נתונים עם מרווחים קבועים. תהליך הרגולריזציה נקרא התאמה.
תהליך ההתאמה כולל שני שלבים:
חלוקת סדרת הזמן למרווחי זמן קבועים, שנקראת גם חלוקת הנתונים לקטגוריות. המרווח הוא תקופת ההתאמה.
חישוב ערך יחיד לנקודות בתקופת ההתאמה. אתם בוחרים איך לחשב את הנקודה היחידה הזו. למשל, אפשר לסכם את כל הערכים, לחשב את הממוצע שלהם או להשתמש בערך המקסימלי. הפונקציה שממזגת את נקודות הנתונים נקראת פונקציית יישור. התוצאה של השילוב נקראת ערך מיושר.
מידע נוסף על התאמה מופיע במאמר התאמה: רגולריזציה בתוך סדרות.
לדוגמה, אם תקופת ההתאמה היא חמש דקות, בשעה 13:00, תקופת ההתאמה כוללת את הדגימות שהתקבלו בין השעות 12:55 ל-13:00. בשעה 13:01, תקופת ההתאמה מוזזת בדקה אחת וכוללת את הדגימות שהתקבלו בין השעות 12:56 ל-13:01.
המעקב מגדיר תקופת יישור באופן הבא:
מסוף Google Cloud
כדי להגדיר את תקופת ההתאמה, בוחרים ערך בשדות הבאים בדף תנאי ההתראה:
- חלון נע: מציין את טווח הזמן להערכה.
- פונקציה אנליטית (window function) מתגלגלת: מציינת את הפונקציה המתמטית שתתבצע על חלון של נקודות נתונים.
מידע נוסף על הפונקציות הזמינות מופיע במאמר 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 שולחת התראות כשהתנאי מתקיים.
שיטות מומלצות להגדרת תקופת ההתאמה וחלון הבדיקה מחדש
תקופת ההתאמה קובעת כמה דוגמאות משולבות עם הכלי להתאמה:
הערך המינימלי של תקופת ההתאמה לסוג מדד הוא תקופת הדגימה של סוג המדד הזה. לדוגמה, אם סוג המדד הוא דגימה כל 300 שניות, תקופת ההתאמה צריכה להיות לפחות 300 שניות. עם זאת, אם רוצים לשלב 5 דגימות, צריך להגדיר את תקופת ההתאמה ל-5 * 300 שניות, כלומר 1,500 שניות.
הערך המקסימלי של תקופת ההתאמה הוא 24 שעות פחות עיכוב ההטמעה של סוג המדד. לדוגמה, אם העיכוב בהוספה של מדד הוא 6 שעות, הערך המקסימלי של תקופת ההתאמה הוא 18 שעות.
משתמשים בחלון הבדיקה מחדש כדי לציין את רמת הרגישות של ההתראה. לדוגמה, אם מגדירים את חלון הבדיקה מחדש ל-20 דקות עבור תנאי של היעדר מדד, לא יכולים להיות נתונים במשך 20 דקות לפני שהתנאי מתקיים. כדי שמדיניות ההתראות תהיה רגישה יותר, מגדירים ערך קטן יותר לחלון הבדיקה מחדש. כדי שמדיניות ההתראות תהיה הכי רספונסיבית, צריך להגדיר את חלון הבדיקה מחדש לאפס בתנאים של סף המדד. ערך יחיד שמוגדר בהתאמה גורם לתנאים מהסוגים האלה להתקיים.
התנאים של מדיניות ההתראות נבדקים בתדירות קבועה. הבחירות שלכם לגבי תקופת ההתאמה וחלון הבדיקה מחדש לא קובעות את תדירות הערכת התנאי.
כללי מדיניות עם כמה תנאים
כלל מדיניות להתראות יכול להכיל עד 6 תנאים.
אם אתם משתמשים ב-Cloud Monitoring API או אם למדיניות ההתראות שלכם יש כמה תנאים, אתם צריכים לציין מתי אירוע נפתח. כדי להגדיר איך משלבים כמה תנאים, מבצעים אחת מהפעולות הבאות:
מסוף Google Cloud
מגדירים את אפשרויות השילוב בשלב 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) של המופעים. התנאי הזה מתקיים כשהשימוש במעבד של כל מופע גדול מ-100ms/s למשך דקה. - התנאי שנקרא
Excessive utilizationעוקב אחרי ניצול המעבד של המופעים. התנאי הזה מתקיים אם ניצול המעבד של מופע כלשהו גדול מ-60% למשך דקה.
בתחילה, נניח ששני התנאים מחזירים את הערך false.
לאחר מכן, נניח ששימוש המעבד (CPU) של vm1 חורג מ-100ms/s למשך דקה אחת. התנאי CPU usage is too high מתקיים כי השימוש במעבד (CPU) גדול מהסף למשך דקה אחת. אם משלבים את התנאים עם מתקיים תנאי כלשהו, נוצר אירוע כי מתקיים תנאי כלשהו. אם התנאים משולבים עם All conditions are met או עם All conditions are met even for different resources for each condition, לא נוצר אירוע. כדי להשתמש באפשרויות האלה, שני התנאים צריכים להתקיים.
עכשיו נניח ששימוש המעבד (CPU) של vm1 נשאר גבוה מ-100ms/s וניצול המעבד של vm2 חורג מ-60% למשך דקה. התוצאה היא ששני התנאים מתקיימים. בהמשך מוסבר מה קורה בהתאם לאופן שבו התנאים משולבים:
מתקיים תנאי כלשהו: אירוע נוצר כשמשאב גורם לתנאי להתקיים. בדוגמה הזו, vm2 גורם לקיום התנאי
Excessive utilization.אם מכונה וירטואלית 2 גורמת לתנאי
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 או שתיסגר באופן מיידי? באופן דומה, אם הנתונים מפסיקים להגיע ואין אירוע פתוח, האם רוצים לפתוח אירוע? לבסוף, כמה זמן צריך להשאיר תקרית פתוחה אחרי שהנתונים מפסיקים להגיע?
יש שני שדות שניתנים להגדרה ומציינים איך Monitoring מעריך תנאי סף של מדדים כשהנתונים מפסיקים להגיע:
כדי להגדיר איך המערכת של 'מעקב' קובעת את ערך ההחלפה של נתונים חסרים, משתמשים בשדה הערכה של נתונים חסרים שמוגדר בשלב הפעלת התנאי. השדה הזה מושבת כשההגדרה חלון הבדיקה מחדש מוגדרת לללא בדיקה מחדש.
חלון הבדיקה מחדש הוא השדה שנקרא duration ב-Cloud Monitoring API.
כדי להגדיר כמה זמן יחכה Monitoring לפני סגירת אירוע פתוח אחרי שהנתונים מפסיקים להגיע, משתמשים בשדה משך הזמן לסגירה אוטומטית של אירוע. מגדירים את משך הזמן של הסגירה האוטומטית בשלב ההתראה. משך הזמן שמוגדר כברירת מחדל לסגירה אוטומטית הוא שבעה ימים.
בהמשך מפורטות האפשרויות השונות לשדה הנתונים החסר:
| Google Cloud console השדה 'הערכה של נתונים חסרים' |
סיכום | פרטים |
|---|---|---|
| Missing data empty | אירועים פתוחים יישארו פתוחים. לא נפתחים אירועים חדשים. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם תקרית פתוחה עבור התנאי הזה, התקרית נשארת פתוחה. כשאירוע פתוח ולא מתקבלים נתונים, טיימר הסגירה האוטומטית מתחיל לפעול אחרי השהיה של לפחות 15 דקות. אם הטיימר יגיע לסיום, התקרית תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
| נקודות נתונים חסרות נחשבות כערכים שמפירים את תנאי המדיניות | אירועים פתוחים יישארו פתוחים. אפשר לפתוח אירועים חדשים. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם תקרית פתוחה עבור התנאי הזה, התקרית נשארת פתוחה. אם אירוע פתוח ולא מתקבלים נתונים במשך משך הזמן לסגירה אוטומטית בתוספת 24 שעות, האירוע נסגר. אם התנאים לא מתקיימים, ההגדרה הזו גורמת לתנאי של סף מדד להתנהג כמו |
| נקודות נתונים חסרות נחשבות כערכים שלא מפרים את תנאי המדיניות | אירועים פתוחים נסגרים. לא נפתחים אירועים חדשים. |
אם התנאים מתקיימים, הם יפסיקו להתקיים כשהנתונים יפסיקו להגיע. אם תקרית פתוחה עבור התנאי הזה, התקרית תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
API
אתם יכולים להגדיר איך מערכת המעקב תעריך תנאי של סף מדד כשנתונים מפסיקים להגיע. לדוגמה, אם תקרית פתוחה ומדידה צפויה לא מגיעה, האם אתם רוצים שהתקרית תישאר פתוחה ב-Monitoring או שתיסגר באופן מיידי? באופן דומה, אם הנתונים מפסיקים להגיע ואין אירוע פתוח, האם רוצים לפתוח אירוע? לבסוף, כמה זמן צריך להשאיר תקרית פתוחה אחרי שהנתונים מפסיקים להגיע?
יש שני שדות שניתנים להגדרה ומציינים איך Monitoring מעריך תנאי סף של מדדים כשהנתונים מפסיקים להגיע:
כדי להגדיר איך כלי המעקב קובע את ערך ההחלפה לנתונים חסרים, משתמשים בשדה
evaluationMissingDataשל מבנהMetricThreshold. המערכת מתעלמת מהשדה הזה אם הערך בשדהdurationהוא אפס.כדי להגדיר כמה זמן ימתין שירות הניטור לפני סגירת אירוע פתוח אחרי שהנתונים מפסיקים להגיע, משתמשים בשדה
autoCloseבמבנהAlertStrategy.
בהמשך מפורטות האפשרויות השונות לשדה הנתונים החסר:
APIevaluationMissingData field |
סיכום | פרטים |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
אירועים פתוחים יישארו פתוחים. לא נפתחים אירועים חדשים. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם תקרית פתוחה עבור התנאי הזה, התקרית תישאר פתוחה. כשאירוע פתוח ולא מתקבלים נתונים, טיימר הסגירה האוטומטית מתחיל לפעול אחרי השהיה של לפחות 15 דקות. אם הטיימר יפוג, התקרית תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
EVALUATION_MISSING_DATA_ACTIVE |
אירועים פתוחים יישארו פתוחים. אפשר לפתוח אירועים חדשים. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם תקרית פתוחה עבור התנאי הזה, התקרית תישאר פתוחה. אם אירוע פתוח ולא מתקבלים נתונים במשך פרק הזמן שמוגדר לסגירה אוטומטית בתוספת 24 שעות, האירוע נסגר. אם התנאים לא מתקיימים, ההגדרה הזו גורמת לתנאי של סף מדד להתנהג כמו |
EVALUATION_MISSING_DATA_INACTIVE |
אירועים פתוחים נסגרים. לא נפתחים אירועים חדשים. |
אם התנאים מתקיימים, הם יפסיקו להתקיים כשהנתונים יפסיקו להגיע. אם תקרית פתוחה עבור התנאי הזה, התקרית תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
כדי לצמצם את הבעיות שנובעות מנתונים חסרים, אפשר לבצע אחת מהפעולות הבאות:
- כדי לזהות דרכים להפחתת זמן האחזור של איסוף המדדים, צריך לפנות לספק שירותי הענן מצד שלישי.
- כדאי להשתמש בחלונות ארוכים יותר לבדיקה חוזרת בתנאים. החיסרון בשימוש בחלון זמן ארוך יותר לבדיקה מחדש הוא שמדיניות ההתראות תהיה פחות רגישה.
מומלץ לבחור מדדים עם עיכוב נמוך יותר באיסוף:
- מדדים של סוכן Monitoring, במיוחד כשהסוכן פועל במכונות וירטואליות בעננים של צד שלישי.
- מדדים מותאמים אישית, כשכותבים את הנתונים שלהם ישירות ל-Monitoring.
- מדדים מבוססי-יומנים, אם איסוף רשומות היומן לא מתעכב.
מידע נוסף זמין במאמרים סקירה כללית של סוכן Monitoring, סקירה כללית של מדדים מוגדרים על ידי המשתמש ומדדים מבוססי-יומן.
מתי המערכת של Monitoring שולחת התראות ויוצרת אירועים
Cloud Monitoring שולח התראה כשסדרת זמן גורמת לתנאי להתקיים. ההתראה נשלחת לכל הערוצים של ההתראות. אי אפשר להגביל את ההתראה לערוץ ספציפי או לקבוצת משנה של הערוצים שכלולים במדיניות.
אם מגדירים התראות חוזרות, אותה התראה נשלחת מחדש לערוצי התראות ספציפיים במדיניות ההתראות.
יכול להיות שתקבלו כמה התראות ייחודיות שקשורות למדיניות התראות אחת, אם אחד מהתנאים הבאים מתקיים:
תנאי מסוים עוקב אחרי כמה סדרות זמן.
מדיניות מכילה מספר תנאים. במקרה כזה, ההתראות שתקבלו תלויות בערך של הטריגר מרובה התנאים של מדיניות ההתראות:
כל התנאים מתקיימים: כשכל התנאים מתקיימים, לכל סדרת זמן שגורמת לתנאי להתקיים, מדיניות ההתראות שולחת התראה ויוצרת אירוע.
אי אפשר להגדיר את Cloud Monitoring כך שייווצר רק אירוע אחד ותישלח רק התראה אחת כשמדיניות ההתראות מכילה כמה תנאים.
מתקיים תנאי כלשהו: מדיניות ההתראות שולחת התראה כשסדרת זמן גורמת לתנאי להתקיים.
מידע נוסף מופיע במאמר בנושא כללי מדיניות עם כמה תנאים.
מדיניות התראות שנוצרת באמצעות Cloud Monitoring API גם שולחת לכם התראה כשהתנאי מתקיים וכשהתנאי מפסיק להתקיים. מדיניות התראות שנוצרה באמצעות מסוף Google Cloud לא שולחת הודעה כשהתנאי מפסיק להתקיים, אלא אם הפעלתם את ההתנהגות הזו.
מתי המערכת של 'מעקב' לא שולחת התראות או יוצרת אירועים
במצבים הבאים, Monitoring לא יוצר אירועים או שולח התראות כשמתקיימים התנאים של מדיניות התראות:
- מדיניות ההתראות מושבתת.
- מדיניות ההתראות מושהית.
- הגעתם למגבלה של מספר האירועים הפתוחים המקסימלי.
מדיניות התראות מושבתת
אם מדיניות ההתראות מושבתת, המערכת לא שולחת התראות ולא יוצרת אירועים. עם זאת, המערכת ממשיכה להעריך את התנאים של מדיניות התראות מושבתת.
כשמפעילים מדיניות מושבתת, המערכת של Monitoring מעריכה את הערכים של כל התנאים במהלך חלון הבדיקה מחדש האחרון. חלון הבדיקה מחדש האחרון עשוי לכלול נתונים שנאספו לפני, במהלך ואחרי הפעלת המדיניות. אפשר לעמוד בתנאים של מדיניות מושבתת מיד אחרי שמפעילים אותה מחדש, גם אם חלונות הבדיקה מחדש גדולים.
לדוגמה, נניח שיש לכם מדיניות התראות שעוקבת אחרי תהליך ספציפי והשבתתם את המדיניות הזו. בשבוע שלאחר מכן, התהליך נכשל, ולא תקבלו התראה כי מדיניות ההתראות מושבתת. אם מפעילים מחדש את התהליך ומפעילים את מדיניות ההתראות באופן מיידי, מערכת Monitoring מזהה שהתהליך לא פעל בחמש הדקות האחרונות ופותחת אירוע.
האירועים שקשורים למדיניות התראות שהושבתה יישארו פתוחים עד שתוקף משך הסגירה האוטומטית של המדיניות יפוג.
כללי מדיניות התראות שהושהו
המעקב לא שולח התראות או יוצר אירועים עבור מדיניות התראות שמושהית. מומלץ להשהות את מדיניות ההתראות כשרוצים למנוע ממדיניות התראות לשלוח התראות רק למשך פרקי זמן קצרים. לדוגמה, לפני שמבצעים תחזוקה במכונה וירטואלית (VM), אפשר ליצור השהיה ולהוסיף לקריטריונים של ההשהיה את מדיניות ההתראות שמנטרת את המופע.
כשמשעים מדיניות התראה, מערכת Monitoring סוגרת את כל האירועים הפתוחים שקשורים למדיניות. המעקב יכול לפתוח תקריות חדשות אחרי שתקופת ההשהיה מסתיימת. מידע נוסף מופיע במאמר השהיית התראות ואירועים.
המגבלות על התראות ועל אירועים פתוחים
מדיניות התראות יכולה לחול על משאבים רבים, ובעיה שמשפיעה על כל המשאבים יכולה לגרום למדיניות ההתראות לפתוח אירועים לכל משאב. אירוע נפתח לכל סדרת זמן שגורמת להשגת תנאי.
כדי למנוע עומס יתר על המערכת, מספר האירועים שמדיניות אחת יכולה לפתוח בו-זמנית מוגבל ל-1,000.
לדוגמה, נניח שיש מדיניות שחלה על 2,000 מכונות של Compute Engine, וכל מכונה גורמת להתקיימות תנאי ההתראה. הניטור מגביל את מספר האירועים הפתוחים ל-1,000. המערכת מתעלמת מכל התנאים הנותרים שמתקיימים עד שחלק מהאירועים הפתוחים שקשורים למדיניות הזו נסגרים.
כתוצאה מהמגבלה הזו, ערוץ התראות יחיד יכול לקבל עד 1,000 התראות בבת אחת. אם למדיניות ההתראות שלכם יש כמה ערוצי התראות, המגבלה הזו חלה על כל ערוץ התראות בנפרד.
זמן אחזור
זמן האחזור הוא העיכוב בין הרגע שבו Monitoring דוגם מדד לבין הרגע שבו נקודה על הגרף של המדד הופכת לזמינה כנתונים בסדרת זמנים. ההשהיה משפיעה על מועד שליחת ההתראות. לדוגמה, אם למדד במעקב יש זמן אחזור של עד 180 שניות, אז Monitoring לא ייצור אירוע למשך עד 180 שניות אחרי שהתנאי של מדיניות ההתראות יחזיר את הערך true. מידע נוסף זמין במאמר בנושא זמן האחזור של נתוני המדדים.
האירועים וההגדרות הבאים משפיעים על זמן האחזור:
השהיה באיסוף המדדים: הזמן שנדרש ל-Monitoring כדי לאסוף את ערכי המדדים. במקרה של ערכי Google Cloud , רוב המדדים לא מוצגים במשך 60 שניות אחרי האיסוף, אבל משך העיכוב תלוי במדד. חישובים של מדיניות התראות מתבצעים עם עיכוב נוסף של עד 5 דקות ו-30 שניות. במדדים של AWS CloudWatch, יכול להיות עיכוב של כמה דקות בהצגת הנתונים. בבדיקת זמני פעילות, זה יכול להיות ממוצע של שתי דקות (מסוף חלון הבדיקה מחדש).
חלון הבדיקה מחדש: חלון הזמן שהוגדר לתנאי. התנאים מתקיימים רק אם התנאי הוא TRUE לאורך כל חלון הבדיקה מחדש. לדוגמה, אם חלון הבדיקה מחדש מוגדר לחמש דקות, יהיו עיכובים בהתראה של חמש דקות לפחות מהרגע שבו האירוע מתרחש.
הזמן שנדרש עד שההתראה מגיעה: יכול להיות שיהיו עיכובים ברשת או עיכובים אחרים בערוצי התראות כמו אימייל ו-SMS (שלא קשורים למה שמועבר), ולפעמים העיכובים האלה יכולים להגיע לכמה דקות. בערוצים מסוימים – כמו SMS ו-Slack – אין ערובה לכך שההודעות יימסרו.
המאמרים הבאים
למידע על יצירת מדיניות התראות, אפשר לעיין במסמכים הבאים:
במאמר מדיניות לדוגמה מופיע מגוון של כללי מדיניות להתראות.