בעיות מוכרות ב-Eventarc Standard

רגילה

בדף הזה מפורטות בעיות מוכרות ב-Eventarc Standard.

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

הקצאת הרשאות ותזמון

• זמן הפריסה של טריגרים: יכולות לחלוף עד שתי דקות עד שטריגרים חדשים שנוצרו יהפכו לפעילים.

• הקצאת סוכן שירות: כשיוצרים טריגר Eventarc בפעם הראשונה בפרויקט Google Cloud , יכול להיות שיהיה עיכוב בהקצאת סוכן השירות של Eventarc. בדרך כלל אפשר לפתור את הבעיה הזו על ידי ניסיון ליצור את הטריגר מחדש. מידע נוסף זמין במאמר בנושא שגיאות שקשורות לסירוב הרשאה.

הגדרת הטריגר

• טריגרים חוצי-פרויקטים: עדיין אין תמיכה בטריגרים חוצי-פרויקטים. השירות שמקבל את האירועים של הטריגר צריך להיות באותוGoogle Cloud פרויקט כמו הטריגר. אם הבקשות לשירות מופעלות על ידי הודעות שפורסמו בנושא Pub/Sub, הנושא צריך להיות באותו פרויקט כמו הטריגר. איך מעבירים אירועים בין פרויקטים ב- Google Cloud

• טריגרים של יומני ביקורת ב-Cloud ל-Compute Engine: לא משנה איפה המכונה הווירטואלית ממוקמת בפועל, טריגרים של יומני ביקורת ב-Cloud ל-Compute Engine יוצרים אירועים שמקורם באזור יחיד: us-central1. כשיוצרים את הטריגר, מוודאים שהמיקום של הטריגר מוגדר ל-us-central1 או ל-global.

• טריגרים של Cloud Storage במיקומים מרובי-אזורים: טריגרים של Cloud Storage עלולים להיכשל אם אירוע של Cloud Storage מגיע מאזור שלא מורשה על ידי מדיניות אחסון ההודעות של Pub/Sub, ואם נאכפות פעולות במעבר ("enforceInTransit": true). כשיוצרים טריגר של Cloud Storage במיקום מרובה-אזורים, צריך לוודא שמדיניות אחסון ההודעות מאפשרת את כל אזורי המקור במיקום מרובה-האזורים הזה. המדיניות הזו מגדירה איפה ההודעות מאוחסנות במהלך השליחה ואיפה נאכפות פעולות במהלך ההעברה. מידע נוסף מופיע במאמר בנושא הגדרת מדיניות לאחסון הודעות.

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

מטענים ייעודיים (payloads) של אירועים ומסירה

• שידור כפול של יומני ביקורת של Cloud: יש שידור כפול ידוע של יומני ביקורת של Cloud ממקורות מסוימים של אירועים. Google Cloud כשיומנים כפולים מתפרסמים, אירועים כפולים מועברים ליעדים. כדי למנוע כפילויות של אירועים, צריך ליצור טריגרים לשדות שמבטיחים שהאירוע יהיה ייחודי. ההגדרה הזו חלה על סוגי האירועים הבאים:

  • Cloud Storage (serviceName: storage.googleapis.com), methodName: storage.buckets.list
  • ‫Compute Engine (serviceName: compute.googleapis.com), methodName: beta.compute.instances.insert
  • ‫BigQuery (serviceName: bigquery.googleapis.com)

  שימו לב: כשתהליך העבודה מטפל בהסרת כפילויות של אירועים, אתם לא צריכים לוודא שהאירוע ייחודי כשאתם יוצרים טריגר לתהליכי עבודה.

• טיפול בכשלים בהודעות לאירועי Pub/Sub ישירים: אירועי Pub/Sub ישירים לא כוללים את השדה delivery_attempt אלא אם יעד האירוע הוא Cloud Run או פונקציות Cloud Run. יכול להיות שהדבר ישפיע על הטיפול שלכם בכשלים בהודעות.

• קידוד מטען ייעודי (payload) של אירועים: אצל חלק מספקי האירועים, אפשר לבחור לקודד את המטען הייעודי של האירועים כ-application/json או כ-application/protobuf. עם זאת, מטען ייעודי (payload) של אירוע בפורמט JSON גדול יותר ממטען ייעודי בפורמט Protobuf, וזה עלול להשפיע על המהימנות בהתאם ליעד האירוע ולמגבלות שלו על גודל האירוע. כשמגיעים למגבלה הזו, המערכת מנסה לשלוח את האירוע שוב בהתאם למאפייני הניסיון החוזר של שכבת התעבורה של Eventarc, ‏ Pub/Sub. במאמר איך מטפלים בכשלים בהודעות Pub/Sub מוסבר מה קורה אם מגיעים למספר המקסימלי של ניסיונות חוזרים.

יעדים ומגבלות

• גודל הארגומנטים של Workflows: כשמשתמשים ב-Workflows כיעד לטריגר של Eventarc, אירועים שגדולים מהגודל המקסימלי של הארגומנטים של Workflows לא יפעילו את ההרצה של תהליך העבודה. מידע נוסף זמין במאמר מכסות ומגבלות.

• מגבלת עומק של קינון לרשומות ביומן: מגבלת העומק המקסימלית של קינון בכל רשומה ביומן מובנה עבור טריגרים שמשתמשים ביומני הביקורת של Cloud היא 64 רמות. אירועים ביומן שחורגים מהמגבלה הזו מושמטים ולא מועברים על ידי Eventarc.