499 חיבור סגור ללקוח

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

אפליקציית הלקוח מקבלת שגיאה לגבי זמן קצוב לתפוגה עבור בקשות API, או שהבקשה נסגרת בפתאומיות בזמן שבקשת ה-API עדיין מתבצעת ב-Apigee.

קוד הסטטוס 499 של בקשות ה-API האלה יופיע ב-API Monitoring וביומני הגישה של NGINX. לפעמים תראו קודי סטטוס שונים ב-API Analytics מפני שהוא מציג את קוד הסטטוס שהוחזר על ידי מעבד ההודעות.

הודעת השגיאה

אפליקציות לקוח עשויות לראות שגיאות כמו: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

מה גורם להשבתה של הזמן הקצוב לתפוגה של הלקוח?

הנתיב הטיפוסי לבקשת API בפלטפורמת Edge הוא לקוח > נתב > מעבד הודעות > שרת קצה עורפי, כפי שמוצג באיור הבא:

הנתבים ומעבדי ההודעות בפלטפורמת Apigee Edge מוגדרים עם ערכי ברירת מחדל מתאימים של זמן קצוב לתפוגה, כדי לוודא שהטיפול בבקשות ה-API לא נמשך זמן רב מדי.

זמן קצוב לתפוגה בלקוח

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

ללקוחות כמו דפדפני אינטרנט ואפליקציות לנייד יש זמן קצוב לתפוגה שהוגדר על ידי מערכת ההפעלה.

הזמן הקצוב לתפוגה של הנתב

הזמן הקצוב לתפוגה שמוגדר כברירת מחדל בנתבים הוא 57 שניות. זה משך הזמן המקסימלי ששרת proxy של API יכול לפעול מהרגע שבו בקשת ה-API מתקבלת ב-Edge, ועד שהתגובה נשלחת בחזרה, כולל התגובה בקצה העורפי וכל כללי המדיניות שבוצעו. כברירת מחדל, אפשר לעקוף את הזמן הקצוב לתפוגה בנתבים ובמארחים הווירטואליים, כפי שמוסבר במאמר הגדרת זמן קצוב לתפוגה של קלט/פלט בנתבים.

זמן קצוב לתפוגה של מעבדי הודעות

הזמן הקצוב לתפוגה שמוגדר כברירת מחדל למעבדי הודעות הוא 55 שניות. זהו משך הזמן המקסימלי שיכול להימשך שרת הקצה העורפי כדי לעבד את הבקשה ולהגיב למעבד ההודעות. אפשר לבטל את הזמן הקצוב לתפוגה שמוגדר כברירת מחדל במעבדי ההודעות או בתוך שרת ה-proxy של ה-API, כמו שמוסבר במאמר הגדרת זמן קצוב לתפוגה של קלט/פלט (I/O) במעבדי הודעות.

אם הלקוח סוגר את החיבור עם הנתב לפני שפג הזמן הקצוב לשרת ה-API של שרת ה-API, תוצג לכם שגיאת זמן קצוב לתפוגה של בקשת ה-API הספציפית. קוד הסטטוס 499 Client Closed Connection מתועד בנתב עבור בקשות כאלה, וניתן לראות אותו ביומנים של API Monitoring ו-NGINX Access.

סיבות אפשריות

ב-Edge, הסיבות האופייניות לשגיאה 499 Client Closed Connection הן:

סיבה התיאור ההוראות לפתרון בעיות הרלוונטיות עבור
הלקוח סגר את החיבור בפתאומיות זה קורה כשהלקוח סוגר את החיבור כי משתמש הקצה ביטל את הבקשה לפני שהיא הושלמה. משתמשים בענן ציבורי ופרטי
זמן קצוב לתפוגה של אפליקציית הלקוח המצב הזה מתרחש כשפג הזמן הקצוב לתפוגה של אפליקציית הלקוח לפני ששרת ה-API של שרת ה-Proxy מספיק לעבד ולשלוח את התגובה. בדרך כלל זה קורה כשהזמן הקצוב לתפוגה של הלקוח קטן מהזמן הקצוב לתפוגה של הנתב. משתמשים בענן ציבורי ופרטי

שלבים נפוצים באבחון

אפשר להשתמש באחד מהכלים/הטכניקות הבאים כדי לאבחן את השגיאה הזו:

  • מעקב באמצעות API
  • יומני הגישה של NGINX

מעקב באמצעות API

