כללי מדיניות ההתראות ב-Cloud Monitoring מזהים בעיות באפליקציות ובתשתיות על ידי הערכת התוצאות של מדדים, יומנים או שאילתות SQL. כשהנתונים המנוטרים עומדים בתנאים שציינתם, המערכת יוצרת התראה ושולחת התראות.
איך פועלות ההתראות
תהליך ההתראה ב-Cloud Monitoring מורכב משלושה חלקים:
מדיניות התראות, שמתארת את הנסיבות שבהן אתם רוצים לקבל התראה, ואיך אתם רוצים לקבל אותה. מדיניות ההתראה יכולה לעקוב אחרי נתונים של סדרות זמנים שמאוחסנים ב-Monitoring, או אחרי יומנים שמאוחסנים ב-Cloud Logging. כשהנתונים עומדים בתנאי של מדיניות ההתראות, המערכת יוצרת התראה ושולחת אותה.
כל התראה היא רשומה של סוג הנתונים שנוטרו, ושל המועד שבו התנאים התקיימו. המידע הזה יכול לעזור לכם לפתור בעיות שגרמו להתראה.
ערוץ התראות מגדיר איך תקבלו התראות כשמערכת Monitoring יוצרת התראה. לדוגמה, אתם יכולים להגדיר מדיניות התראות שתשלח אימייל לכתובת
my-support-team@example.comותפרסם הודעה בערוץ#my-support-teamב-Slack. מדיניות התראות יכולה להכיל ערוץ התראות אחד או יותר.
כללי מדיניות ההתראות יכולים להעריך שלושה סוגים של נתונים:
נתוני סדרות עתיות, שנקראים גם נתוני מדדים, שמאוחסנים על ידי Monitoring. מדיניות התראות מהסוג הזה נקראת מדיניות התראות מבוססת-מדדים.
כדי ללמוד איך להגדיר מדיניות התראות שמבוססת על מדדים, נסו את המדריך למתחילים של Compute Engine.
נתוני רשומות ביומן שמאוחסנים ב-Cloud Logging. כללי מדיניות התראה שמעריכים רשומות יומן בודדות נקראים כללי מדיניות התראה מבוססי-יומן. מדיניות התראות מבוססות-יומנים שולחת התראה כשמופיעה הודעה מסוימת ביומנים. מידע נוסף זמין במאמר מעקב אחרי היומנים.
תוצאות של שאילתת SQL שמופעלת ב-Observability Analytics על נתונים של רשומות ביומן שמאוחסנים ב-Logging. מדיניות התראות שמנטרת את התוצאות של שאילתת SQL נקראת מדיניות התראות מבוססת-SQL. למידע נוסף, קראו את המאמר מעקב אחרי תוצאות של שאילתות SQL באמצעות מדיניות התראות.
תהליך ההתראה עוזר לכם להגיב לבעיות כשביצועי האפליקציה לא עומדים בערכים מקובלים. לדוגמה, אתם פורסים אפליקציית אינטרנט במכונה וירטואלית (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. |
אתם רוצים מדיניות התראות שתשלח התראה כשזמן האחזור של התגובה הוא 500ms או יותר, ב-5 בדיקות זמני פעילות רצופות במשך 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'].
מידע נוסף זמין במאמר הגדרת מדיניות התראות מבוססות-יומנים במסמכי התיעוד של Logging.
מעקב אחרי תוצאות של שאילתות SQL
כדי לעקוב אחרי תוצאות של שאילתות SQL, משתמשים במדיניות התראות שמבוססת על SQL.
התנאי של מדיניות התראות שמבוססת על SQL מנתח מדי פעם את נתוני הרשומות ביומן, ואז יוצר התראות כשטבלת תוצאות השאילתה עומדת בקריטריונים מסוימים. סוג כזה של מדיניות התראות שימושי כשצריך מדיניות התראות שעוקבת אחרי צבירות נתונים או דפוסים מורכבים בכמה רשומות ביומן. לדוגמה, אתם רוצים לקבל התראה כשליותר מ-50 רשומות ביומן ב-60 הדקות האחרונות יש רמת חומרה של WARNING.
למידע נוסף, קראו את המאמר מעקב אחרי תוצאות של שאילתות SQL באמצעות מדיניות התראות במסמכי התיעוד של Logging.
רכיבי מדיניות ההתראות
כל מדיניות התראה כוללת את הרכיבים הבאים:
תנאי שמתאר מתי משאב או קבוצת משאבים נמצאים במצב שדורש תגובה. התנאי כולל את מקור הנתונים, סף סטטי או דינמי ושיטות לצבירת נתונים כמו מסננים ו-groupby. התנאים יכולים לעקוב אחרי מדד אחד, כמה מדדים או יחס בין מדדים. אתם יכולים גם להשתמש ב-Prometheus Query Language (PromQL) כדי לכלול ביטויים מורכבים, כמו ספים דינמיים ולוגיקה מותנית.
אם אתם משתמשים בשילוב כדי להפעיל מדיניות התראות מומלצת, התנאי של מדיניות ההתראות מאוכלס מראש.
רשימה של ערוצי התראות שמתארים את מי צריך לעדכן כשנדרשת פעולה. למידע נוסף, קראו את המאמר יצירה וניהול של ערוצי התראות.
מסמכים שמופיעים בהתראות ובדפי התראות. אתם יכולים להגדיר את שורת הנושא של ההתראה ולהוסיף מידע שימושי לגוף ההתראה. לדוגמה, אתם יכולים להגדיר שההתראה תציג קישורים לפלייבוקים פנימיים או לדפי Google Cloud כמו מרכזי בקרה בהתאמה אישית. למידע נוסף על תיעוד, כולל דוגמאות, קראו את המאמר הוספת הערות להתראות באמצעות תיעוד בהגדרת המשתמש.
ניהול כללי מדיניות ההתראות וההתראות
אחרי שמפעילים מדיניות התראות, המערכת עוקבת באופן רציף אחרי התנאים של המדיניות. אי אפשר להגדיר את מדיניות ההתראות כך שתעקוב אחרי תנאים רק בפרקי זמן מסוימים. אם רוצים להשבית את מדיניות ההתראות לפרק זמן מסוים, אפשר ליצור השהיה.
אם התראה פתוחה ו-Monitoring קובע שהתנאים של המדיניות שמבוססת על מדדים כבר לא מתקיימים, אז Monitoring סוגר את ההתראה באופן אוטומטי ושולח התראה על הסגירה.
המאמרים הבאים
במאמר ההתנהגות של מדיניות התראות שמבוססת על מדדים מוסבר על זמן האחזור של ההתראות ואיך הבחירות של הפרמטרים של מדיניות ההתראות משפיעות על מועד שליחת ההתראות .
במאמר סיכום של דוגמאות למדיניות התראות תוכלו למצוא רשימה של דוגמאות למדיניות מבוססת-מדדים, כולל איך להשתמש ב-JSON כדי לכתוב תנאי של סף מדד שעוקב אחרי יחס של סוגי מדדים.