כדי לעקוב אחרי התקינות של פייפליין זורם וצריכת המשאבים בלי להגדיר ידנית כללי מדיניות ב-Cloud Monitoring, אתם יכולים להפעיל התראות מוכנות לשימוש ב-Dataflow. התראות מוכנות לשימוש מספקות חבילה מוגדרת מראש של מדיניות התראות מומלצת, שאפשר להפעיל במהלך הפעלת המשימה.
התכונה הזו מאפשרת לכם:
- חשיפה מיידית: מעקב אוטומטי אחרי מדדי סטרימינג קריטיים, כמו זמן העיבוד של צבר המשימות וצמיחת ה-vCPU, בלי הגדרה ידנית.
- מעקב סטנדרטי: אפשר להחיל במהירות מדיניות התראות בסיסית על עומסי עבודה חדשים וקיימים בסביבת הייצור.
- התאמה אישית של ההתראות: אפשר לשנות את ערכי הסף של התראות ברירת המחדל, להשבית כללי מדיניות ספציפיים או להוסיף לחבילה כללי מדיניות משלכם להתראות בהתאמה אישית.
אתם יכולים להתאים אישית את כללי המדיניות האלה שמוגדרים כברירת מחדל בכל שלב ב-Cloud Monitoring, או לשלב את כללי המדיניות המותאמים אישית שלכם להתראות עם חבילת ההתראות המוכנה לשימוש.
דרישות מוקדמות
כדי להשתמש בהתראות המוכנות לשימוש, הפרויקט צריך לעמוד בדרישות הבאות:
ערוצי התראות: צריך להגדיר לפחות ערוץ התראות אחד (לדוגמה, אימייל, Slack או PagerDuty). מומלץ להגדיר אנשי קשר חיוניים כדי לוודא שההתראות יגיעו לבעלי העניין הרלוונטיים. הדרישה הזו לא נאכפת על ידי שירות Dataflow. מידע נוסף זמין במאמר יצירה וניהול של ערוצי התראות.
הרשאות: כדי ליצור ולנהל את כללי המדיניות האלה בשבילכם, חשבון השירות של Dataflow (P4SA) צריך הרשאות IAM ספציפיות:
monitoring.alertPolicies.getmonitoring.alertPolicies.listmonitoring.alertPolicies.createmonitoring.alertPolicies.updatemonitoring.alertPolicies.delete
בפרויקטים חדשים, ההרשאות האלה מתווספות באופן אוטומטי. בפרויקטים קיימים, יכול להיות שתצטרכו להגדיר את ההרשאות האלה באופן ידני בחשבון P4SA.
עדכון ההרשאות של P4SA
סוכן השירות של Dataflow (שנקרא לעיתים קרובות P4SA, או חשבון שירות לכל מוצר ולכל פרויקט) הוא חשבון שירות שמנוהל באופן אוטומטי ונוצר כשמפעילים את Dataflow API. כתובת האימייל שלו מופיעה בפורמט הבא:
service-PROJECT_NUMBER@dataflow-service-producer-prod.
כדי לעדכן את ה-P4SA, צריך את ההרשאה resourcemanager.projects.setIamPolicy או תפקיד שכולל את ההרשאה הזו, כמו אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin).
כדי להקצות את התפקידים הנדרשים באמצעות מסוף Google Cloud :
נכנסים לדף IAM במסוף Google Cloud .
בוחרים את הפרויקט הרצוי.
מסמנים את התיבה Include Google-provided role grants.
ברשימת חשבונות המשתמשים, מאתרים את השורה של סוכן השירות של Dataflow (
service-PROJECT_NUMBER@dataflow-service-producer-prod.או עם התפקיד סוכן שירות של Cloud Dataflow).בשורה הזו לוחצים על Edit principal.
בחלונית Edit permissions לוחצים על Add another role.
ברשימה Select a role, בוחרים באפשרות Monitoring Editor (
roles/monitoring.editor).לוחצים על Save. יכול להיות שיעברו כמה דקות עד שהעדכון של ההרשאות יתפשט.
הפעלת התראות מוכנות לשימוש
אתם יכולים לרשום משימה להתראות מוכנות לשימוש באמצעות ה-CLI של gcloud.
הפעלת התראות באמצעות ה-CLI של gcloud
כדי להפעיל או להשבית את התכונה, מוסיפים את אחד מהדגלים הבאים במהלך שליחת המשימה:
--enable-turnkey-alerts--no-enable-turnkey-alerts
אם לחשבון השירות אין את ההרשאות הנדרשות, ה-CLI דוחה את הבקשה ומציג את ההרשאות החסרות. מידע נוסף זמין בקטע דרישות מוקדמות.
הגדרות ההתראות המוכנות לשימוש נשמרות גם כשמעדכנים את המשימה. כשמעדכנים משימה, ההגדרה הקודמת של ההתראות המוכנות לשימוש נשמרת, כך שלא צריך לציין שוב את הדגל --enable-turnkey-alerts או --no-enable-turnkey-alerts, אלא אם רוצים לשנות את ההגדרה.
חבילת כללי המדיניות שמוגדרת כברירת מחדל
ההתראות המוכנות לשימוש כוללות שתי כללי מדיניות עיקריים שמיועדים לעומסי עבודה אופייניים של סטרימינג, שמתמקדים במדדי KPI בזמן אמת כמו זמני עיבוד וניצול משאבים. לכללי המדיניות ש-Google מספקת יש קידומת Default Policy: לצורך זיהוי, אבל השירות משתמש בתוויות כמזהה הראשי.
הלקוחות מצורפים באופן אוטומטי לכל כללי המדיניות בחבילת ברירת המחדל. במקרה הצורך, אפשר להשבית כללי מדיניות ספציפיים שמוגדרים כברירת מחדל בהתראות של Cloud Monitoring.
| שם המדיניות | מדד בסיס | סף ברירת המחדל | ההסבר |
|---|---|---|---|
| מדיניות ברירת המחדל: צבר הזמנות משוער | job/estimated_backlog_processing_time |
30 דקות | הערכת הזמן שנדרש כדי לטפל בצבר המשימות הנוכחי. אם הצבר גדול מ-30 דקות, סימן שהמשימה מתקשה להתקדם. |
| מדיניות ברירת המחדל: מדיניות צמיחה של vCPU | job/current_num_vcpus |
עלייה של יותר מפי 5 בשימוש הממוצע ב-vCPU בשעה אחת בהשוואה לממוצע של 7 ימים | מעקב אחרי שינויים יחסיים במספר ה-vCPU כדי להעריך עלויות לא צפויות של משימות. |
מחזור החיים של המדיניות
- כללי מדיניות בגרסת בטא: כללי המדיניות האלה כוללים את הקידומת
BETAבשם שלהם, והם עשויים להשתנות או להימחק ככל שנגדיר את הסף בצורה מדויקת יותר. - כללי מדיניות GA: אחרי שכלל מדיניות נחשב ליציב, הקידומת
BETAמוסרת.
התאמה אישית וניהול של התראות
ההתראות המוכנות מראש הן נקודת התחלה. מומלץ להתאים אותם אישית לדרישות הספציפיות של העסק.
- במסוף Google Cloud , נכנסים לדף Cloud Monitoring > Alerting.
- מוצאים את המדיניות (לדוגמה, מדיניות ברירת המחדל: צבר הזמנות משוער).
- עורכים את הסף לערך הרצוי.
יצירת כללי מדיניות בהתאמה אישית
כדי להוסיף כל מדיניות התראה של Cloud Monitoring לחבילת ההתראות המוכנות לשימוש, צריך להוסיף לה את התווית goog-turnkey-alerts. כך אתם יכולים לנהל כללים מותאמים אישית שספציפיים לעסק שלכם לצד חבילת הכללים שמוגדרת כברירת מחדל.
השבתה או מחיקה של כללי מדיניות בנושא התראות
אתם יכולים להשבית או למחוק כללי מדיניות ספציפיים שמוגדרים כברירת מחדל באמצעות Monitoring. כשמשביתים מדיניות, המערכת מפסיקה להעריך את התנאי של המדיניות ולא נוצרים אירועים חדשים, אבל ההגדרות של המדיניות נשמרות. אם מוחקים מדיניות, היא מוסרת מהפרויקט באופן סופי. למידע נוסף על ניהול מחזורי החיים של כללי מדיניות, קראו את המאמרים ניהול מדיניות התראות ומדיניות התראות מושבתת.
פתרון בעיות
| שגיאה | רזולוציה |
|---|---|
| PERMISSION_DENIED | מוודאים של-Dataflow P4SA יש את ההרשאות הנדרשות של monitoring.alertPolicies.* שמפורטות בקטע דרישות מוקדמות. אם התפקידים האלה חסרים ב-P4SA, ה-pipeline עדיין יופעל, אבל תופיע השגיאה PERMISSION_DENIED בפלט של שורת הפקודה וביומני המשימות, שמציינת שלא ניתן ליצור התראות כברירת מחדל. |
| לא התקבלו התראות | כדי לקבוע אם התנאי להתראה התקיים, בודקים אם יש אירועים. אפשר לראות את ההתראות שהופעלו ואת צירי הזמן של האירועים ב-Monitoring (ראו הצגת אירועים). |
| כללי מדיניות כפולים | בדרך כלל זה קורה אם לכמה כללי מדיניות יש את התווית goog-turnkey-alerts ואותה הגדרת מדד. Dataflow בודק אם יש חפיפה בין תוויות ומדדים, ולא התאמות מדויקות של שמות. בודקים את כללי המדיניות ומסירים את התווית מהגדרות מיותרות. |