פתרון בעיות שקשורות להתראות חסרות

כדי לאבחן ולפתור בעיות שקשורות להתראות חסרות ב-Cloud Monitoring, אפשר לבדוק את notification_channel_events היומנים ב-Logs Explorer. אחר כך תוכלו לתקן בעיות בהעברה ובהגדרות בערוצי webhook,‏ Pub/Sub ו-SMS, או לשנות את מדיניות ההתראות לגבי כיבוי של מכונות וירטואליות (VM) ומדדים של מספר הבקשות.

ההתראות לא מתקבלות

אם לא מקבלים התראות באף אחד מערוצי ההתראות שהוגדרו, צריך לבצע את הפעולות הבאות:

  1. במסוף Google Cloud , נכנסים לדף Logs Explorer:

    כניסה אל Logs Explorer

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

  2. בוחרים את הפרויקט המתאים Google Cloud .

  3. שליחת שאילתה ליומנים לגבי אירועים בערוץ ההתראות:

    1. מרחיבים את התפריט שם היומן ובוחרים באפשרות notification_channel_events.
    2. מרחיבים את התפריט חומרה ובוחרים באפשרות שגיאה.
    3. אופציונלי: כדי לבחור טווח זמן בהתאמה אישית, משתמשים בבורר טווח הזמן.
    4. לוחצים על Run query.

    השלבים הקודמים יוצרים את השאילתה הבאה:

    resource.type:"stackdriver_notification_channel"
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR

    בדרך כלל שורת הסיכום והשדה jsonPayload מכילים מידע על הכשל. לדוגמה, כשמתרחשת שגיאת שער, שורת הסיכום כוללת את הטקסט failed with 502 Bad Gateway (הפעולה נכשלה עם שגיאה 502 שער שגוי).

התראות webhook לא מתקבלות

הקטע הזה רלוונטי אם לא קיבלתם התראות דרך ערוץ התראות של webhook שהגדרתם.

נקודת קצה פרטית

אם יש לכם נקודת קצה פרטית, אתם יכולים להשתמש בהתראות Pub/Sub בשילוב עם מינוי pull לנושא ההתראות הזה. אי אפשר להשתמש ב-webhook לשליחת התראות לנקודות קצה פרטיות.

כשמגדירים ערוץ התראות ב-Pub/Sub, התראות על אירועים נשלחות לתור Pub/Sub עם אמצעי בקרה לניהול זהויות והרשאות גישה. כל שירות שיכול לשלוח שאילתות לנושא Pub/Sub או להאזין לו יכול לצרוך את ההתראות האלה. לדוגמה, אפליקציות שפועלות במכונות וירטואליות של App Engine,‏ Cloud Run או Compute Engine יכולות לצרוך את ההתראות האלה.

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

נקודת קצה ציבורית

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

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

resource.type="stackdriver_notification_channel"

התראות Pub/Sub לא מתקבלות

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

היומנים כוללים שגיאה מסוג Failed to authenticate as service account

כשמריצים שאילתה ביומן notification_channel_events כדי לחפש שגיאות, יכול להיות שתופיע רשומה ביומן שהשדה summary שלה כולל את ההודעה הבאה:

Failed to authenticate as service account service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

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

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

  1. נכנסים לדף IAM במסוף Google Cloud :

    כניסה לדף IAM

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.

  2. מחפשים חשבון שירות שפועל לפי מוסכמות מתן השמות הבאות:

    service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

    אם חשבון השירות הזה לא מופיע ברשימה, מסמנים את התיבה Include Google-provided role grants.

