סקירה כללית על התראות

במאמר הזה מוסבר איך לקבל התראות כשהאפליקציה נכשלת או כשהביצועים שלה לא עומדים בקריטריונים שהוגדרו.

איך פועלות ההתראות

תהליך ההתראות ב-Cloud Monitoring כולל שלושה חלקים:

• מדיניות התראות, שמתארת את הנסיבות שבהן רוצים לקבל התראה ואת האופן שבו רוצים לקבל התראה. מדיניות ההתראות יכולה לעקוב אחרי נתונים של סדרות זמן שמאוחסנים ב-Monitoring או אחרי יומנים שמאוחסנים ב-Cloud Logging. כשהנתונים האלה עומדים בתנאי של מדיניות ההתראות, מערכת Monitoring יוצרת התראה ושולחת את ההתראות.

• כל התראה היא רשומה של סוג הנתונים שנבדקו ושל הזמן שבו התנאים התקיימו. המידע הזה יכול לעזור לכם לפתור את הבעיות שגרמו להתראה.

• ערוץ התראות מגדיר איך תקבלו התראות כש-Monitoring יוצר התראה. לדוגמה, אפשר להגדיר מדיניות התראות לשליחת אימייל לכתובת [e-mail] ולפרסום הודעה בערוץ #my-support-team ב-Slack. מדיניות התראות יכולה להכיל ערוץ אחד או יותר של הודעות.

מדיניות ההתראות יכולה להעריך שלושה סוגים של נתונים:

• נתונים של סדרות זמן, שנקראים גם נתוני מדדים, שמאוחסנים על ידי Monitoring. סוגי המדיניות האלה נקראים מדיניות התראות מבוססת-מדדים.

  כדי ללמוד איך מגדירים מדיניות התראות שמבוססת על מדדים, אפשר לנסות את המדריך למתחילים בנושא Compute Engine.

• נתונים של רשומות ביומן שאוחסנו על ידי Cloud Logging. מדיניות התראות שבודקת רשומות בודדות ביומן נקראת מדיניות התראות מבוססת-יומן. מדיניות התראות שמבוססת על יומנים שולחת לכם התראות כשמופיעה הודעה מסוימת ביומנים. מידע נוסף מופיע במאמר בנושא מעקב אחרי היומנים.

• התוצאות של שאילתת SQL שמופעלת ב-Observability Analytics על נתוני רשומות ביומן שמאוחסנים ב-Logging. מדיניות התראות שעוקבת אחרי התוצאות של שאילתת SQL נקראת מדיניות התראות שמבוססת על SQL. מידע נוסף מופיע במאמר בנושא מעקב אחרי תוצאות של שאילתות SQL באמצעות מדיניות התראות.

  מדיניות התראות מבוססת-SQL נמצאת ב-Public Preview.

תהליך ההתראה עוזר לכם להגיב לבעיות כשהביצועים של אפליקציה לא עומדים בערכים המקובלים. לדוגמה, אתם פורסים אפליקציית אינטרנט במכונה וירטואלית (VM) של Compute Engine. אתם מצפים שזמן האחזור של תגובת ה-HTTP ישתנה, אבל אתם רוצים שצוות התמיכה יגיב אם זמן האחזור של האפליקציה יהיה ארוך במשך תקופה משמעותית. אפשר ליצור מדיניות התראות שמבוססת על מדדים, שתעקוב אחרי מדד השהייה של תגובת ה-HTTP של האפליקציה. אם זמן האחזור של התגובה גבוה משתי שניות למשך חמש דקות לפחות, מערכת המעקב יוצרת התראה ושולחת התראות באימייל לצוות התמיכה.

איך יוצרים מדיניות התראות

יש כמה דרכים ליצור מדיניות התראות. לדוגמה, אתם יכולים להשתמש במדיניות התראות שהוגדרה מראש על ידי הפעלת התראות מומלצות משילובים או מדפים מסוימים במסוף Google Cloud . אפשר גם להגדיר מדיניות חדשה להתראות באמצעותGoogle Cloud המסוף, Cloud Monitoring API, ‏ Google Cloud CLI ו-Terraform.

שימוש בשילובים ובכללי מדיניות מומלצים להתראות

‫Monitoring מספק חבילות מוכנות מראש שמאפשרות לכם ליצור מדיניות התראות עבורGoogle Cloud השירותים והשילובים של צד שלישי. החבילות כוללות כללי מדיניות מומלצים להתראות, מרכזי בקרה לדוגמה ומדדים מרכזיים לשירות. החבילות האלה זמינות לGoogle Cloud שירותים כמו Google Kubernetes Engine,‏ Compute Engine ו-Cloud SQL, ולשילובים נפוצים של צד שלישי כמו MongoDB,‏ Kafka ו-Elasticsearch.

כשמתקינים חבילה, אפשר להפעיל את מדיניות ההתראות המומלצת של החבילה. כשמפעילים מדיניות התראות מומלצת, מגדירים את ערוץ ההתראות שלה ואפשר גם לשנות ערכים אחרים. אחרי ההגדרה, מדיניות ההתראות מתחילה לעקוב אחרי היעד שלה באופן מיידי, ללא צורך בהזנת נתונים נוספת מצד המשתמש.