כדי לאבחן את השגיאה באמצעות API Monitoring:

  1. עוברים לדף ניתוח > API Monitoring > חקירה.
  2. מסננים לפי 4xx שגיאות ובוחרים את מסגרת הזמן.
  3. יש להציב קוד סטטוס ביחס לזמן.
  4. צריך לבחור תא שיש בו 499 שגיאות, כמו שמוצג בהמשך:

  5. המידע על השגיאה 499 יופיע בחלונית השמאלית כפי שמוצג כאן:

  6. בחלונית השמאלית, לוחצים על View Logs (הצגת היומנים).

    בחלון יומני תנועה, מאתרים את הפרטים הבאים לגבי חלק מהשגיאות 499:

    • בקשה:מספקת את שיטת הבקשה ואת ה-URI ששימשו לביצוע הקריאות
    • זמן תגובה:משך הזמן הכולל שחלף עד הבקשה.

    תוכלו גם לקבל את כל היומנים באמצעות ממשק ה-API של GET יומנים של Monitoring API. לדוגמה, שליחת שאילתות על היומנים של org, env, timeRange וגם status, תאפשר לך להוריד את כל היומנים של עסקאות שבהן תם הזמן הקצוב לתפוגה של הלקוח.

    מאחר ש-API Monitoring מגדיר את שרת ה-Proxy כ-- עבור שגיאות HTTP 499, תוכלו להשתמש ב-API (Logs API) כדי לקבל את שרת ה-Proxy המשויך למארח ולנתיב הווירטואלי.

    לדוגמה : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. בודקים את זמן התגובה כדי לראות אם יש 499 שגיאות נוספות, ולבדוק אם זמן התגובה עקבי (נניח 30 שניות) בכל השגיאות של 499.

יומני הגישה של NGINX

כדי לאבחן את השגיאה באמצעות יומני הגישה של NGINX:

  1. משתמשים בענן פרטי יכולים להשתמש ביומני הגישה של NGINX כדי לזהות את המידע העיקרי על שגיאות HTTP 499.
  2. בודקים את יומני הגישה של NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. אפשר לחפש כדי לראות אם יש שגיאות 499 במהלך פרק זמן ספציפי (אם הבעיה אירעה בעבר) או אם יש בקשות שעדיין נכשלות עם 499.
  4. כדאי לשים לב לפרטים הבאים לגבי חלק מהשגיאות מסוג 499:
    • זמן תגובה כולל
    • URI של בקשה
    • סוכן משתמש

    שגיאה 499 לדוגמה מיומן הגישה של NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    לצורך הדוגמה הזו, אנחנו רואים את הפרטים הבאים:

    • זמן תגובה כולל: 10.001 שניות. זה מציין שהלקוח תם הזמן הקצוב לתפוגה אחרי 10.001 שניות
    • הבקשה: GET /v1/products
    • מארח:api.acme.org
    • סוכן משתמש:okhttp/3.9.1
  5. צריך לבדוק אם ערכי זמן התגובה הכולל ו-User Agent עקביים בכל השגיאות של 499.

הסיבה: הלקוח סגר את החיבור בפתאומיות

אבחון

  1. כשמתבצעת קריאה ל-API מאפליקציית דף אחת שפועלת בדפדפן או באפליקציה לנייד, הדפדפן יבטל את הבקשה אם משתמש הקצה סוגר לפתע את הדפדפן, עובר לדף אינטרנט אחר באותה כרטיסייה או מפסיק את טעינת הדף. לשם כך, יש ללחוץ או להקיש על הפסקת הטעינה.
  2. במקרה כזה, הטרנזקציות בסטטוס HTTP 499 משתנות בדרך כלל בזמן עיבוד הבקשה (זמן תגובה) לכל אחת מהבקשות.
  3. כדי לקבוע אם זו הסיבה, אפשר להשוות בין זמן התגובה ולבדוק אם הוא שונה לכל אחת מהשגיאות 499 באמצעות יומני API Monitoring או יומני NGINX Access, כפי שמוסבר בשלבי האבחון הנפוצים.

רזולוציה

  1. זהו מצב נורמלי ובדרך כלל לא גורם לדאגה אם שגיאות ה-HTTP 499 מתרחשות בכמויות קטנות.

  2. אם זה קורה לעיתים קרובות עם אותו נתיב של כתובת ה-URL, יכול להיות ששרת ה-proxy הספציפי שמשויך לנתיב הזה איטי מאוד והמשתמשים לא רוצים לחכות.

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

    1. במקרה כזה, מגדירים את שרת ה-Proxy המושפע באמצעות השלבים בקטע השלבים לאבחון בעיות נפוצות.
    2. כדאי להשתמש במרכז הבקרה לניתוח זמן האחזור כדי להמשיך לבדוק מה גורם לזמן האחזור של שרת ה-proxy ולפתור את הבעיה.
    3. אם תגלו שזמן האחזור צפוי לשרת ה-Proxy הספציפי, ייתכן שתצטרכו ליידע את המשתמשים שלכם שייקח זמן מה עד ששרת ה-Proxy הזה יגיב.

הסיבה: זמן קצוב לתפוגה של אפליקציית לקוח

