בקשות API שלא תועדו בממשק המשתמש של Edge

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

תיאור הבעיה

בתמונה הזו אפשר לראות שבקשות API לא מתועדות בממשק המשתמש של Edge כשמתחיל סשן מעקב:

הודעת שגיאה

כשהבעיה הזו מתרחשת, לא יוצגו הודעות שגיאה בממשק המשתמש של Edge.

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

בטבלה הבאה מפורטות סיבות אפשריות לכשל בקבלת בקשות API ב-Edge UI Trace:

הסיבה: בקשות שלא טופלו על ידי מעבד ההודעות

אבחון

כדי לתעד בקשת API בסשן Trace, מעבד ההודעות של הרכיב Edge חייב לעבד את בקשת ה-API. יש כמה סיבות לכך שבקשת API לא מתועדת בעסקת Trace.

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

תרחיש 1: הבקשות לא מגיעות ל-Apigee Edge

• סיבה

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

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• רזולוציה

  אפשר לבדוק את הגדרת ה-DNS באמצעות הפקודה הבאה:

  dig hostName

  אפשר לאמת את הקישוריות לרשת באמצעות הפקודה הבאה:

  telnet hostName port

תרחיש 2: בקשות נכשלות בנתב של Apigee Edge

• סיבה

  בתרחיש הזה, השגיאה עשויה להיגרם כתוצאה מכשל בלחיצת יד של TLS או SSL. במקרה כזה, יכול להיות שתקבלו אחת מהשגיאות הבאות:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  ייתכן גם שתופיע שגיאה של אישור SSL.

• רזולוציה

  כדאי לעיין במדריכים הבאים כדי לפתור את הבעיות האלה:

  כשלים לחיצת יד של TLS או SSL

  בקשה לא תקינה 400 – שגיאת אישור SSL

תרחיש 3: מעבד ההודעות לא יכול לעבד בקשות

• סיבה

  בתרחיש הזה, מעבד ההודעות של Apigee לא יכול למצוא את ה-API Proxy המארח והנתיב הווירטואלי שצוינו. כתוצאה מכך, יכול להיות שתראו השגיאות הבאות:

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• רזולוציה

  אפשר לעיין במדריך הזה כדי לפתור את הבעיה: 404 לא ניתן לזהות את שרת ה-proxy למארח.

הסיבה: שרת ה-proxy ל-API לא נמצא בעץ הסיווג

אבחון

אם מעבד ההודעות לא מצליח למצוא שרת proxy ל-API בעץ הסיווג שלו, בקשות API לאותו שרת proxy לא יוצגו בסשנים של מעקב בממשק המשתמש של Edge.

כדי לברר אם זה המצב, יש לפעול לפי השלבים הבאים:

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

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   פלט לדוגמה:

   הפקודה שלמעלה תציג רשימה של גרסאות קודמות שנפרסו. לדוגמה, אם גרסה 12 נפרסה, יתקבל הפלט הבא:

   [ "12" ]
   

   אלא אם יש לסירוגין שגיאות HTTP 404, סביר להניח שתראו שהגרסה הספציפית נפרסה.

2. קוראים את עץ הסיווג ובודקים אם קיים שם שרת proxy ל-API באמצעות הפקודה הבאה:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

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

רזולוציה

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

1. מתחברים לכל אחד מהמארחים של מעבד ההודעות שחסר להם שרת proxy ספציפי ל-API בעץ הסיווג ומשתמשים בפקודה שבהמשך כדי להפעיל מחדש את מעבד ההודעות:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

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

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. כשמעבד ההודעות מוכן, מאמתים את הזמינות של שרת ה-proxy ל-API באמצעות הפקודה הבאה:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   פלט לדוגמה:

   הפקודה שלמעלה תציג רשימה של גרסאות קודמות שנפרסו. לדוגמה, אם גרסה 12 נפרסה, יתקבל הפלט הבא:

   [ "12" ]
   

   אלא אם יש לסירוגין שגיאות HTTP 404, סביר להניח שתראו שהגרסה הספציפית נפרסה.

4. קוראים את עץ הסיווג ומאמתים את קיומו של שם ה-Proxy ל-API באמצעות הפקודה הבאה:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

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

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

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

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree