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

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

BAD_GATEWAY

אם מקבלים את קוד השגיאה 13 ואת ההודעה BAD_GATEWAY, המשמעות היא ש-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 אם ציינתם מפתח API בקטע security במסמך OpenAPI, אבל לבקשה ל-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. בוחרים את הפריסה האחרונה כדי לראות את הגדרת השירות.

אם השיטה שאתם קוראים לה לא מופיעה בקטע paths של מסמך OpenAPI, אתם יכולים להוסיף את השיטה או את הדגל x-google-allow ברמה העליונה של הקובץ:

x-google-allow: all

הדגל הזה מאפשר לכם להימנע מפירוט כל השיטות שנתמכות בקצה העורפי במסמך OpenAPI. כשמשתמשים ב-all, כל הקריאות – עם או בלי מפתח API או אימות משתמש – עוברות דרך ESP אל ה-API שלכם. מידע נוסף זמין במאמר x-google-allow.

שגיאות שספציפיות לסביבה הגמישה של App Engine

בקטע הזה מתוארות תגובות שגיאה מ-APIs שנפרסו בסביבה הגמישה של App Engine.

קוד שגיאה 502 או 503

יכול להיות שיחלפו כמה דקות עד ש-App Engine יגיב לבקשות בהצלחה. אם שולחים בקשה ומקבלים בתגובה HTTP 502, 503 או שגיאת שרת אחרת, צריך לחכות דקה ולנסות לשלוח את הבקשה שוב.

הודעת השגיאה BAD_GATEWAY

קוד שגיאה 502 עם BAD_GATEWAY בהודעה מציין בדרך כלל ש-App Engine הפסיק את האפליקציה כי נגמר לה הזיכרון. ל-VM גמיש של App Engine שמוגדר כברירת מחדל יש רק 1GB של זיכרון, ורק 600MB זמינים למאגר האפליקציות.

כדי לפתור את הבעיה שקוד השגיאה שלה הוא 502:

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

    כניסה לדף Logs Explorer

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

  3. בוחרים באפשרות Google App Engine Application ופותחים את vm.syslog.

  4. מחפשים רשומה ביומן שדומה לזו:

    kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

    אם מופיעה רשומה של Out of memory ביומן:

    1. כדי להגדיל את הגודל של מכונת ה-VM שמוגדרת כברירת מחדל, מוסיפים את השורות הבאות לקובץ app.yaml:

      resources:
  memory_gb: 4

    2. פורסים מחדש את ה-API:

      gcloud app deploy

אם האפשרות rollout_strategy: managed מצוינת בקטע endpoints_api_service של הקובץ app.yaml, משתמשים בפקודה הבאה כדי לפרוס מחדש את ה-API:

  gcloud app deploy

מידע נוסף מופיע במאמר בנושא פריסת ה-API וספק ה-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.

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

בעיות בפונקציה לדוגמה Invoke-WebRequest

בגרסאות מסוימות של Windows PowerShell, הדוגמה Invoke-WebRequest בהדרכות נכשלת. קיבלנו גם דיווח שהתגובה הכילה רשימה של בייטים לא חתומים שהיה צריך להמיר לתווים. אם הדוגמה Invoke-WebRequest לא הניבה את התוצאה הרצויה, נסו לשלוח את הבקשה באמצעות אפליקציה אחרת. הנה כמה הצעות:

  • מפעילים את Cloud Shell ופועלים לפי השלבים ל-Linux במדריך שבו השתמשתם כדי לשלוח את הבקשה.

  • מתקינים אפליקציה של צד שלישי, כמו התוסף לדפדפן Chrome‏ Postman (שמוצע על ידי www.getpostman.com). כשיוצרים את הבקשה ב-Postman:

    • בוחרים באפשרות POST כפועל ה-HTTP.
    • בכותרת, בוחרים את המפתח content-type ואת הערך application/json.
    • בגוף ההודעה, מזינים: {"message":"hello world"}

    • בכתובת ה-URL, משתמשים במפתח ה-API בפועל ולא במשתנה הסביבה. לדוגמה:

      • בסביבה הגמישה של App Engine: https://example-project-12345.appspot.com/echo?key=AIza...
      • במערכות קצה אחרות: http://192.0.2.0:80/echo?key=AIza...

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

    --data "{\"message\":\"hello world\"}"