בדף הזה מוסבר איך ליצור מדיניות התראות מבוססת-PromQL ב-Cloud Monitoring. אפשר להשתמש בשאילתות PromQL כדי ליצור תנאים מורכבים עם תכונות כמו יחסים, ספים דינמיים שמבוססים על מדד אחר ומדדים משולבים. אפשר גם להגדיר מדיניות התראות מבוססת-PromQL שתפעל על נתונים של יותר משנתיים.
אם אתם משתמשים ב-Prometheus בסביבות מחוץ ל- Google Cloud, או אם אתם משתמשים בהתראות בשירות מנוהל ל-Prometheus, אתם יכולים להעביר את כללי ההתראות של Prometheus למדיניות התראות שמבוססת על PromQL. כך תוכלו לנהל את כל מדיניות ההתראות ב-Cloud Monitoring.
אפשר גם לייבא מרכזי בקרה של Grafana אל Cloud Monitoring.
- מידע כללי על השימוש ב-PromQL ב-Monitoring זמין במאמר PromQL ב-Cloud Monitoring.
- מידע כללי על מדיניות התראות זמין במאמר התנהגות של מדיניות התראות מבוססת-מדדים.
שימוש ב-PromQL במדיניות התראות ב-Cloud Monitoring
אפשר ליצור מדיניות התראות שמבוססת על PromQL בדרכים הבאות:
כדי ליצור מדיניות התראות במסוף Google Cloud ולהגדיר שאילתת PromQL בכלי לעריכת קוד, אפשר לעיין במאמר יצירת מדיניות התראות מבוססת-PromQL (מסוף).
כדי ליצור מדיניות התראות מבוססת-PromQL באמצעות ה-CLI של gcloud או מבנה
AlertPolicyב-Monitoring API, אפשר לעיין במאמר יצירת מדיניות התראות מבוססת-PromQL (API).כדי להעביר את כללי ההתראות וערוצי ההתראות של Prometheus אל Cloud Monitoring באמצעות Google Cloud CLI, אפשר לעיין במאמר בנושא העברת כללי התראות ונמענים מ-Prometheus.
אירועים שנוצרו על ידי מדיניות התראות שמבוססת על PromQL מופיעים במסוף Google Cloud עם שאר האירועים. אפשר לבצע פעולות לגבי האירועים האלה במסוף Google Cloud .
התנאים של מדיניות ההתראות שמבוססת על PromQL יכולים להפנות לכל מדד ב-Cloud Monitoring, כולל מדדי מערכת, מדדים מותאמים אישית ומדדים שמבוססים על יומנים ומדדי Prometheus. Google Cloud צריך לתרגם את השמות של מדדים שאינם מדדי Prometheus לתחביר של מדדי PromQL. מידע נוסף זמין במאמר מיפוי מדדים של Monitoring ל-PromQL.
שאילתה על נתונים של מדדים מלפני יותר משנתיים
בניגוד לסוגים אחרים של מדיניות התראות שתומכים רק בשאילתות על נתוני מדדים מ-25 שעות, אפשר להשתמש ב-PromQL כדי להגדיר התראות על נתוני מדדים מ-2 שנים. האפשרות הזו תומכת בתרחישי שימוש כמו:
- זיהוי חריגות על ידי השוואה בין 5 הדקות האחרונות לבין אותן 5 דקות לפני שבוע.
- הפעלת מדיניות התראות לגבי עלייה הדרגתית בשימוש (slow burn) למשך 7 ימים.
- קבלת הערך הממוצע בחודש האחרון והתראה אם הנתונים מהשעה האחרונה חורגים ביותר מ-3 סטיות תקן מהממוצע הזה.
- שימוש בפונקציה
predict_linearעל נתונים מהשבוע האחרון כדי לבדוק אם תחרגו מסף מסוים ביום הבא.
מדיניות התראות ב-PromQL שפועלת על הנתונים מ-25 השעות האחרונות, כפי שמוגדר על ידי סכום תקופת ההתאמה וכל שינוי בזמן שנגרם כתוצאה משימוש במאפיין offset, יכולה לבצע הערכה בתדירות של עד 30 שניות.
מדיניות שפועלת על נתונים ישנים יותר מוערכת בתדירות נמוכה יותר, והתקופה המינימלית נקבעת לפי כמה זמן אחורה מדיניות ההתראות בודקת:
| טווח הזמן שחלף מאז השאילתה | מרווח ההערכה המינימלי (ברירת מחדל) |
|---|---|
| עד 25 שעות1 | 30 שניות |
| 25 שעות עד 8 ימים | 5 דקות |
| 8 ימים עד 16 ימים | שעה אחת |
| 16 ימים עד 32 ימים | שעתיים |
| 32 ימים עד 93 ימים | 6 שעות |
| 93 ימים עד שנתיים | 12 שעות |
1 חלק מהמדדים משירותי Google Cloud תומכים רק במרווחי הערכה של 30 שניות למשך עד 23 שעות ו-30 דקות.
חשוב לוודא שמשכי הזמן של rate יהיו לפחות באורך של מרווח ההערכה, כדי שמדיניות ההתראות לא תפספס נתונים. לדוגמה, אם מרווח ההערכה הוא שעה, השאילתה צריכה להיראות כך: rate(metric[1h]).
הזמן הקצוב לתפוגת שאילתות של תנאים שפועלים על נתונים של יותר מ-25 שעות הוא 2 דקות, כמו ב-Metrics Explorer. אם שאילתת PromQL לא מגיעה לזמן קצוב לתפוגה בכלי Metrics Explorer, היא לא תגיע לזמן קצוב לתפוגה בהתראה.
מדיניות התראות ב-PromQL אמינה הרבה יותר כשמפעילים אותה על נתונים מ-25 השעות האחרונות. כדי להבטיח את המהימנות המקסימלית, צריך לוודא שסכום חלון הבדיקה מחדש, תקופת ההתאמה וכל שינוי בזמן שנגרם כתוצאה משימוש במחרוזת offset הוא לכל היותר 25 שעות.
חלונות הבדיקה מחדש מושבתים בשאילתות התראות של PromQL שמתבססות על נתונים בני יותר מ-25 שעות.
אפשר להגדיר התראות רק על הנתונים מ-25 השעות האחרונות של מדדים מותאמים אישית (הקידומת custom.googleapis.com) ומדדים מבוססי-יומן שהוגדרו על ידי המשתמש (הקידומת logging.googleapis.com/user/).
הגבלות
אל תוסיפו מסננים שמשתמשים בתוויות של מטא-נתונים של המערכת למדיניות ההתראות שמבוססת על PromQL.
חלון הבדיקה מחדש של מדיניות התראות שמבוססת על PromQL יכול להיות עד 24 שעות. אם משתמשים בחלון בדיקה חוזרת, הסכום של חלון הבדיקה החוזרת, תקופת ההתאמה וכל שינוי בזמן שנגרם כתוצאה משימוש במחרוזת offset, צריך להיות לכל היותר 25 שעות.
אם כלל ההתראה של Prometheus מפנה למדד, צריך קודם שיהיה תיאור מדד מקביל ב-Cloud Monitoring לפני שיוצרים מדיניות התראות מבוססת-PromQL. עם זאת, אפשר לבטל את האימות הזה על ידי הגדרת מדיניות התראות מבוססת-PromQL באמצעות Cloud Monitoring API. מידע נוסף זמין במאמר השבתת הבדיקה לקיום מדדים.
אם מדיניות ההתראות שלכם עוקבת אחרי יחס בין מדדים, צריך להגדיר את משך הזמן לפחות כפול ממרווח ההערכה. משכי זמן קצרים יותר עלולים להוביל לאירועים שגויים. מידע נוסף זמין במאמר התראות שגויות בגלל אנומליות בחישוב היחס.
תמחור
למידע על התמחור של Cloud Monitoring, אפשר לעיין בדף התמחור של Google Cloud Observability.