מצב כזה יכול להתרחש במספר תרחישים.

  1. צפוי שהשלמת הבקשה תימשך זמן מסוים (למשל, 10 שניות) בתנאי תפעול רגילים. עם זאת, אפליקציית הלקוח מוגדרת עם ערך שגוי של זמן קצוב לתפוגה (נניח 5 שניות), ולכן הזמן הקצוב לתפוגה של אפליקציית הלקוח הוא לפני השלמת בקשת ה-API, שמובילה ל-499. במקרה כזה, עלינו להגדיר את הזמן הקצוב לתפוגה של הלקוח לערך מתאים.
  2. שרת היעד או תוסף היתרונות המרכזיים נמשכים זמן רב מהצפוי. במקרה כזה, צריך לתקן את הרכיב המתאים ולשנות בהתאם את ערכי הזמן הקצוב לתפוגה.
  3. הלקוח לא היה זקוק עוד לתגובה ולכן בוטל. מצב כזה יכול לקרות בממשקי API בתדירות גבוהה, כמו השלמה אוטומטית או סקרים קצרים.

אבחון

יומני הגישה ל-API Monitoring או ל-NGINX

אפשר לאבחן את השגיאה באמצעות API Monitoring או יומני הגישה של NGINX:

  1. כדאי לבדוק ביומני API Monitoring או ביומני הגישה של NGINX עסקאות HTTP 499, כמו שמוסבר בשלבים הנפוצים לאבחון.
  2. קבע אם זמן התגובה תואם לכל השגיאות של 499.
  3. אם כן, ייתכן שאפליקציית לקוח מסוימת הגדירה זמן קצוב לתפוגה קבוע בצד שלה. אם שרת proxy או שרת יעד של API מגיבים לאט, הלקוח יפסיק לפעול בתום הזמן הקצוב לתפוגה של שרת ה-proxy, וכתוצאה מכך יתקבלו כמויות גדולות של HTTP 499s לאותו נתיב URI. במקרה כזה, צריך לאתר את User Agent ביומני הגישה של NGINX שיכול לעזור לכם לזהות את אפליקציית הלקוח הספציפית.
  4. יכול להיות גם שקיים מאזן עומסים מול Apigee, כמו Akamai, F5, AWS ELB וכו'. אם Apigee פועל מאחורי מאזן עומסים מותאם אישית, יש להגדיר את הזמן הקצוב לתפוגה של מאזן העומסים כך שיהיה ארוך יותר מהזמן הקצוב לתפוגה של Apigee API. כברירת מחדל, הזמן הקצוב לתפוגה של נתב Apigee מסתיים לאחר 57 שניות, ולכן הוא מתאים להגדיר זמן קצוב לתפוגה של בקשה ל-60 שניות במאזן העומסים.

נתוני מעקב

מאבחנים את השגיאה באמצעות מעקב

אם הבעיה עדיין פעילה (עדיין מתרחשות 499 שגיאות), יש לבצע את השלבים הבאים:

  1. מפעילים את סשן המעקב ל-API המושפע בממשק המשתמש של Edge.
  2. צריך להמתין עד שהשגיאה תתרחש או אם קיבלתם קריאה ל-API, ולאחר מכן לבצע כמה קריאות ל-API ולשחזר את השגיאה.
  3. עליך לבדוק את הזמן שחלף בכל שלב, ולציין הערה לגבי השלב שבו ניצלת את רוב הזמן.
  4. אם מופיעה שגיאה עם הזמן הארוך ביותר שחלף מיד אחרי אחד מהשלבים הבאים, סימן שהשרת בקצה העורפי איטי או שנדרש לו זמן רב כדי לעבד את הבקשה:
    • הבקשה נשלחה לשרת היעד
    • המדיניות בנושא יתרונות מרכזיים של שירות

    הנה דוגמה למעקב אחר ממשק המשתמש, שמראה תם הזמן הקצוב לתפוגה של השער לאחר שליחת הבקשה לשרת היעד:

רזולוציה

  1. כדאי לעיין ב שיטות המומלצות להגדרת זמן קצוב לתפוגה של קלט/פלט כדי להבין אילו ערכים של זמן קצוב לתפוגה צריך להגדיר ברכיבים שונים שקשורים לתהליך בקשת ה-API דרך Apigee Edge.
  2. חשוב להגדיר ערך מתאים של זמן קצוב לתפוגה באפליקציית הלקוח בהתאם לשיטות המומלצות.

אם הבעיה נמשכת, עוברים אל חובה לאסוף פרטי אבחון .

צריך לאסוף פרטי אבחון

אם הבעיה נמשכת, אספו את פרטי האבחון הבאים וצרו קשר עם התמיכה של Apigee Edge.

אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:

  • שם הארגון
  • שם הסביבה
  • שם שרת proxy ל-API
  • השלמת הפקודה curl שמשמשת לשחזור השגיאה של הזמן הקצוב לתפוגה
  • קובץ מעקב לבקשות API שלגביהן מופיעות שגיאות בנוגע לזמן הקצוב לתפוגה של לקוח

אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:

  • זוהתה הודעת שגיאה מלאה בבקשות שנכשלו
  • שם הסביבה
  • חבילת שרת proxy ל-API
  • קובץ מעקב לבקשות API שלגביהן מופיעות שגיאות בנוגע לזמן הקצוב לתפוגה של לקוח
  • יומני הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • יומני המערכת של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)