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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

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

הודעת השגיאה

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

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

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

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

אבחון

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

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

תרחיש 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 Unable to identify proxy for host.

הסיבה: לא נמצא 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. אחרי שה-Message Processor מוכן, בודקים את הזמינות של proxy ל-API באמצעות הפקודה הבאה:

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

   פלט לדוגמה:

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

   [ "12" ]
   

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

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

   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