פתרון בעיות שקשורות לשגיאות בתגובות

בדף הזה מוסבר איך לפתור בעיות שגיאה שמתקבלות בתגובה לבקשה שנשלחת ל-API.

Upstream backend unavailable

אם קיבלתם את קוד השגיאה 14 ואת ההודעה upstream backend unavailable, המשמעות היא ש-Extensible Service Proxy‏ (ESP) לא יכול להגיע לחלק האחורי של השירות. כדאי לבדוק את הדברים הבאים:

  • מוודאים ששירות הקצה העורפי פועל. הדרך לעשות את זה תלויה ב-backend.

  • כתובת ה-IP הנכונה של השירות לקצה העורפי מצוינת:
    • ב-GKE, בודקים את ערך הדגל של ESP‏ --backend (האפשרות הקצרה היא -a) בקובץ המניפסט של הפריסה (לרוב נקרא deployment.yaml).
    • ב-Compute Engine, בודקים את ערך הדגל של ESP‏ --backend (האפשרות הקצרה היא -a) בפקודה docker run.

reset reason: connection failure

אם מקבלים קוד HTTP‏ 503 או קוד gRPC‏ 14 וההודעה upstream connect error or disconnect/reset before headers. reset reason: connection failure, המשמעות היא ש-ESPv2 לא יכול להגיע לקצה העורפי של השירות.

כדי לפתור את הבעיה, צריך לבדוק היטב את הפרטים הבאים.

כתובת קצה עורפי

צריך להגדיר את ESPv2 עם כתובת הבק-אנד הנכונה. בעיות נפוצות:

  • הסכימה של כתובת ה-Backend צריכה להתאים לסוג אפליקציית ה-Backend. ב-OpenAPI, קצה העורפי צריך להיות http://, וב-gRPC, קצה העורפי צריך להיות grpc://.
  • ב-ESPv2 שפריסה ב-Cloud Run, הסכימה של כתובת ה-Backend צריכה להיות https:// או grpcs://. הפקודה s אומרת ל-ESPv2 להגדיר TLS עם הקצה העורפי.

חיפוש DNS

כברירת מחדל, ESPv2 מנסה לזהות שמות דומיינים לכתובות IPv6. אם הרזולוציה של IPv6 נכשלת, ESPv2 חוזר לכתובות IPv4.

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

השגיאה הזו נפוצה אם מגדירים Serverless VPC Connector ל-ESPv2 שנפרס ב-Cloud Run. רשתות VPC לא תומכות בתעבורת IPv6.

API is not enabled for the project

אם שלחתם מפתח API בבקשה, הודעת שגיאה כמו "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" מציינת שמפתח ה-API נוצר בפרויקט אחר ב- Google Cloudולא בפרויקט שבו ה-API מופעל. כדי לפתור את הבעיה, אפשר ליצור את מפתח ה-API באותו פרויקט Google Cloud שה-API משויך אליו, או להפעיל את ה-API בפרויקט Google Cloud שבו נוצר מפתח ה-API.

Service control request failed with HTTP response code 403

אם קיבלתם את קוד השגיאה 14 ואת ההודעה Service control request failed with HTTP response code 403, המשמעות היא ש-Service Control API‏ (servicecontrol.googleapis.com) לא מופעל בפרויקט.

  1. כדי לוודא שכל השירותים שנדרשים ל-Endpoints ול-ESP מופעלים בפרויקט, אפשר לעיין במאמר בנושא בדיקת השירותים הנדרשים.

  2. כדי לוודא שלחשבון השירות שמשויך למופע שבו פועל ESP יש את כל ההרשאות הנדרשות, אפשר לעיין במאמר בנושא בדיקת ההרשאות הנדרשות.

Method doesn't allow unregistered callers

מערכת ESP מגיבה בשגיאה Method doesn't allow unregistered callers אם ציינתם allow_unregistered_calls: false בקובץ ההגדרות של gRPC API, אבל לבקשה ל-API לא הוקצה מפתח API לפרמטר שאילתה בשם key.

אם אתם צריכים ליצור מפתח API כדי לבצע קריאות ל-API, תוכלו לעיין במאמר בנושא יצירת מפתח API.

Method does not exist

התגובה Method does not exist מציינת שלא נמצאה שיטת HTTP ‏(GET, POST או אחרת) בנתיב כתובת ה-URL שצוין. כדי לפתור בעיות, משווים את הגדרת השירות שפרסתם כדי לוודא ששם השיטה ונתיב כתובת ה-URL שאתם שולחים בבקשה זהים:

  1. נכנסים לדף Endpoints Services במסוף Google Cloud של הפרויקט.

    לדף Endpoints Services

  2. אם יש לכם יותר מ-API אחד, בוחרים את ה-API שאליו שלחתם את הבקשה.

  3. לוחצים על הכרטיסייה היסטוריית הפריסה.

  4. בוחרים את הפריסה האחרונה כדי לראות את הגדרת השירות.

Transport is closing

אם קיבלתם את קוד השגיאה 13 ואת ההודעה transport is closing, זה מצביע על כך שספק ה-ESP לא נגיש.

בודקים את יומני השגיאות של ספק שירותי האימייל. הדרך לעשות את זה תלויה ב-backend. מידע נוסף מפורט במאמרים הבאים:

תגובות לא צפויות

אם תגובת ה-HTTP נראית בינארית, יכול להיות שהבקשה מגיעה ל-API דרך יציאה HTTP2, כשבעצם התכוונתם להשתמש ביציאה HTTP1.

בודקים את אפשרויות ההגדרה של היציאה עבור ESP. מכיוון שהדגלים של הטופס הקצר, -p (עבור HTTP1) ו--P (עבור HTTP2), נראים דומים, אנו ממליצים להשתמש בדגלים של הטופס הארוך במקום זאת: --http_port עבור HTTP1 ו---http2_port עבור HTTP2.

הגדרה שגויה של העורף של ה-ESP עלולה גם לגרום לתגובות לא צפויות. מוודאים שדגל ה-Backend ‏ (-a או --backend) מוגדר לכתובת URL של gRPC, כמו --backend=grpc://127.0.0.1:8081.

פרטים נוספים על הדגלים של ESP זמינים במאמר בנושא אפשרויות הפעלה של ESP.

בדיקת היומנים ב-Cloud Logging

כדי להשתמש ביומנים של Cloud Logging כדי לפתור בעיות שקשורות לשגיאות בתגובה:

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

    כניסה לדף Logs Explorer

  2. בחלק העליון של הדף, בוחרים את Google Cloud הפרויקט.

  3. בתפריט הנפתח שמימין, בוחרים באפשרות Produced API (API שנוצר) >‏ [YOUR_SERVICE_NAME] (שם השירות שלכם).

  4. משנים את טווח הזמן עד שמופיעה שורה עם שגיאת התגובה.

  5. מרחיבים את מטען ה-JSON הייעודי ומחפשים את error_cause.

    • אם הערך של error_cause הוא application, סימן שיש בעיה בקוד.

    • אם הערך של error cause הוא משהו אחר ואתם לא מצליחים לפתור את הבעיה, אתם יכולים לייצא את היומן ולצרף אותו לכל פנייה שלכם אל Google.

מידע נוסף מפורט במאמרים הבאים: