במאמר הזה מוסבר איך אפשר לארגן את האירועים ולתת להם עדיפות באמצעות תוויות שהמשתמשים מגדירים. התוויות האלה מוגדרות במדיניות התראות ומופיעות במדיניות התראות ובאירועים. בהתאם להגדרה, התוויות מופיעות גם בהתראות מסוימות.
מידע על התוויות
תוויות הן צמדי מפתח/ערך שמשמשים לצירוף מידע לסדרת זמן, למדיניות התראות, לאירוע או להודעה. לדוגמה, התוויות בסדרת זמן יכולות לזהות את המכונה הווירטואלית (VM) הספציפית שממנה נאספו הנתונים. התוויות מוגדרות על ידי המשתמש או מוגדרות מראש.
תוויות שהוגדרו על ידי המשתמש
תוויות שהוגדרו על ידי המשתמש מכילות מידע שאתם מציינים. התוויות האלה יכולות לכלול ערכים סטטיים או דינמיים:
לתוויות סטטיות שהוגדרו על ידי המשתמש יש ערכים שלא ניתן לשנות. אתם יכולים ליצור תוויות סטטיות בהגדרת מדיניות התראות באמצעות Google Cloud המסוף או Cloud Monitoring API. מידע נוסף זמין במאמרים הבאים:
לתוויות דינמיות שהוגדרו על ידי המשתמש יש ערכים שיכולים להשתנות על סמך ערכים של נתונים מסדרת זמן. אפשר ליצור תוויות דינמיות שהמשתמש מגדיר כשמגדירים את התנאי של מדיניות התראות באמצעות PromQL. דוגמה מופיעה במאמר דוגמה: הוספת תוויות מוגדרות על ידי המשתמש עם ערכים דינמיים.
המפתחות של התוויות צריכים להתחיל באות קטנה. גם המפתחות וגם הערכים של התוויות יכולים להכיל רק אותיות קטנות, ספרות, קווים תחתונים ומקפים.
תוויות שהוגדרו מראש
תוויות מוגדרות מראש כלולות בתיאורי משאבים. צריך לאכלס את התוויות האלה כשכותבים נתונים של סדרות זמן. התוויות האלה מציגות מידע על המדד שנאסף או על המשאב שהמדד נכתב לגביו. לדוגמה, התוויות בסדרת זמן יכולות לזהות מכונה וירטואלית (VM), אזור, Google Cloud פרויקט וסוג מכשיר. כש-Monitoring יוצר אירוע על סמך סדרת הזמן הזו, האירוע מקבל בירושה את התוויות האלה.
תוויות של App Hub
App Hub מוסיף תוויות לנתוני יומן, מדדים ומעקב שנוצרו על ידי אפליקציה, השירותים ועומסי העבודה שלה. התוויות האלה מאפשרות לתשתית Google Cloud ליצור לוחות בקרה של אפליקציות, שירותים ועומסי עבודה שמציגים נתוני מדדים ויומנים. מידע נוסף זמין במאמרים הבאים:
- Google Cloud console: קישור מדיניות התראות לאפליקציה ב-App Hub
- Cloud Monitoring API: Associate an alerting policy with an App Hub application (שיוך מדיניות התראות לאפליקציה ב-App Hub).
איך רואים את התוויות
אפשר לראות את התוויות של מדיניות התראות או של אירוע בדף הפרטים של אירוע, בדף הפרטים של מדיניות התראות ובחלק מהההתראות.
- מדיניות התראות: תוויות סטטיות בהגדרת המשתמש מופיעות בקטע תוויות משתמש. תוויות דינמיות שהוגדרו על ידי המשתמש ותוויות שהוגדרו מראש לא מוצגות.
- אירועים: תוויות סטטיות שהוגדרו על ידי המשתמש מופיעות בקטע תוויות מדיניות, ותוויות דינמיות שהוגדרו על ידי המשתמש מופיעות בקטע תוויות מדדים. תוויות מוגדרות מראש מפורטות בקטעים תוויות של משאבים במעקב ותוויות של מדדים.
התראות: תוויות מוגדרות מראש ותוויות שהוגדרו על ידי המשתמש מפורטות בסוגי ההתראות הבאים:
- אימייל
- Google Chat
- PagerDuty
- Pub/Sub
- Webhook
דוגמה: הוספת תוויות מוגדרות על ידי המשתמש עם ערכים דינמיים
אפשר להשתמש ב-PromQL כדי להגדיר תווית כך שהערך שלה ישתנה באופן דינמי על סמך נתונים של סדרות זמן. לדוגמה, אתם רוצים שלאירועים יהיה תווית criticality שהערך שלה משתנה בהתאם לערך של מדד השימוש במעבד שבמעקב:
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.9,
"criticality", "CRITICAL", "", ""
)
or ignoring (criticality)
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.8,
"criticality", "WARNING", "", ""
)
or ignoring (criticality)
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.7,
"criticality", "INFO", "", ""
)
or ignoring (criticality)
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]),
"criticality", "GOOD", "", ""
)
באיור הבא מוצג תהליך העיבוד של נתוני סדרות הזמן שמתבצע על ידי כללי התראה שמשתמשים בשאילתות PromQL:
ה-policy handler מעבד את נתוני השימוש במעבד ומפיק סדרת זמן שמציינת מתי התנאי מתקיים. בדוגמה הקודמת, התנאי מתקיים כשהשימוש במעבד הוא לפחות 70%. לכל סדרת זמן של נתוני קלט, רכיב ה-handler של המדיניות יכול ליצור אחת מארבע סדרות זמן:
| שם סדרת הזמנים של הפלט | התנאי מתקיים | תיאור |
|---|---|---|
| "GOOD" | לא | לסדרת הזמן הזו יש את אותן תוויות כמו לסדרת הזמן של הקלט. אין לו תווית חומרה. |
| "CRITICAL" | כן | ניצול המעבד הוא לפחות 90%. לסדרת הזמן של הפלט יש את אותן תוויות כמו לסדרת הזמן 'GOOD', בתוספת תוויות חומרה עם הערך 'CRITICAL'. |
| "WARNING" | כן | ניצול המעבד הוא לפחות 80% אבל פחות מ-90%. לסדרת הזמן של הפלט יש את אותן תוויות כמו לסדרת הזמן GOOD, בתוספת תוויות חומרה עם הערך WARNING. |
| "INFO" | כן | ניצול המעבד הוא לפחות 70% אבל פחות מ-80%. לסדרת הזמן של הפלט יש את אותן תוויות כמו לסדרת הזמן GOOD, בתוספת תוויות חומרה עם הערך INFO. |
הנתונים בסדרת הזמנים שנוצרים על ידי גורם הטיפול במדיניות הם הקלט של מנהל האירועים, שקובע מתי נוצרים אירועים ומתי הם נסגרים. כדי לקבוע מתי לסגור אירוע, מנהל האירוע משתמש בערכים של השדות duration, evaluationMissingData ו-autoClose.
שיטות מומלצות
כדי לוודא שבכל רגע נתון יש לכל היותר אירוע פתוח אחד כשיוצרים תוויות שהערכים שלהן מוגדרים באופן דינמי, צריך לבצע את הפעולות הבאות:
באובייקט
MetricThreshold, מחליפים את ערכי ברירת המחדל בשדות הבאים:- השדה
duration: צריך להגדיר ערך שאינו אפס. - שדה
evaluationMissingData: הגדרה שגורמת לסגירת האירועים כשנתונים מפסיקים להגיע. כשמשתמשים ב-Cloud Monitoring API, צריך להגדיר את השדה הזה לערךEVALUATION_MISSING_DATA_INACTIVE. כשמשתמשים במסוף Google Cloud , מגדירים את השדה לערך 'נקודות נתונים חסרות נחשבות כערכים שלא מפרים את תנאי המדיניות'.
- השדה
באובייקט
AlertStrategy, מגדירים את השדהautoCloseלערך המינימלי שלו, שהוא 30 דקות. כשמשתמשים ב-Cloud Monitoring API, צריך להגדיר את השדה הזה לערך30m.
מידע נוסף זמין במאמר בנושא נתוני מדדים חלקיים.
תהליך הטיפול באירוע
נניח שמדידות השימוש ביחידת העיבוד המרכזית (CPU) נמוכות מ-70% כשיוצרים את מדיניות ההתראות. הסדר הבא ממחיש איך נפתחים ונסגרים אירועים:
מכיוון שמדידות השימוש במעבד נמוכות מ-70%, המטפל במדיניות יוצר את סדרת הזמן 'טוב' ולא נפתחים אירועים.
עכשיו נניח ששיעור ניצול המעבד עולה ל-93%. ה-handler של המדיניות מפסיק ליצור את נתוני הסדרה העיתית 'GOOD' ומתחיל ליצור נתונים לסדרה העיתית 'CRITICAL'.
מנהל האירוע רואה סדרת זמן חדשה עם הערך CRITICAL (קריטי) שעומדת בתנאי, ואז פותח אירוע. ההתראה כוללת את תווית החומרה עם הערך
CRITICAL.נניח ששיעור ניצול המעבד ירד ל-75%. ה-handler של המדיניות מפסיק ליצור את סדרת הזמן 'CRITICAL' ומתחיל ליצור את סדרת הזמן 'INFO'.
מנהל האירוע רואה סדרת זמן חדשה מסוג INFO שעומדת בתנאי, ואז פותח אירוע. ההתראה כוללת את תווית החומרה עם הערך
INFO.מנהל האירועים רואה שלא מגיעים נתונים לסדרת הזמן CRITICAL ושיש אירוע פתוח לסדרת הזמן הזו. מכיוון שהמדיניות מוגדרת לסגירת אירועים כשנתונים מפסיקים להגיע, מנהל האירועים סוגר את האירוע שמשויך לסדרת הזמן 'קריטי'. לכן, רק האירוע שתווית החומרה שלו היא
INFOיישאר פתוח.לבסוף, נניח ששיעור ניצול המעבד יורד ל-45%. הערך הזה נמוך מכל ערכי הסף, ולכן המטפל במדיניות מפסיק ליצור את סדרת הזמן 'מידע' ומתחיל ליצור את סדרת הזמן 'טוב'.
מנהל האירוע רואה שלא מגיעים נתונים לסדרת הזמן INFO ושיש אירוע פתוח לסדרת הזמן הזו. מכיוון שהמדיניות משתמשת בהגדרות המומלצות, האירוע נסגר.
אם לא משתמשים בערך המומלץ בשדה evaluationMissingData, כשנתונים מפסיקים להגיע, אירועים פתוחים לא נסגרים באופן מיידי.
התוצאה היא שאולי תראו כמה אירועים פתוחים לאותה סדרת זמן של נתוני קלט. מידע נוסף זמין במאמר בנושא נתוני מדדים חלקיים.
המאמרים הבאים
- יצירת מדיניות התראות באמצעות Monitoring API
- יצירת מדיניות התראות באמצעות PromQL
- טיפול בנתוני מדדים חלקיים