במסמך הזה מתואר איך תקופות ההתאמה וחלונות הבדיקה מחדש קובעים מתי מתקיים תנאי מסוים, איך מדיניות התראות משלבת כמה תנאים ואיך מדיניות התראות מחליפה נקודות נתונים חסרות. בנוסף, מוסבר כאן מהו המספר המקסימלי של אירועים פתוחים עבור מדיניות מסוימת, מהו מספר ההתראות לכל אירוע, ומה גורם לעיכובים בהתראות.
התוכן הזה לא רלוונטי למדיניות התראות שמבוססת על יומנים. מידע על מדיניות התראות שמבוססת על יומנים זמין במאמר מעקב אחרי היומנים.
תקופות התאמה וחלונות בדיקה מחדש
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 שולחת התראות כשהתנאי מתקיים.
שיטות מומלצות להגדרת תקופת ההתאמה וחלון הבדיקה מחדש
תקופת ההתאמה קובעת כמה דגימות יאוחדו על ידי הכלי להתאמה. הגדרת תקופת ההתאמה מושפעת ממרווח הדגימה, מהעיכוב בהעברה וממספר הדגימות שרוצים לשלב:
תקופת ההתאמה לא יכולה להיות ארוכה מ-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 combiner value |
משמעות |
|---|---|---|
| מתקיים אחד מהתנאים | 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.
לאחר מכן, נניח שהשימוש במעבד של vm1 חורג מ-100ms/s למשך דקה אחת. התנאי CPU usage is too high מתקיים כי השימוש במעבד (CPU) גבוה מהסף למשך דקה אחת. אם התנאים משולבים עם 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להתקיים.אם מכונה וירטואלית 2 גורמת לתנאי
CPU usage is too highלהתקיים, גם במקרה הזה נוצר אירוע. התקרית נוצרת כי vm1 ו-vm2 שגורמים לתנאיCPU usage is too highלהתקיים הם אירועים שונים.כל התנאים מתקיימים, גם אם מדובר במשאבים שונים לכל תנאי: נוצר אירוע כי שני התנאים מתקיימים.
כל התנאים מתקיימים: לא נוצר אירוע כי כדי שהמשלב הזה יפעל, אותו משאב צריך לגרום לכל התנאים להתקיים. בדוגמה הזו, לא נוצר אירוע כי vm1 גורם להשגת התנאי
CPU usage is too high, ו-vm2 גורם להשגת התנאיExcessive utilization.
נתוני מדדים חלקיים
אם נתוני סדרת הזמן מפסיקים להגיע או אם יש עיכוב בהגעת הנתונים, המערכת של Monitoring מסווגת את הנתונים כחסרים. נתונים חסרים יכולים למנוע סגירה של אירועים. העיכובים בהגעת הנתונים מספקי ענן של צד שלישי יכולים להגיע ל-30 דקות, והעיכובים הנפוצים ביותר הם של 5 עד 15 דקות. אם יש עיכוב ארוך – ארוך יותר מחלון הבדיקה מחדש – התנאים יכולים לעבור למצב 'לא ידוע'. כשהנתונים מגיעים בסופו של דבר, יכול להיות שחלק מההיסטוריה האחרונה של התנאים אבדה ב'מעקב'. בבדיקה מאוחרת יותר של נתוני הסדרה העיתית, יכול להיות שהבעיה הזו לא תופיע כי אין הוכחות לעיכובים אחרי שהנתונים מגיעים.
מסוף 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 |
סיכום | פרטים |
|---|---|---|
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 לא שולחת הודעה כשהתנאי מפסיק להתקיים, אלא אם הפעלתם את ההתנהגות הזו.
מתי המערכת של 'מעקב' לא שולחת התראות או יוצרת אירועים
במצבים הבאים, המערכת של 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 – אין ערובה שההודעות יימסרו.
המאמרים הבאים
למידע על יצירת מדיניות התראות, אפשר לעיין במסמכים הבאים:
מגוון של כללי מדיניות בנושא התראות מופיע במאמר דוגמאות לכללי מדיניות.