מדיניות מומלצת להתראות יכולה לעזור לכם אם פרסתם שירות חדש ואתם רוצים לקבל התראות על מדדים חשובים. לדוגמה, חבילת השילוב של Cloud SQL כוללת מדיניות מומלצת להגדרת התראות לגבי מקרים של מכונות שנכשלו ועסקאות איטיות:

מידע נוסף זמין במאמרים הבאים:

• התקנת כללי מדיניות התראות.
• ניהול שילובים
• מעקב אחרי אפליקציות של צד שלישי.

יצירת כללי מדיניות חדשים להתראות

אתם יכולים ליצור מדיניות התראות כדי לעקוב אחרי סוגים שונים של נתונים, בהתאם לצרכים שלכם. בקטעים הבאים מפורטים סוגי הנתונים השונים שאפשר לעקוב אחריהם באמצעות מדיניות התראות.

מעקב אחרי נתונים של פעולות על ציר הזמן

סוג התנאי	תיאור	דוגמה
תנאי של סף מדד	תנאי סף המדד מתקיימים כשערכי המדד גבוהים או נמוכים מסף מסוים בחלון בדיקה חוזרת ספציפי. מידע נוסף זמין במאמרים יצירת מדיניות התראות מבוססת-מדדים ויצירת מדיניות התראות באמצעות ה-API.	אתם רוצים מדיניות התראות שתשלח התראה כשהשהיית התגובה היא 500 אלפיות השנייה או יותר, במשך חמש בדיקות זמני פעילות רצופות במהלך 10 דקות.
תנאי של היעדר מדד	תנאים של היעדר מדדים מתקיימים כשאין נתונים בסדרת זמן במעקב לגבי חלון בדיקה חוזרת ספציפי. חלון הבדיקה מחדש המקסימלי הוא 24 שעות. מידע נוסף זמין במאמרים יצירת מדיניות התראות על היעדר מדדים ויצירת מדיניות התראות באמצעות ה-API.	אתם רוצים מדיניות התראות שפותחת התראה לצוות התמיכה שלכם אם משאב לא מגיב לבקשות HTTP במשך חמש דקות.
תנאי Prometheus Query Language‏ (PromQL)	‫PromQL היא שפת שאילתות פונקציונלית שמשמשת להערכה של נתוני סדרות זמן בזמן אמת. בשילוב עם שאילתות PromQL, אפשר להשתמש בכל ביטוי תקין, כמו שילובים של מדדים, יחסים וערכי סף דינמיים שמבוססים על מדד. מידע נוסף מופיע במאמרים PromQL ב-Cloud Monitoring וסקירה כללית על התראות PromQL.	אתם רוצים להשתמש בביטוי התראה של PromQL שנמצא במאגר ציבורי, אתם רוצים מדיניות התראות שמבוססת על יותר ממדד אחד כמו יחס, או שאתם רוצים מדיניות התראות שפועלת על נתונים של יותר מ-25 שעות.
תנאי של ערך מדד חזוי	תנאים של ערכי מדדים חזויים מתקיימים כשמדיניות ההתראות חוזה שהסף ייחצה בחלון התחזית הקרוב. חלון התחזית יכול להיות בין שעה ל-7 ימים. מידע נוסף זמין במאמרים יצירת מדיניות התראות לגבי ערכי מדדים צפויים ויצירת מדיניות התראות באמצעות ה-API.	אתם רוצים מדיניות התראות שתפתח התראה לצוות התמיכה שלכם אם יש סיכוי גבוה ששימוש במשאב יגיע ל-80% משטח הדיסק ב-24 השעות הקרובות.

מומלץ לסנן לפי התוויות שמוגדרות בסוגי משאבים במעקב במקום לפי תוויות שמוגדרות בסוגי מדדים, אם אפשר, במיוחד אם אתם שולחים שאילתות לגבי מדדים עם קרדינליות גבוהה. אם יש לכם תווית משאב ותווית מדד שמציגות מידע דומה, כדאי להשתמש בתווית המשאב בשאילתות.

לדוגמה, אם המשאב שבמעקב כולל תווית cluster והמדד כולל תווית kubernetes_cluster_name שמתעדת מידע דומה, כדאי לסנן לפי התווית cluster של המשאב.

כשבוחרים סדרות זמן למדיניות התראות רגישה, לא כדאי להסתמך על הערכים של תוויות מטא-נתונים של משאבים שהוגדרו על ידי המערכת או על ידי המשתמש. במקום זאת, משתמשים בערכים של תוויות שמוגדרות על ידי סוגי המשאבים שבמעקב.

תוויות של מטא נתונים של משאבים מתווספות באופן אסינכרוני לסדרות זמן, ולא חלות עליהן אותן ציפיות לגבי זמן האחזור כמו על ערכים של סוגי מדדים מוגדרים או סוגים של משאבים שנמצאים במעקב. לכן, מדיניות התראות שמסתמכת על ערכי מטא-נתונים כדי להפעיל פעולה עלולה להתנהג בצורה לא צפויה אם יש עיכוב באכלוס התוויות של מטא-נתונים של משאבים.

