מידע על שלבים לפתרון בעיות שיכולים לעזור לכם אם נתקלתם בבעיות בשימוש ב-Pub/Sub.
אי אפשר ליצור נושא
מוודאים שיש לכם את ההרשאות הנדרשות.
כדי ליצור נושא Pub/Sub, צריך את התפקיד עריכה ב-Pub/Sub (roles/pubsub.editor) בניהול זהויות והרשאות גישה (IAM) בפרויקט. אם לא הוקצה לכם התפקיד הזה, פנו לאדמין.
למידע נוסף על פתרון בעיות שקשורות לנושאים, אפשר לעיין בדפים הבאים:
אי אפשר ליצור מינוי
חשוב לוודא שביצעתם את הפעולות הבאות:
מוודאים שיש לכם את ההרשאות הנדרשות. כדי ליצור מינוי ל-Pub/Sub, צריך את תפקיד ה-IAM Pub/Sub Editor (roles/pubsub.editor) בפרויקט. אם לא הוקצה לכם התפקיד הזה, פנו לאדמין.
ציינתם שם למינוי.
ציינתם את השם של נושא קיים שאתם רוצים לצרף אליו את המינוי.
אם יוצרים מינוי לקבלת עדכונים בדחיפה, צריך לציין
https://באותיות קטנות (לאhttp://אוHTTPS://) כפרוטוקול של כתובת ה-URL לקבלת העדכונים בשדהpushEndpoint.
מידע נוסף על פתרון בעיות שקשורות למינויים זמין בדפים הבאים:
פתרון בעיות שקשורות למשיכה, דחיפה, BigQuery או Cloud Storage
פתרון בעיות שקשורות להרשאות
ההרשאות ב-Pub/Sub קובעות אילו משתמשים וחשבונות שירות יכולים לבצע פעולות במשאבי Pub/Sub. הגדרות הרשאות שגויות עלולות לגרום לשגיאות של דחיית הרשאה ולהפריע לזרימת ההודעות. יומני הביקורת מספקים תיעוד מפורט של כל שינויי ההרשאות, וכך מאפשרים לכם לזהות את מקור הבעיות האלה.
כדי לפתור בעיות בהרשאות Pub/Sub באמצעות יומני ביקורת:
קבלת ההרשאות הנדרשות כדי להציג את Logs Explorer.
מידע נוסף מופיע במאמר לפני שמתחילים.
נכנסים לדף Logs Explorer במסוף Google Cloud .
בוחרים פרויקט, תיקייה או ארגון קיימים ב- Google Cloud .
ריכזנו כאן רשימה של מסננים שבהם אפשר להשתמש כדי למצוא יומנים רלוונטיים:
resource.type="pubsub_topic" OR resource.type="pubsub_subscription": אפשר להשתמש בשאילתה הזו כנקודת התחלה כשמנסים לפתור בעיות שקשורות לשינויים בהגדרות של נושאים או מינויים, או לבקרת גישה. אפשר לשלב אותו עם מסננים אחרים כדי לצמצם את החיפוש עוד יותר.
protoPayload.methodName="google.iam.v1.SetIamPolicy": משתמשים בשאילתה הזו כשחושדים שבעיה מסוימת נגרמת בגלל הרשאות שגויות או חסרות. הוא עוזר לעקוב אחרי מי ביצע שינויים במדיניות IAM ואילו שינויים בוצעו. המידע הזה יכול לעזור לפתור בעיות כמו משתמשים שלא מצליחים לפרסם בנושאים או להירשם למינויים, אפליקציות שלא מקבלות גישה למשאבי Pub/Sub או שינויים לא צפויים בבקרת הגישה.
protoPayload.status.code=7: משתמשים בשאילתה הזו כשנתקלים בשגיאות שקשורות באופן מפורש להרשאות. כך תוכלו לזהות אילו פעולות נכשלות ומי מנסה לבצע אותן. אפשר לשלב את השאילתה הזו עם השאילתות הקודמות כדי לזהות את המשאב הספציפי ואת השינוי במדיניות IAM שעלולים לגרום לדחיית ההרשאה.
מנתחים את היומנים כדי לזהות גורמים כמו חותמת הזמן של האירוע, חשבון המשתמש שביצע את השינוי וסוגי השינויים שבוצעו.
על סמך המידע שנאסף מיומני הביקורת, אפשר לבצע פעולות מתקנות.
פתרון בעיות בהרשאות ב-Terraform
כשמשתמשים ב-Pub/Sub עם Terraform, צריך להעניק במפורש את התפקידים הנדרשים בקוד Terraform. לדוגמה, כדי לפרסם, חשבון השירות של האפליקציה צריך את התפקיד roles/pubsub.publisher. אם התפקיד הזה לא מוגדר במפורש בקוד Terraform, יכול להיות שגרסה עתידית של terraform apply תסיר אותו. המצב הזה קורה לעיתים קרובות במהלך עדכונים לא קשורים, וגורם לכך שאפליקציה מהימנה נכשלת פתאום עם שגיאות PERMISSION_DENIED.
הגדרה מפורשת של התפקיד בקוד מונעת רגרסיות מקריות כאלה.
המינוי נמחק
יש שתי דרכים עיקריות למחוק מינויים ל-Pub/Sub:
משתמש או חשבון שירות עם הרשאות מספיקות מוחקים את המינוי בכוונה.
מינוי נמחק אוטומטית אחרי תקופה של חוסר פעילות, שהיא 31 ימים כברירת מחדל. מידע נוסף על מדיניות תפוגת המינוי זמין במאמר בנושא תקופת התפוגה.
כדי לפתור בעיות שקשורות למינוי שנמחק, פועלים לפי השלבים הבאים:
במסוף Google Cloud , עוברים לדף Pub/Sub subscriptions (מינויים ל-Pub/Sub) ומוודאים שהמינוי כבר לא מופיע ברשימה. מידע נוסף על הצגת רשימת המינויים זמין במאמר הצגת רשימת המינויים.
בודקים את יומני הביקורת. עוברים אל Logs Explorer. אפשר להשתמש במסנן
protoPayload.methodName="google.pubsub.v1.Subscriber.DeleteSubscription"כדי למצוא מינויים שנמחקו. בודקים את היומנים כדי לדעת אם מישהו מחק את המינוי או שהוא נמחק בגלל חוסר פעילות. InternalExpireInactiveSubscriptionמציין שמינוי נמחק בגלל חוסר פעילות. מידע נוסף על שימוש ביומני ביקורת לפתרון בעיות מופיע במאמר פתרון בעיות ב-Pub/Sub באמצעות יומני ביקורת.
שגיאה מסוג 403 (Forbidden)
בדרך כלל, שגיאה 403 מציינת שאין לכם את ההרשאות המתאימות לביצוע פעולה. לדוגמה, יכול להיות שתקבלו שגיאת 403 User not authorized כשאתם מנסים לפרסם בנושא או לשלוף ממינוי.
אם השגיאה הזו מופיעה, צריך לבצע את הפעולות הבאות:
- צריך לוודא שהפעלתם את Pub/Sub API במסוףGoogle Cloud .
חשוב לוודא שלגורם המבצע את הבקשה יש את ההרשאות הנדרשות במשאבי Pub/Sub API הרלוונטיים, במיוחד אם משתמשים ב-Pub/Sub API לתקשורת בין פרויקטים.
אם אתם משתמשים ב-Dataflow, ודאו שלחשבון השירות של Dataflow
{PROJECT_NUMBER}@cloudservices.gserviceaccount.comולחשבון השירות של Compute Engine{PROJECT_NUMBER}-compute@developer.gserviceaccount.comיש את ההרשאות הנדרשות במשאב ה-API הרלוונטי של Pub/Sub. מידע נוסף זמין במאמר בנושא אבטחה והרשאות ב-Dataflow.אם אתם משתמשים ב-App Engine, בדקו בדף ההרשאות של הפרויקט אם חשבון שירות של App Engine מופיע כעורך Pub/Sub. אם לא, מוסיפים את חשבון השירות של App Engine כעורך ב-Pub/Sub. בדרך כלל, חשבון השירות של App Engine הוא מהצורה
<project-id>@appspot.gserviceaccount.com.אפשר להשתמש ביומני ביקורת כדי לפתור בעיות שקשורות להרשאות.
קודי שגיאה נפוצים אחרים
רשימה של קודי שגיאה נפוצים אחרים שקשורים ל-Pub/Sub API והתיאורים שלהם מופיעה במאמר קודי שגיאה.
זמני קצוב לתפוגה של חיבורים, חביון או שגיאות ברשת
יכול להיות שתיתקלו בכשלים לסירוגין או בכשלים קבועים כשאתם מנסים להתחבר לשירותים של Pub/Sub באמצעות אפליקציות לקוח. Google Cloudהבעיות האלה יכולות להתבטא בצורות הבאות:
- עיכובים משמעותיים בפרסום הודעות, שעלולים לגרום להצטברות של הודעות שממתינות לעיבוד באפליקציה.
- שגיאות שקשורות לזמן קצוב לתפוגה, כמו gRPC
DEADLINE_EXCEEDED,code = DeadlineExceededאוjava.net.SocketTimeoutException. - כשלים בקלט/פלט של הרשת, כמו שגיאות
UNAVAILABLE: io exceptionאוConnection refusedכשמנסים לגשת לשירותים כמוpubsub.googleapis.comאוoauth2.googleapis.com.
בעיות הקישוריות האלה יכולות לקרות גם בלי לבצע שינויים בהגדרות של Pub/Sub או בקוד האפליקציה. המצב הזה קורה לעיתים קרובות כשחומות אש מקומיות או חומות אש של VPC משתמשות ברשימות היתרים של כתובות IP שמוגדרות מראש עבור Google APIs. שירותי Google, כולל Pub/Sub והתלויות שלו כמו שירותי אימות, משתמשים בטווח דינמי של כתובות IP. אם חומת האש לא לוקחת בחשבון כתובות IP חדשות, היא עלולה לחסום תנועה לכתובות ה-IP החדשות, ולגרום לבעיות בחיבור ובאימות.
כדי להבטיח קישוריות יציבה, מומלץ להימנע מכללים של חומת אש שמבוססים על כתובות IP סטטיות בשירותי Google. במקום זאת:
- מגדירים את חומת האש כך שתאפשר תעבורת נתונים באמצעות טווחי כתובות ה-IP שפורסמו על ידי Google עבור דומיינים שמוגדרים כברירת מחדל, במקום כתובות שמוגדרות בהארדקוד. כדי ללמוד איך להשיג את הטווחים האלה ולעדכן באופן אוטומטי את הכללים בחומת האש, אפשר לעיין במאמר כתובות IP לדומיינים שמוגדרים כברירת מחדל.
- מפעילים גישה פרטית ל-Google, שמאפשרת למופעים ברשת ה-VPC שלכם להגיע לשירותים ולממשקי ה-API של Google בלי לעבור דרך האינטרנט הציבורי, וכך מפשטת את ניהול חומת האש.
JWT לא חוקי: הטוקן חייב להיות טוקן לטווח קצר
אם אתם מקבלים שגיאה כמו Invalid JWT: Token must be a short-lived token (60
minutes) and in a reasonable timeframe כשהאפליקציה שלכם יוצרת אינטראקציה עם Pub/Sub API, בדרך כלל זה מצביע על בעיה בתזמון של פרטי הכניסה לאימות.
השגיאה הזו מתרחשת במהלך האימות של JSON Web Token (JWT) שמשמש לאימות של בקשות API. סיבה נפוצה היא הבדל משמעותי בשעה (הטיה בזמן) בין מכונת הלקוח שבה מופעלת ספריית Pub/Sub לבין שרתי האימות של Google. ל-JWT יש חלון תוקף מוגבל, ולכן פערים בשעון יכולים לגרום למערכת להתייחס אליהם כאל JWT שתוקף השימוש בהם פג או שעדיין לא תקף.
כדי לפתור את הבעיה, צריך לסנכרן את השעון של מכונת הלקוח:
מוודאים שהתאריך, השעה ואזור הזמן במחשב נכונים.
משתמשים בשירות Network Time Protocol (NTP) כדי לשמור על סנכרון של זמן המערכת, ומוודאים שהשירות פועל ומוגדר בצורה נכונה.
שימוש מופרז בפעולות ניהול
אם אתם מגלים שאתם משתמשים ביותר מדי מהמכסת הפעולות האדמיניסטרטיביות, יכול להיות שתצטרכו לשנות את מבנה הקוד. לדוגמה, נניח שיש לנו את הפסאודו קוד הבא. בדוגמה הזו, נעשה שימוש בפעולה אדמיניסטרטיבית (GET) כדי לבדוק אם יש מינוי לפני שהמערכת מנסה להשתמש במשאבים שלו. גם GET וגם CREATE הן פעולות של אדמין:
if !GetSubscription my-sub {
CreateSubscription my-sub
}
Consume from subscription my-sub
דפוס יעיל יותר הוא לנסות לצרוך הודעות מהמינוי (בהנחה שאפשר להיות בטוחים באופן סביר בשם המינוי). בגישה האופטימית הזו, אתם מקבלים או יוצרים את המינוי רק אם יש שגיאה. דוגמה:
try {
Consume from subscription my-sub
} catch NotFoundError {
CreateSubscription my-sub
Consume from subscription my-sub
}
אפשר להשתמש בדוגמאות הקוד הבאות כדי להטמיע את התבנית הזו בשפה הרצויה:
המשך
בדוגמה הבאה נעשה שימוש בגרסה הראשית של ספריית הלקוח Go Pub/Sub (v2). אם אתם עדיין משתמשים בספרייה v1, כדאי לעיין במדריך להעברה לגרסה v2. כדי לראות רשימה של דוגמאות קוד מגרסה 1, אפשר לעיין ב דוגמאות הקוד שהוצאו משימוש.
לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Go במאמר מדריך למתחילים: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Go API.
Java
לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Java במאמר התחלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Java API.
Node.js
לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Node.js במאמר הפעלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Node.js API.
Node.ts
לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Node.js במאמר הפעלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Node.js API.
Python
לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Python במאמר תחילת העבודה המהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של ה-API בשפת Python של Pub/Sub.
C++
לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של C++ במאמר תחילת העבודה המהירה: שימוש בספריות לקוח. מידע נוסף זמין במאמרי העזרה של Pub/Sub C++ API.