כדי להפעיל את Monitoring ליצירת חשבון שירות ההתראות, מתחילים בתהליך של יצירת ערוץ התראות Pub/Sub:

  1. נכנסים לדף  Alerting במסוף Google Cloud :

    עוברים אל התראות

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

  2. לוחצים על עריכת ערוצי התראות.

  3. בקטע Pub/Sub, לוחצים על Add new (הוספה).

    אם חשבון השירות של ההתראות לא קיים, הוא נוצר על ידי כלי המעקב. בתיבת הדו-שיח יצירת ערוץ Pub/Sub מוצג השם של חשבון השירות של ההתראות.

  4. אם לא רוצים להוסיף ערוץ התראות, לוחצים על ביטול. אחרת, מסיימים ליצור את ערוץ ההתראות ולוחצים על הוספת ערוץ.

  5. נותנים לחשבון השירות הרשאות לפרסום בנושאי Pub/Sub:

    1. בכרטיסייה חדשה בדפדפן, פותחים את המסמך יצירת ערוץ התראות.
    2. לוחצים על הכרטיסייה Pub/Sub ופועלים לפי השלבים בקטע Authorize service account בדף.

היומנים כוללים שגיאה מסוג PERMISSION_DENIED

כשמריצים שאילתה ביומן notification_channel_events כדי לחפש שגיאות, יכול להיות שתופיע רשומה ביומן שהשדה summary שלה כולל את ההודעה הבאה:

An error occurred while publishing notification to Cloud Pub/Sub topic TOPIC_ID. Possible causes: 1) you don't have the required role (https://cloud.google.com/monitoring/support/notification-options#pubsub); or 2) Cloud Pub/Sub API is not enabled in your project: PERMISSION_DENIED

השגיאה הזו מתרחשת אם לחשבון השירות של ההתראות אין הרשאה לשלוח התראות בנושאי Pub/Sub שמעניינים אתכם, או אם Pub/Sub API לא מופעל בפרויקט שלכם.

כדי לראות את ההרשאות של חשבון שירות, אפשר להשתמש במסוףGoogle Cloud או בפקודה הבאה של Google Cloud CLI:

  • בדף IAM במסוף Google Cloud מפורטים התפקידים של כל חשבון שירות.
  • בדף Topics של Pub/Sub במסוף Google Cloud מופיע כל נושא. כשבוחרים נושא, בכרטיסייה Permissions מופיעים התפקידים שהוקצו לחשבונות השירות.

  • כדי להציג רשימה של כל חשבונות השירות והתפקידים שלהם, מריצים את הפקודה הבאה ב-Google Cloud CLI:

    gcloud projects get-iam-policy PROJECT_ID

    זו תגובה חלקית לפקודה הזו:

    serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
   role: roles/monitoring.notificationServiceAgent
   - members:
   [...]
   role: roles/owner
   - members:
   - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
   role: roles/pubsub.publisher

    התשובה של הפקודה כוללת רק תפקידים, ולא כוללת הרשאות לכל נושא.

  • כדי להציג את הקישורים של IAM לנושא ספציפי, מריצים את הפקודה הבאה:

    gcloud pubsub topics get-iam-policy TOPIC_ID

    זוהי דוגמה לתגובה לפקודה הזו:

    bindings:
- members:
   - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
   role: roles/pubsub.publisher
etag: BwXPRb5WDPI=
version: 1

במאמר הרשאת חשבון שירות מוסבר איך להעניק הרשאה לחשבון השירות של שירות ההתראות.

היומנים כוללים שגיאה מסוג FAILED_PRECONDITION

כשמריצים שאילתה ביומן notification_channel_events כדי לחפש שגיאות, יכול להיות שתופיע רשומה ביומן שהשדה summary שלה כולל את ההודעה הבאה:

An error occurred while publishing notification to Cloud Pub/Sub topic TOPIC_ID: FAILED_PRECONDITION

