מדיניות התראות מבוססת-מדדים ב-Cloud Monitoring מאפשרת לכם לעקוב אחרי נתונים של סדרות זמן, ליצור התראות ולשלוח אותן. אתם יכולים לקבוע מתי כללי מדיניות ההתראות ייצרו התראות וישלחו אותן, על ידי הגדרת תקופות התאמה, חלונות בדיקה חוזרת וכללים עם כמה תנאים. כדי לצמצם את מספר ההתראות החיוביות השגויות ולכוונן את מהירות התגובה של ההתראות, חשוב להבין איך מדיניות ההתראות מטפלת בנתונים חסרים, מהן המגבלות על התראות ומהם העיכובים בהתראות.
התוכן הזה לא רלוונטי למדיניות התראות שמבוססות על יומנים. למידע על מדיניות התראות מבוססות-יומנים, ראו מעקב אחרי היומנים.
תקופות התאמה וחלונות זמן לבדיקה חוזרת
כדי לקבוע אם התנאי של מדיניות ההתראה מתקיים, המערכת של Cloud Monitoring בודקת את תקופת ההתאמה ואת חלון הבדיקה החוזרת.
תקופת התאמה
לפני שמדיניות התראה מנטרת נתונים של סדרת זמנים, צריך להסדיר אותם כדי שלמדיניות ההתראה יהיו נתונים במרווחים קבועים להערכה. תהליך ההסדרה נקרא התאמה.
ההתאמה כוללת שני שלבים:
חלוקת סדרת הזמנים למרווחי זמן קבועים, שנקראת גם חלוקת הנתונים לקטגוריות. המרווח הוא תקופת ההתאמה.
חישוב ערך יחיד לנקודות בתקופת ההתאמה. אתם בוחרים איך לחשב את הנקודה הבודדת הזו. אתם יכולים לסכם את כל הערכים, לחשב את הממוצע שלהם או להשתמש בערך המקסימלי. הפונקציה שמשלבת את הנקודות על הגרף נקראת aligner. התוצאה של השילוב נקראת הערך המותאם.
למידע נוסף על התאמה, ראו התאמה: רגולריזציה בתוך סדרה.
לדוגמה, אם תקופת ההתאמה היא חמש דקות, בשעה 13:00 תקופת ההתאמה תכלול את הדגימות שהתקבלו בין 12:55 ל-13:00. בשעה 13:01, תקופת ההתאמה זזה בדקה אחת ומכילה את הדגימות שהתקבלו בין השעות 12:56 ו-13:01.
המעקב מגדיר תקופת התאמה באופן הבא:
מסוף Google Cloud
כדי להגדיר את תקופת ההתאמה, בוחרים ערך בשדות הבאים בדף תנאים להתראה:
- חלון זמן דינמי: מציין את טווח הזמן להערכה.
- פונקציית חלון זמן דינמי: מציינת את הפונקציה המתמטית שצריך לבצע בחלון של נקודות על הגרף.
מידע נוסף על הפונקציות הזמינות מופיע בקטע Aligner במאמרי העזרה של ה-API. חלק מפונקציות ההתאמה גם מתאימות את הנתונים וגם ממירות אותם מסוג מדד אחד לאחר. הסבר מפורט מופיע במאמר סוגים, טיפוסים והמרות.
API
כדי להגדיר את תקופת ההתאמה, מגדירים את השדות aggregations.alignmentPeriod ו-aggregations.perSeriesAligner במבנים MetricThreshold ו-MetricAbsence.
מידע נוסף על הפונקציות הזמינות מופיע בקטע Aligner במאמרי העזרה של ה-API. חלק מפונקציות ההתאמה גם מתאימות את הנתונים וגם ממירות אותם מסוג מדד אחד לאחר. הסבר מפורט מופיע במאמר סוגים, טיפוסים והמרות.
כדי להמחיש את ההשפעה של תקופת ההתאמה על תנאי במדיניות התראה, נבחן תנאי של סף מדד שעוקב אחרי מדד עם תקופת דגימה של דקה אחת. נניח שתקופת ההתאמה מוגדרת ל-5 דקות, ושההתאמה מוגדרת ל-sum. נניח גם שהתנאי מתקיים כשהערך המיושר של סדרת הזמנים גדול מ-2 למשך 3 דקות לפחות, ושהתנאי נבדק כל דקה.
בדוגמה הזו, חלון הבדיקה החוזרת, שמתואר בקטע הבא, הוא שלוש דקות. באיור הבא מוצגות כמה הערכות עוקבות של התנאי:
כל שורה באיור ממחישה הערכה אחת של התנאי. הנתונים של פעולות על ציר הזמן מוצגים. הנקודות בתקופת ההתאמה מוצגות בנקודות כחולות, ונקודות ישנות יותר מוצגות בנקודות שחורות. בכל שורה מוצג הערך המותאם, וגם אם הערך הזה גדול מהסף של שתיים. בשורה עם התווית start, הערך המותאם מחושב כאחד, שהוא קטן מהסף.
בבדיקה הבאה, סכום הדגימות בתקופת ההתאמה הוא שתיים.
בבדיקה השלישית, הסכום הוא שלוש, ומכיוון שהערך הזה גדול מהסף, מופעל טיימר לחלון הבדיקה החוזרת.
חלונות זמן לבדיקה חוזרת
לתנאי של מדיניות ההתראה יש חלון בדיקה חוזרת, שמונע את קיום התנאי בגלל מדידה או תחזית בודדת. לדוגמה, נניח שחלון הבדיקה החוזרת של תנאי מסוים מוגדר ל-15 דקות. כאן מתוארת ההתנהגות של התנאי בהתאם לסוג שלו:
- תנאים של סף מדד מתקיימים כשבסדרת זמנים אחת, כל מדידה מותאמת במרווח זמן של 15 דקות חורגת מהסף.
- תנאים של היעדר מדדים מתקיימים כשלא מגיעים נתונים לסדרת זמן במרווח של 15 דקות.
- תנאי התחזית מתקיימים כשכל תחזית שנוצרת במהלך חלון של 15 דקות צופה שסדרת הזמן תחרוג מהסף בתוך חלון התחזית.
בכללי מדיניות עם תנאי אחד, נפתחת התראה ונשלחות התראות כשהתנאי מתקיים. ההתראות האלה נשארות פתוחות כל עוד התנאי ממשיך להתקיים.
מסוף Google Cloud
כדי להגדיר את חלון הבדיקה החוזרת, משתמשים בשדה Retest window בשלב Configure alert trigger.
API
כדי להגדיר את חלון הבדיקה החוזרת, מגדירים את השדה duration במבנים MetricThreshold ו-MetricAbsence.
באיור הקודם מוצגות שלוש הערכות של תנאי סף למדד. בזמן start + 2 minutes, הערך המיושר גדול מהסף, אבל התנאי לא מתקיים כי חלון הבדיקה החוזרת מוגדר ל-3 דקות. האיור הבא ממחיש את התוצאות של הערכות התנאי הבאות:
למרות שהערך המותאם גדול מהסף בזמן start + 2 minutes, התנאי לא מתקיים עד שהערך המותאם גדול מהסף במשך שלוש דקות. האירוע הזה מתרחש בשעה start + 5 minutes.
חלון הבדיקה החוזרת של התנאי מתאפס בכל פעם שמדידה או תחזית לא עומדות בתנאי. לכן, הגדירו חלון בדיקה חוזרת ארוך מספיק כדי לצמצם את מספר ההתראות החיוביות השגויות, אבל קצר מספיק כדי לוודא שההתראות נפתחות בזמן. ההתנהגות הזו מודגמת בדוגמה הבאה:
דוגמה
מדיניות ההתראה הזו מכילה תנאי אחד של סף מדד שמציין חלון בדיקה חוזרת של חמש דקות.
אם זמן האחזור של תגובת ה-HTTP גדול משתי שניות,
ואם זמן האחזור גדול מהסף למשך חמש דקות,
אז פותחים התראה ושולחים אימייל לצוות התמיכה.
הרצף הבא ממחיש איך חלון הבדיקה החוזרת משפיע על הערכת התנאי:
- זמן האחזור של HTTP הוא פחות משתי שניות.
- בשלוש הדקות הבאות, זמן האחזור של HTTP גדול משתי שניות.
- במדידה הבאה, זמן האחזור קצר משתי שניות, ולכן התנאי מאפס את חלון הבדיקה החוזרת.
בחמש הדקות הבאות, זמן האחזור של HTTP גדול משתי שניות, ולכן התנאי מתקיים.
מכיוון שמדיניות ההתראות כוללת תנאי אחד, מערכת Monitoring שולחת התראות כשהתנאי מתקיים.
שיטות מומלצות להגדרת תקופת ההתאמה וחלון הבדיקה החוזרת
כדי להגדיר מדיניות התראה שבודקת באופן מהימן בלי התראות שווא, צריך להגדיר את תקופת ההתאמה ואת חלון הבדיקה החוזרת בהתאם לתרחיש לדוגמה.
הגדרת תקופת ההתאמה
תקופת ההתאמה קובעת כמה דגימות המערכת משלבת למדידה מצטברת. כשמגדירים את תקופת ההתאמה, חשוב להביא בחשבון את מרווח הדגימה של המדד ואת העיכוב בהטמעה:
תקופת התאמה מינימלית: תקופת ההתאמה חייבת להיות לפחות 60 שניות (דקה אחת) וכפולה של מספר שלם של 60 שניות. כדי לוודא שכל חלון התאמה כולל נתונים מייצגים, צריך להגדיר את תקופת ההתאמה לפחות למרווח הדגימה של המדד, מעוגל כלפי מעלה לכפולה של 60 שניות. לדוגמה, למדד שנדגם כל 30 שניות, הגדירו את תקופת ההתאמה ל-60 שניות לפחות.
עיכוב בהטמעה: נתוני המדדים נאספים ומוטמעים לפני שהם מגיעים ל-Monitoring. כשמערכת Monitoring בודקת את כללי ההתראה, היא מעבירה את זמני הבדיקה לעבר כדי להביא בחשבון את עיכוב ההטמעה הצפוי של כל מדד – בדרך כלל לפחות 60 שניות, עם עיכובים קצרים יותר למדדים כמו בדיקות זמינות ועיכובים ארוכים יותר למדדים עם זמן אחזור גבוה יותר, כמו מדדים מבוססי-יומנים שהוגדרו על ידי המשתמש או מדדי ענן של צד שלישי. עם זאת, אם במדד חיצוני או של צד שלישי יש השהיית הטמעה משתנה שחורגת מהעיכוב המובנה, צריך לבחור תקופת התאמה רחבה מספיק כדי לתעד כמה מרווחי דגימה, כך שדגימות מושהות לא ייצרו חלונות התאמה ריקים.
תקופת ההתאמה המקסימלית: בתנאים של סף למדד, תקופת ההתאמה יכולה להיות עד 25 שעות. בתנאים מסוג metric-absence, הסכום של תקופת ההתאמה וחלון הבדיקה החוזרת לא יכול להיות יותר מ-25 שעות. אם אתם צריכים להעריך מגמות היסטוריות בחלונות מבט לאחור של יותר מ-25 שעות (עד שנתיים), השתמשו ב-PromQL. בכללי התראה של PromQL עם חלון מבט לאחור של יותר מ-25 שעות, חלון הבדיקה החוזרת (
duration) צריך להיות אפס, ואי אפשר להשתמש במדדים מותאמים אישית או במדדים מבוססי-יומנים. בנוסף, מרווחי ההערכה המינימליים גדלים בהתאם למשך חלון המבט לאחור:- 25 שעות ו-10 דקות עד 8 ימים: 5 דקות
- 8 עד 16 ימים: שעה אחת
- 16 עד 32 ימים: שעתיים
- 32 עד 93 ימים: 6 שעות
- 93 ימים עד שנתיים: 12 שעות
למידע נוסף, קראו את המאמר שימוש ב-PromQL ליצירת מדיניות התראות.
הגדרת חלון הזמנים לבדיקה חוזרת
חלון הבדיקה החוזרת (duration) מציין כמה זמן סדרת הזמן צריכה לחרוג באופן רציף מהסף של התנאי לפני שמערכת Monitoring פותחת התראה:
תגובה: בתנאים של ערכי סף למדדים, אם מגדירים את חלון הבדיקה החוזרת ל-0 (מוצג במסוף Google Cloud בתור No retest), נפתחת התראה כשמדידה מותאמת אחת חורגת מערך הסף. בתנאים של היעדר מדדים, הנתונים צריכים להיות חסרים בכל חלון הבדיקה החוזרת כדי שהתנאי יתקיים.
הימנעות מהתראות שווא: כדי להימנע מהתראות שווא שנגרמות כתוצאה מעליות חדות זמניות, תנודות בהערכה או שונות באיסוף המדדים, הגדירו את חלון הבדיקה החוזרת ל-180 שניות (3 דקות) לפחות. אם מגדירים את חלון הבדיקה החוזרת ל-0, תיפתח התראה על נקודה חריגה אחת.
התנאים של מדיניות ההתראות נבדקים בתדירות קבועה, אלא אם משתמשים ב-PromQL. ב-PromQL, תדירות ההערכה יכולה להשתנות בהתאם למשך החיפוש לאחור של השאילתה.
כללי מדיניות עם כמה תנאים
מדיניות התראה יכולה להכיל עד 6 תנאים.
אם אתם משתמשים ב-Cloud Monitoring API או אם למדיניות ההתראות יש כמה תנאים, אתם צריכים לציין מתי נפתחת התראה. כדי להגדיר איך לשלב כמה תנאים, מבצעים אחת מהפעולות הבאות:
מסוף Google Cloud
אתם מגדירים את אפשרויות השילוב בשלב טריגר עם כמה תנאים.
API
מגדירים את אפשרויות השילוב באמצעות השדה combiner של המבנה AlertPolicy.
בטבלה הבאה מפורטות ההגדרות במסוף Google Cloud , הערך המקביל ב-Cloud Monitoring API ותיאור של כל הגדרה:
| ערך הטריגרים של המדיניותGoogle Cloud console |
ערך המשלב של 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. נניח גם שיצרתם מדיניות התראה עם שני תנאים:
- התנאי שנקרא
CPU usage is too highעוקב אחרי השימוש במעבד (CPU) של המכונות. התנאי הזה מתקיים כששימוש במעבד (CPU) של כל מכונה הוא יותר מ-100ms/s למשך דקה אחת. - התנאי שנקרא
Excessive utilizationעוקב אחרי ניצול המעבד (CPU) של המכונות. התנאי הזה מתקיים כשניצול המעבד (CPU) של כל מכונה גדול מ-60% למשך דקה אחת.
בהתחלה, נניח ששני התנאים מחזירים את הערך false.
עכשיו נניח שהשימוש במעבד (CPU) של vm1 חורג מ-100ms/s למשך דקה אחת. מכיוון שהשימוש במעבד (CPU) גבוה מהסף למשך דקה, התנאי CPU usage is too high מתקיים. אם התנאים משולבים עם כל תנאי שמתקיים, נוצרת התראה כי אחד מהתנאים מתקיים. אם התנאים משולבים עם All conditions are met או עם All conditions are met even for different resources for each condition, לא נוצרת התראה. כדי להשתמש באפשרויות השילוב האלה, שני התנאים צריכים להתקיים.
עכשיו נניח שהשימוש במעבד (CPU) של vm1 נשאר מעל 100ms/s, ושהניצול של המעבד (CPU) של vm2 חורג מ-60% למשך דקה. התוצאה היא ששני התנאים מתקיימים. בטבלה הבאה מתואר מה קורה בהתאם לשילוב של התנאים:
Any condition is met: התראה נוצרת כשמשאב גורם לתנאי להתקיים. בדוגמה הזו, 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.
נתוני מדדים חלקיים
כשנתונים של סדרת זמנים מפסיקים להגיע או כשהם מתעכבים, מערכת Monitoring מסווגת אותם כחסרים. אם חסרים נתונים, יכול להיות שההתראות לא ייסגרו. עיכובים בהגעת נתונים מספקי שירותי ענן של צד שלישי יכולים להגיע עד 30 דקות, אבל בדרך כלל העיכובים הם של 5 עד 15 דקות. עיכוב ארוך – יותר מחלון הבדיקה החוזרת – יכול לגרום לתנאים להיכנס למצב "לא ידוע". כשהנתונים מגיעים בסופו של דבר, יכול להיות שחלק מההיסטוריה האחרונה של התנאים ב-Monitoring אבדה. יכול להיות שבבדיקה מאוחרת יותר של נתוני הסדרות העיתיות הבעיה הזו לא תופיע, כי אין ראיות לעיכובים אחרי שהנתונים מגיעים.
מסוף Google Cloud
אתם יכולים להגדיר איך המערכת תעריך תנאי של סף מדד כשנתונים מפסיקים להגיע. לדוגמה, כשנפתחת התראה ומדידה צפויה לא מגיעה, האם אתם רוצים ש-Monitoring ישאיר את ההתראה פתוחה או יסגור אותה מיד? באופן דומה, כשנתונים מפסיקים להגיע ואין התראה פתוחה, האם אתם רוצים שתיפתח התראה? ולסיום, כמה זמן ההתראה צריכה להישאר פתוחה אחרי שהנתונים מפסיקים להגיע?
יש שני שדות שאפשר להגדיר, שמציינים איך מערכת Monitoring מעריכה תנאים של סף מדדים כשנתונים מפסיקים להגיע:
כדי להגדיר איך המערכת תקבע את הערך החלופי לנתונים החסרים, משתמשים בשדה Evaluation of missing data, שאותו מגדירים בשלב Condition trigger. השדה הזה מושבת כשחלון הבדיקה החוזרת מוגדר לערך No retest.
חלון הבדיקה החוזרת הוא השדה שנקרא duration ב-Cloud Monitoring API.
כדי להגדיר כמה זמן מערכת Monitoring תחכה לפני שהיא תסגור התראה פתוחה אחרי שהנתונים יפסיקו להגיע, משתמשים בשדה Alert autoclose duration. את משך הזמן לסגירה האוטומטית מגדירים בשלב ההתראה. משך הזמן שמוגדר כברירת מחדל לסגירה אוטומטית הוא שבעה ימים.
האפשרויות השונות לשדה הנתונים החסר:
| Google Cloud מסוף השדה "הערכה של נתונים חסרים" |
סיכום | פרטים |
|---|---|---|
| נתונים חסרים | התראות פתוחות נשארות פתוחות. התראות של חדשות Google חדשות לא נפתחות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם יש התראה פתוחה לגבי התנאי הזה, היא תישאר פתוחה. כשהתראה פתוחה ולא מגיעים נתונים, הטיימר לסגירה אוטומטית מתחיל אחרי עיכוב של 15 דקות לפחות. אם הטיימר מסתיים, ההתראה נסגרת. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
| נקודות נתונים חסרות נחשבות כערכים שמפירים את תנאי המדיניות | התראות פתוחות נשארות פתוחות. אפשר לפתוח התראות חדשות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם יש התראה פתוחה לגבי התנאי הזה, היא תישאר פתוחה. אם התראה פתוחה ולא מגיעים נתונים במשך פרק הזמן לסגירה אוטומטית ועוד 24 שעות, ההתראה נסגרת. בתנאים שלא מתקיימים, ההגדרה הזו גורמת לתנאי metric-threshold להתנהג כמו |
| נקודות נתונים חסרות מטופלות כערכים שלא מפרים את תנאי המדיניות | ההתראות הפתוחות נסגרות. התראות של חדשות Google חדשות לא נפתחות. |
אם התנאים מתקיימים, הם מפסיקים להתקיים כשנתונים מפסיקים להגיע. אם יש התראה פתוחה לגבי התנאי הזה, ההתראה תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים גם כשהנתונים יפסיקו להגיע. |
API
אתם יכולים להגדיר איך המערכת תעריך תנאי של סף מדד כשנתונים מפסיקים להגיע. לדוגמה, כשנפתחת התראה ומדידה צפויה לא מגיעה, האם אתם רוצים ש-Monitoring ישאיר את ההתראה פתוחה או יסגור אותה מיד? באופן דומה, כשנתונים מפסיקים להגיע ואין התראה פתוחה, האם אתם רוצים שתיפתח התראה? ולסיום, כמה זמן ההתראה צריכה להישאר פתוחה אחרי שהנתונים מפסיקים להגיע?
יש שני שדות שאפשר להגדיר, שמציינים איך מערכת Monitoring מעריכה תנאים של סף מדדים כשנתונים מפסיקים להגיע:
כדי להגדיר איך המערכת תקבע את הערך החלופי לנתונים החסרים, משתמשים בשדה
evaluationMissingDataשל המבנהMetricThreshold. המערכת מתעלמת מהשדה הזה כשהערך בשדהdurationהוא אפס.כדי להגדיר כמה זמן Monitoring ימתין לפני סגירת התראה פתוחה אחרי שהנתונים יפסיקו להגיע, משתמשים בשדה
autoCloseבמבנהAlertStrategy.
האפשרויות השונות לשדה הנתונים החסר:
שדה evaluationMissingData
ב-API |
סיכום | פרטים |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
התראות פתוחות נשארות פתוחות. לא נפתחות התראות של חדשות Google. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם יש התראה פתוחה לתנאי הזה, היא תישאר פתוחה. כשהתראה פתוחה ולא מגיעים נתונים, הטיימר לסגירה אוטומטית מתחיל אחרי עיכוב של 15 דקות לפחות. אם הטיימר מסתיים, ההתראה נסגרת. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים כשהנתונים יפסיקו להגיע. |
EVALUATION_MISSING_DATA_ACTIVE |
התראות פתוחות נשארות פתוחות. אפשר לפתוח התראות חדשות. |
אם התנאים מתקיימים, הם ימשיכו להתקיים גם כשהנתונים יפסיקו להגיע. אם יש התראה פתוחה לתנאי הזה, היא תישאר פתוחה. כשהתראה פתוחה ולא מגיעים נתונים במשך משך הזמן לסגירה אוטומטית פלוס 24 שעות, ההתראה נסגרת. בתנאים שלא מתקיימים, ההגדרה הזו גורמת לתנאי metric-threshold להתנהג כמו |
EVALUATION_MISSING_DATA_INACTIVE |
ההתראות הפתוחות נסגרות. לא נפתחות התראות של חדשות Google. |
אם התנאים מתקיימים, הם מפסיקים להתקיים כשנתונים מפסיקים להגיע. אם יש התראה פתוחה לתנאי הזה, היא תיסגר. אם התנאים לא מתקיימים, הם ימשיכו לא להתקיים כשהנתונים יפסיקו להגיע. |
חסרה הערכת נתונים במחזורי החיים של עומסי העבודה
בתנאים של סף מדד ושל שפת שאילתות של Monitoring, אתם יכולים להגדיר איך Monitoring יעריך נתונים חסרים כשסדרות הזמן יפסיקו לדווח. כדי להגדיר הערכה של נתונים חסרים, לתנאי צריך להיות חלון בדיקה חוזרת (duration) שאינו אפס. תנאי PromQL לא תומכים בהגדרות של הערכת נתונים חסרים. במקום זאת, מערכת Monitoring סוגרת התראת PromQL פתוחה אחרי שחסרים נתונים בשני מרווחי הערכה, בתוספת תקופת חסד.
כשבתנאי מוערכים נתונים חסרים עם הגדרת ברירת המחדל Missing data empty (EVALUATION_MISSING_DATA_NO_OP או EVALUATION_MISSING_DATA_UNSPECIFIED), התראה שכבר נפתחה נשארת פתוחה כשנתוני המדדים מפסיקים להגיע. לדוגמה, אם במשימה או בקונטיינר זמניים יש עלייה חדה ומתמשכת שפותחת התראה, ואז עומס העבודה מסתיים, ההתראה נשארת פתוחה עד שתוקף משך הזמן לסגירה אוטומטית (ברירת המחדל היא 7 ימים) פג, כי לא מגיעות נקודות על הגרף נוספות שמראות שהמדד חזר לרמה שמתחת לסף.
כדי להתאים את ההתנהגות של מדיניות ההתראה למחזור החיים של האפליקציה, בחרו הגדרה להערכת נתונים חסרים ומשך זמן לסגירה אוטומטית, בהתאם לסוגי עומסי העבודה הבאים:
| סוג עומס העבודה | ההגדרה המומלצת לנתונים חסרים | משך הזמן המומלץ לסגירה אוטומטית | התנהגות מחזור החיים וההיגיון שמאחוריה |
|---|---|---|---|
| תהליכי רקע ותשתיות שפועלים באופן רציף (מכונות וירטואליות של Compute Engine, מכונות של Cloud SQL, צמתים של GKE) |
Missing data empty
(EVALUATION_MISSING_DATA_NO_OP) או
Values that violate the condition
(EVALUATION_MISSING_DATA_ACTIVE) |
ברירת מחדל (7 ימים) או 24 שעות | תשתית רציפה צריכה לשלוח נתוני טלמטריה של מדדים בלי הפרעה. אם הטלמטריה נפסקת בזמן שהתראה פתוחה, שמירה על ההתראה הפתוחה מבטיחה שמחיצות הרשת, קריסות של מכונות וירטואליות או כשלים של דימונים יקבלו את תשומת הלב של המפעיל במקום להיסגר באופן אוטומטי. |
| עומסי עבודה זמניים ושירותים להתאמה אוטומטית לעומס (פודים של GKE, משימות וגרסאות של Cloud Run, משימות ב-Cloud Tasks, וורקרים של Batch) |
ערכים שלא מפרים את התנאי
(EVALUATION_MISSING_DATA_INACTIVE) |
בין 30 דקות לשעתיים | פודים זמניים וקונטיינרים ללא שרת (serverless) מסתיימים או מצטמצמים לאפס אחרי שהעבודה מסתיימת. אם מגדירים נתונים חסרים כלא פעילים, כשקונטיינר זמני נעלם, התנאי מפסיק להיחשב כמופר וההתראה נסגרת. קיצור משך הזמן לסגירה אוטומטית מונע מאירועים זמניים להימשך כמה ימים. |
| עומסי עבודה תקופתיים ומתוזמנים (שאילתות באצווה יומיות, משימות cron שעתיות, ניתוח נתונים של יום קלנדרי) |
ערכים שלא מפרים את התנאי
(EVALUATION_MISSING_DATA_INACTIVE) |
בין 30 דקות לשעתיים | עומסי עבודה תקופתיים של אצווה מדווחים על מדדים בדוח רק במהלך הרצות פעילות. משך הזמן לסגירה אוטומטית נמדד מהרגע שבו נתוני הטלמטריה מפסיקים להגיע, ולכן שימוש ב-EVALUATION_MISSING_DATA_INACTIVE ובמשך זמן מקוצר לסגירה אוטומטית (לפחות 30 דקות) מונע מהתראות על הפעלה בודדת להימשך לאורך ימים קלנדריים. |
כדי לצמצם את הבעיות שנובעות מנתונים חסרים, אתם יכולים לבצע את הפעולות הבאות:
- כדי לזהות דרכים לצמצום זמן האחזור של איסוף המדדים, פנו לספק שירותי הענן של הצד השלישי.
- להשתמש בחלונות זמן ארוכים יותר לבדיקה חוזרת בתנאים שלכם. החיסרון בשימוש בחלון בדיקה חוזרת ארוך יותר הוא שמדיניות ההתראות תהיה פחות רספונסיבית.
בחרו מדדים עם עיכוב קצר יותר באיסוף הנתונים:
- מעקב אחרי מדדי סוכנים, במיוחד כשהסוכן פועל במכונות וירטואליות בעננים של צד שלישי.
- מדדים בהתאמה אישית, כשכותבים את הנתונים שלהם ישירות ל-Monitoring.
- מדדים מבוססי-יומנים, אם אין עיכוב באיסוף של רשומות ביומן.
למידע נוסף, ראו סקירה כללית על סוכן תפעול, סקירה כללית על מדדים בהתאמה אישית ומדדים מבוססי-יומנים.
מתי מערכת Monitoring שולחת התראות ויוצרת התרעות
מערכת Cloud Monitoring שולחת התראה כשסדרת זמן גורמת להתקיימות של תנאי. ההתראה נשלחת לכל ערוצי ההתראות. אי אפשר להגביל התראה לערוץ ספציפי או לקבוצת משנה של ערוצי המדיניות.
אם מגדירים התראות חוזרות, אותה התראה נשלחת מחדש לערוצי התראות ספציפיים בהתאם למדיניות ההתראות.
יכול להיות שתקבלו כמה התראות ייחודיות שקשורות למדיניות התראה אחת, אם מתקיים אחד מהתנאים הבאים:
תנאי עוקב אחרי כמה סדרות זמנים.
המדיניות מכילה כמה תנאים. במקרה כזה, ההתראות שתקבלו תלויות בערך של הטריגר מרובה התנאים של מדיניות ההתראה:
All conditions are met: כשכל התנאים מתקיימים, מדיניות ההתראה שולחת התראה ויוצרת התראה לכל סדרת זמן שגורמת לתנאי להתקיים.
אי אפשר להגדיר ב-Cloud Monitoring יצירה של התראה אחת בלבד ושליחה של התראה אחת בלבד כשמדיניות ההתראות מכילה כמה תנאים.
Any condition is met: מדיניות ההתראה שולחת התראה כשסדרת זמנים גורמת לתנאי להתקיים.
למידע נוסף, קראו את המאמר כללי מדיניות עם כמה תנאים.
מדיניות התראות שנוצרה באמצעות Cloud Monitoring API גם שולחת התראה כשהתנאי מתקיים וכשהוא מפסיק להתקיים. במדיניות התראה שנוצרה באמצעות מסוף Google Cloud , לא נשלחת התראה כשהתנאי מפסיק להתקיים, אלא אם הפעלתם את ההתנהגות הזו.
כש-Monitoring לא שולח התראות או יוצר התראות
במצבים הבאים, מערכת Monitoring לא יוצרת התראות או שולחת התראות כשמתקיימים התנאים של מדיניות ההתראות:
- מדיניות ההתראות מושבתת.
- מדיניות ההתראות מופעלת.
- הגעתם למספר המקסימלי של התראות פתוחות ב-Cloud Monitoring.
כללי מדיניות התראות מושבתים
כלי המעקב לא יוצר התראות ולא שולח התראות לגבי כללי מדיניות התראות מושבתים. עם זאת, מערכת Monitoring ממשיכה להעריך את התנאים של מדיניות התראות מושבתת.
כשמפעילים מדיניות מושבתת, המערכת בודקת את הערכים של כל התנאים בחלון הבדיקה החוזרת האחרון. חלון הבדיקה החוזרת האחרון עשוי לכלול נתונים שנאספו לפני, במהלך ואחרי הפעלת המדיניות. התנאים של מדיניות מושבתת יכולים להתקיים מיד אחרי שמפעילים מחדש את המדיניות, גם אם חלונות הבדיקה החוזרת גדולים.
לדוגמה, נניח שיש לכם מדיניות התראה שמנטרת תהליך ספציפי, והשבתתם את המדיניות הזו. בשבוע שלאחר מכן, התהליך מושבת, ובגלל שמדיניות ההתראות מושבתת, לא נשלחת לכם התראה. אם תפעילו מחדש את התהליך ותפעילו את מדיניות ההתראה באופן מיידי, מערכת Monitoring תזהה שהתהליך לא פעל בחמש הדקות האחרונות ותפתח התראה.
ההתראות שקשורות למדיניות התראות מושבתת נשארות פתוחות עד שפג משך הזמן לסגירה אוטומטית של המדיניות.
כללי מדיניות התראות שהושהו
ב-Monitoring לא נשלחות התראות ולא נוצרות התראות למדיניות התראות שהופעלה בה הפעלה מאוחרת. מומלץ להפעיל את מצב "התראה" במדיניות ההתראות כשרוצים למנוע ממדיניות ההתראות לשלוח התראות רק במרווחי זמן קצרים. לדוגמה, לפני שמבצעים פעולות תחזוקה במכונה וירטואלית (VM), אפשר ליצור השהיה ולהוסיף לקריטריונים שלה את מדיניות ההתראות שמנטרת את המכונה.
כשמפעילים את מצב "התראה מאוחרת" במדיניות התראות, המערכת סוגרת את כל ההתראות הפתוחות שקשורות למדיניות. הכלי Monitoring יכול לפתוח התראות חדשות אחרי שתוקף ההשהיה פג. למידע נוסף, ראו השהיית התראות.
מגבלות על התראות פתוחות ועל שליחת התראות
מדיניות התראות יכולה לחול על הרבה משאבים, ובעיה שמשפיעה על כל המשאבים יכולה לגרום למדיניות ההתראות לפתוח התראות לכל משאב. תיפתח התראה לכל סדרת זמנים שבה מתקיים תנאי.
כדי למנוע עומס יתר על המערכת, מספר ההתראות שכללי מדיניות יכולים לפתוח בו-זמנית מוגבל ל-1,000.
לדוגמה, נניח שיש מדיניות שחלה על 2,000 מכונות של Compute Engine, וכל מכונה גורמת לעמידה בתנאים להתראה. ב-Cloud Monitoring, מספר ההתראות הפתוחות מוגבל ל-1,000. המערכת מתעלמת משאר התנאים שמתקיימים עד שחלק מההתראות הפתוחות של אותה מדיניות נסגרות.
כתוצאה מהמגבלה הזו, ערוץ התראות יחיד יכול לקבל עד 1,000 התראות בו-זמנית. אם במדיניות ההתראה יש כמה ערוצי התראות, המגבלה הזו חלה על כל ערוץ התראות בנפרד.
זמן אחזור
זמן אחזור הוא העיכוב בין המועד שבו Monitoring דוגם מדד לבין המועד שבו הנקודה על הגרף של המדד הופכת לנתונים בסדרת זמנים. זמן האחזור משפיע על מועד שליחת ההתראות. לדוגמה, אם למדד במעקב יש זמן אחזור של עד 180 שניות, מערכת Monitoring לא תיצור התראה עד 180 שניות אחרי שהתנאי של מדיניות ההתראה יתקיים. מידע נוסף זמין במאמר זמן האחזור של נתוני המדדים.
האירועים וההגדרות הבאים משפיעים על זמן האחזור:
עיכוב באיסוף המדדים: הזמן שנדרש ל-Monitoring כדי לאסוף את ערכי המדדים. בערכים של Google Cloud , רוב המדדים לא מוצגים במשך 60 שניות אחרי האיסוף, אבל משך העיכוב תלוי במדד. החישובים של מדיניות ההתראות נמשכים עוד 5 דקות ו-30 שניות. במדדים של AWS CloudWatch, העיכוב בהצגה יכול להיות כמה דקות. בבדיקות של זמינות, זה יכול להיות ממוצע של שתי דקות (מסוף חלון הבדיקה החוזרת).
חלון בדיקה חוזרת: החלון שהוגדר לתנאי. התנאים מתקיימים רק אם התנאי נכון לאורך כל חלון הבדיקה החוזרת. לדוגמה, אם מגדירים חלון בדיקה חוזרת של חמש דקות, ההתראה תתעכב לפחות בחמש דקות מהרגע שהאירוע מתרחש בפעם הראשונה.
הזמן עד שההתראה מגיעה: בערוצי התראות כמו אימייל ו-SMS, יכולים להיות עיכובים שקשורים לרשת או עיכובים אחרים (שלא קשורים לתוכן שנשלח), לפעמים של כמה דקות. בערוצים מסוימים, כמו SMS ו-Slack, אין הבטחה שההודעות יימסרו.
המאמרים הבאים
במאמרים הבאים מוסבר איך יוצרים מדיניות התראות:
במאמר מדיניות לדוגמה תוכלו לראות מגוון של כללי מדיניות התראות.