פתרון בעיות ב-Eventarc for Workflows

בדף הזה מוסבר איך לפתור בעיות שאתם עלולים להיתקל בהן כשמשתמשים ב-Eventarc for Workflows.

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

יצירת הטריגר נכשלת כי יעד תהליך העבודה לא קיים

מופיעה הודעת שגיאה שדומה להודעה הבאה: 

cloud workflow "projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_ID" does not exist
הפלט הזה כולל את הערכים הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
  • ‫LOCATION: המיקום של זרימת העבודה
  • ‫WORKFLOW_ID: השם של תהליך העבודה

השגיאה הזו מתרחשת כש-Eventarc לא מצליח למצוא את תהליך העבודה של היעד. כדי לפתור את הבעיה:

  1. מוודאים שקיים תהליך עבודה של היעד והוא פעיל: 

    gcloud workflows list --location -

    הפלט אמור להיראות כך: 

    NAME                                                          STATE   REVISION_ID  UPDATE_TIME
projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_ID  ACTIVE  000004-c0c   2021-11-19T14:29:27.530185556Z

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

הטריגר נוצר בהצלחה אבל היעד לא מקבל אירועים

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

אם הטריגר עדיין לא פועל והאירועים לא מועברים:

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

    לפני שמגדירים את נושא להודעות ללא מוצא, מאחזרים את הנושא ואת המינוי של הטריגר:

    gcloud eventarc triggers describe TRIGGER \
--location=LOCATION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫TRIGGER: המזהה של הטריגר או מזהה מלא.
    • ‫LOCATION: המיקום של טריגר Eventarc.

  2. אפשר להשתמש במסוף Google Cloud כדי לעקוב אחרי פרסום ההודעות בנושא Pub/Sub באמצעות המדד: topic/send_message_operation_count.

  3. אם ההודעות לא מתפרסמות בנושא Pub/Sub, צריך לוודא שהמקור יוצר אירועים:

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

    • כדי לבדוק אירועים מ-Cloud Storage, בודקים את ההתראות לגבי הקטגוריה:

      ‫
      gcloud storage buckets notifications list gs://BUCKET_NAME
       מחליפים את BUCKET_NAME בשם הקטגוריה.
      הפלט אמור להיראות כך:

      projects/_/buckets/BUCKET_NAME/notificationConfigs/NOTIFICATION_CONFIG_ID
Cloud Pub/Sub topic: projects/PROJECT_ID/topics/TOPIC_ID
Filters:
  Event Types: OBJECT_ARCHIVE

      הפלט הזה כולל את הערכים הבאים:

      • ‫TOPIC_ID: המזהה של נושא ה-Pub/Sub הקיים.
      • ‫NOTIFICATION_CONFIG_ID: המזהה של הגדרת ההתראה.

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

  5. אם הודעות מתפרסמות בנושא Pub/Sub אבל לא מופעלות הרצות של תהליכי עבודה, צריך לוודא שהמטען הייעודי (payload) של Eventarc לא גדול מ-512 KB. מידע נוסף על מגבלות משאבים זמין במאמר מכסות ומגבלות.

    1. נכנסים לדף Subscriptions במסוף Cloud.

      לדף "מינויים"

    2. מעקב אחר הודעות שלא אושרו במינוי. מידע נוסף זמין במאמר בנושא מעקב אחרי הודעות שלא נמסרו שהועברו.

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

      • משתמשים במסנן Permission 'workflows.executions.create' denied כדי לוודא שהטריגר משויך לחשבון שירות שיש לו הרשאה להפעיל הרצות של תהליכי עבודה. כדי לקבל מידע נוסף על הקצאת התפקידים המתאימים לחשבון השירות, אפשר לעקוב אחר ההוראות שבקטע 'הכנה ליצירת טריגר' כשיוצרים טריגר עבור ספק ספציפי, סוג אירוע ויעד של Workflows.
      • משתמשים במילת המפתח event size exceeded כדי לוודא שגודל האירוע גדול מ-512 KB.

    4. אם היומנים מתועדים אבל האירועים לא מועברים, פנו לתמיכה.