פתרון בעיות

בדף זה מוצגים פרטים לגבי פתרון בעיות לכל אחת מהגרסאות של ממשקי Service Infrastructure API הבאים:

• Service Management API
• Service Control API
• ממשק ה-API לניהול של צרכני השירות

הערה: לפרטים על פתרון בעיות ב-Service Infrastructure לגבי Service Usage API, אפשר לעיין במאמר פתרון בעיות.

איך מטפלים באופן כללי בשגיאות של Service Control API

השימוש בממשק Service Control API מאפשר לבצע פעולות ברמת הבקרה על שירותים מנוהלים, כמו רישום ביומן ומעקב. לכן, בדרך כלל אלה יהיו אפליקציות של שרתים שקוראות ל-Service Control API. ריכזנו כאן המלצות כלליות לטיפול בשגיאות ברמת API ל-REST או ל-RPC:

• אתם צריכים לוודא שהקוד שלכם בשרת מתעד את כל השגיאות שהוחזרו על ידי Service Control API. כך תוכלו להשתמש בנתונים האלה כדי לפתור בעיות בשירות המנוהל שלכם.
• אם בשרת מתקבל קוד השגיאה 429 מ-Service Control API, הוא צריך להחזיר את קוד השגיאה 429 ללקוחות שלו.
• אם אין לשרת גישה ל-Service Control API, אפשר לבחור אם להחזיר שגיאת fail-open (להתעלם מהשגיאה) או fail-close (להחזיר את קוד השגיאה 503 ללקוח).
• אם בשרת מתקבל קוד השגיאה 500 מ-Service Control API, הוא צריך להחזיר את קוד השגיאה 500 ללקוחות שלו. שגיאות כאלה בדרך כלל מעידות על באגים ב-Service Control API.
• אם בשרת מתקבלות שגיאות אחרות מ-Service Control API, הוא צריך להחזיר את קוד השגיאה 500 ללקוחות שלו. שגיאות כאלה בדרך כלל מעידות על באגים בשירות המנוהל.

מה משמעות השגיאה "service not enabled"

כדי שתוכלו להשתמש בשירות כלשהו של Google API, אתם צריכים להפעיל את השירות עבור Google Cloud הפרויקט שלכם, ולהעביר בכל בקשת API את מפתח ה-API או אסימון הגישה ל-OAuth שמשויך לפרויקט הזה. פרטים נוספים זמינים במדריך האימות. כדי לתקן את השגיאה הזו, צריך להפעיל את השירות לפרויקט שלכם באמצעות Google Cloud המסוף, Google Cloud CLI או Service Usage API. במאמר הפעלה והשבתה של שירותים מוסבר איך להפעיל את השירות.

איך מתקנים שגיאות permission denied

בדרך כלל השגיאות האלה מתקבלות כאשר ליישות שקוראת ל-API חסרה ההרשאה המתאימה למשאבים מסוימים, בהגדרות של ניהול זהויות והרשאות גישה. פרטים על ההרשאות הנדרשות לכל Service Infrastructure API זמינים בדף Access Control של כל ממשק, בהתאמה:

• בקרת גישה ל-Service Control API
• בקרת גישה ל-Service Management API

איך מבצעים ניסיון חוזר בשגיאות ב-API

מומלץ לבצע ניסיון חוזר גם במרווחי זמן שגדלים באופן מעריכי וגם במרווחי זמן אקראיים. המרווח המינימלי לניסיון חוזר צריך להיות של 30 שניות עבור שגיאות מכסה עם קוד 429, ושל שניה אחת עבור שגיאות בחיבור לשרת עם קוד 500 או קוד 503. לשגיאות אחרות, צריך לבצע נסיון חוזר רק על סמך המידע הנוסף של כל שגיאה. לפרטים נוספים, ראו google.rpc.Code.

איך מבקשים להגדיל את מכסת ה-API

בדף Quotas and Limits מוסבר איך מגישים בקשה להגדלת המכסה לכל Service Infrastructure API, בהתאמה:

• מכסה ל-Service Control API
• מכסה לממשק API לניהול של צרכני השירות
• מכסה ל-Service Management API

איך מתקנים שגיאות "Ownership for domain name cannot be verified"

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