השגיאה הזו מתרחשת כש-Pub/Sub דוחה בקשת פרסום מ-Monitoring כי נושא היעד לא עומד בתנאי מוקדם נדרש. הנה כמה סיבות נפוצות לשגיאה הזו:

  • מדיניות אחסון הודעות והגבלות על מיקום אחסון הנתונים: מדיניות אחסון ההודעות בנושא מגבילה את Google Cloud האזורים שבהם אפשר לעבד או לאחסן הודעות:

    • אכיפה בזמן ההעברה באזור שאסור לפרסם בו: מדיניות האחסון של ההודעות בנושא enforceInTransit מוגדרת ל-true, ובקשת הפרסום מגיעה מאזור שלא נכלל ב-allowedPersistenceRegions. אם enforceInTransit הוא true, מערכת Pub/Sub דוחה בקשות מאזורים שלא מורשים במקום להפנות אותן. אם הנושא משתמש בטרנספורמציות של הודעות בודדות באמצעות הסקת מסקנות מ-AI, אז גם האזור שבו מתבצע הפרסום צריך להיות מותר על ידי הטרנספורמציה.
    • אזורים מוגבלים שבהם מותרת שמירת נתונים: הנושא enforceInTransit מוגדר ל-false ובקשת הפרסום מגיעה מחוץ ל-allowedPersistenceRegions, אבל Pub/Sub לא יכול להפנות את הבקשה כי אין אשכול מתאים זמין ו-allowedPersistenceRegions מכיל רק אזורים פרטיים או מוגבלים.
    • שכפול סינכרוני בין אזורים ללא אזור משני תקין: הנושא משתמש בשכפול סינכרוני בין אזורים ויש לו מדיניות אחסון הודעות, אבל allowedPersistenceRegions לא כולל אזור שכפול משני תקין למיקום הפרסום.
    • נקודת קצה אזורית ללא אכיפה של הצפנה במעבר: בקשת הפרסום מנותבת אל נקודת קצה אזורית, אבל במדיניות אחסון ההודעות של הנושא, הערך של enforceInTransit מוגדר כ-false.

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

  • שגיאות שקשורות למפתחות הצפנה בניהול הלקוח (CMEK): הנושא מוגדר לשימוש במפתח הצפנה בניהול הלקוח מ-Cloud Key Management Service ‏(Cloud KMS), ו-Pub/Sub לא יכול להצפין את ההודעה שפורסמה:

    • נדחתה הרשאה במפתח Cloud KMS: ‏ Cloud KMS מחזיר שגיאה PERMISSION_DENIED כש-Pub/Sub מנסה להצפין את ההודעה, ו-Pub/Sub מדווח על כך כשגיאה FAILED_PRECONDITION. לדוגמה, השגיאה הזו מתרחשת כשלאגנט השירות של Pub/Sub אין את התפקיד CryptoKey Encrypter/Decrypter ‏ (roles/cloudkms.cryptoKeyEncrypterDecrypter) במפתח.
    • מצב של מפתח Cloud KMS שלא ניתן לשימוש: ‏ Cloud KMS מחזיר שגיאה FAILED_PRECONDITION כי גרסת המפתח מושבתת או נהרסה, או כי לא ניתן להגיע למפתח של מנהל מפתחות חיצוני.

    כדי לפתור שגיאות CMEK, צריך לוודא שגרסת מפתח Cloud KMS מופעלת ונגישה, ושלסוכן השירות של Pub/Sub יש את roles/cloudkms.cryptoKeyEncrypterDecrypter התפקיד במפתח.

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

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

מדיניות התראות שעוקבת אחרי המדד compute.googleapis.com/instance/uptime לא תשלח לכם התראה כשהמכונה הווירטואלית מושבתת. במקרה של המדד הזה, מדיניות ההתראות עוקבת רק אחרי סדרות זמן של מכונות וירטואליות שנמצאות במצב RUNNING. אם מכונה וירטואלית נמצאת במצב אחר, כמו STOPPED או DELETED, היא לא תנוטר. מידע על מצבי מכונות וירטואליות זמין במאמר בנושא מחזור החיים של מכונות וירטואליות.

לא מתקבלות התראות על מדיניות התראות לגבי מספר הבקשות

אם לא קיבלתם התראות ממדיניות התראות שעוקבת אחרי מדד serviceruntime.googleapis.com/api/request_count, כדאי לוודא שתקופת ההתאמה של המדיניות לא ארוכה מ-7 שעות ו-30 דקות.

לא מתקבלות הודעות SMS או קודי אימות

אם לא קיבלתם התראות או קודי אימות ב-SMS, כדאי לוודא שלא הגעתם למגבלת הודעות ה-SMS. יכול להיות שיש יומנים שמאשרים את השגיאה הזו. כדאי לבדוק את היומנים של Denied quota token.

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