מעקב אחרי נתוני רשומות ביומן

כדי לעקוב אחרי רשומות ספציפיות ביומן, משתמשים במדיניות התראות מבוססת-יומן. תנאי במדיניות התראות שמבוססת על יומן מתקיים כשמדיניות ההתראות מזהה שביטוי מרשומה ביומן תואם לקריטריונים של מדיניות ההתראות. לדוגמה, אתם רוצים מדיניות התראות שתפתח התראה לצוות התמיכה שלכם כשערך של רשומה ביומן message מכיל את הערך product_ids=['tier_1_support', 'tier_2_support'].

מידע נוסף זמין במאמר בנושא הגדרת כללי מדיניות להתראות שמבוססות על יומנים במסמכי התיעוד בנושא רישום ביומן.

מעקב אחרי תוצאות של שאילתות SQL

כדי לעקוב אחרי תוצאות של שאילתות SQL, משתמשים במדיניות התראות מבוססת-SQL. התנאי של מדיניות התראות מבוססת-SQL מנתח מעת לעת את נתוני רשומות היומן, ואז יוצר התראות כשהטבלה של תוצאות השאילתה עומדת בקריטריונים מסוימים. סוג המדיניות הזה של התראות שימושי כשצריך מדיניות התראות שעוקבת אחרי צבירות של נתונים או אחרי דפוסים מורכבים בכמה רשומות ביומן. לדוגמה, אתם רוצים לקבל התראה אם יותר מ-50 רשומות ביומן ב-60 הדקות האחרונות הן ברמת חומרה WARNING.

מידע נוסף מופיע במאמר בנושא מעקב אחרי תוצאות של שאילתות SQL באמצעות מדיניות התראות במסמכי התיעוד של Logging.

רכיבים של מדיניות התראות

כל מדיניות התראות כוללת את הרכיבים הבאים:

• תנאי שמתאר מתי משאב או קבוצת משאבים נמצאים במצב שדורש תגובה. התנאי כולל את מקור הנתונים, סף סטטי או דינמי ושיטות צבירת נתונים כמו מסננים ו-groupby. התנאים יכולים לעקוב אחרי מדד יחיד, כמה מדדים או יחס בין מדדים. אפשר גם להשתמש בשפת השאילתות של Prometheus‏ (PromQL) כדי לכלול ביטויים מורכבים כמו ספים דינמיים ולוגיקה מותנית.

  אם משתמשים בשילוב כדי להפעיל מדיניות מומלצת להתראות, אז התנאי של מדיניות ההתראות מאוכלס מראש.

• רשימה של ערוצי התראות שמתארת למי צריך לשלוח התראה כשנדרשת פעולה. מידע נוסף מופיע במאמר בנושא יצירה וניהול של ערוצי התראות.

• תיעוד שמופיע בהתראות ובדפי ההתראות. אתם יכולים להגדיר את שורת הנושא של ההתראה ולהוסיף מידע שימושי לגוף ההתראה. לדוגמה, אפשר להגדיר את ההתראה כך שיוצגו בה קישורים לחוברות הפעלה פנימיות או Google Cloud לדפים כמו מרכזי בקרה בהתאמה אישית. מידע נוסף על תיעוד, כולל דוגמאות, זמין במאמר בנושא הוספת הערות להתראות עם תיעוד שהוגדר על ידי המשתמש.

ניהול של מדיניות התראות והתראות

אחרי שמפעילים מדיניות התראות, שירות Monitoring עוקב באופן רציף אחרי התנאים של המדיניות הזו. אי אפשר להגדיר את מדיניות ההתראות כך שתעקוב אחרי תנאים רק בתקופות זמן מסוימות. אם רוצים להשבית את מדיניות ההתראות לתקופה מסוימת, יוצרים השהיה.

אם התראה פתוחה ומערכת המעקב קובעת שהתנאים של מדיניות מבוססת-מדדים כבר לא מתקיימים, מערכת המעקב סוגרת את ההתראה באופן אוטומטי ושולחת התראה על הסגירה.

תמחור

למידע על התמחור של Cloud Monitoring, אפשר לעיין בדף התמחור של Google Cloud Observability.

למידע על מעקב אחרי מספר טווחי המעקב או היומנים שנקלטים, או על קבלת התראה כשתוכן ספציפי נכלל ברשומה ביומן, אפשר לעיין במסמכים הבאים:

• התראות על העברה חודשית של יומנים
• התראה על הטמעת יחידות לוגיות למעקב חודשי
• הגדרת התראות מבוססות-יומן

המאמרים הבאים

• מידע על זמן האחזור של ההתראות ועל האופן שבו הבחירות של הפרמטרים של מדיניות ההתראות משפיעות על מועד שליחת ההתראות מופיע במאמר התנהגות של מדיניות התראות שמבוססת על מדדים.

• רשימה של דוגמאות למדיניות מבוססת-מדדים, כולל הסבר על שימוש ב-JSON כדי לכתוב תנאי של סף מדד שעוקב אחרי יחס בין סוגי מדדים, מופיעה במאמר סיכום של דוגמאות למדיניות התראות.