500 שגיאת שרת פנימית - שרת עורפי

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

סרטונים

וידאו התיאור
שגיאת שרת פנימית 500 – נגרמה על ידי הקצה העורפי מדגים 500 Internal Server Error בזמן אמת שנגרם על ידי שרת הקצה העורפי, יחד עם שלבים לפתרון השגיאה.

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 500 עם ההודעה Internal Server Error כתגובה לקריאות ל-API.

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

הודעות שגיאה

אפליקציית הלקוח מקבלת את קוד התגובה הבא: 

HTTP/1.1 500 Internal Server Error

בנוסף, ייתכן שתופיע הודעת שגיאה שדומה לזו:

דוגמה מס' 1

דוגמה מס' 1 לתגובה של שרת הקצה העורפי

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

דוגמה מס' 2

דוגמה מס' 2 לתגובה של שרת הקצה העורפי

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

גורמים אפשריים

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

הסיבות האפשריות לכך הן:

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

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

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

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

הליך מס' 1: שימוש ב-API Monitoring

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

  1. נכנסים לממשק המשתמש של Apigee Edge בתור משתמשים עם תפקיד מתאים.

  2. עוברים לארגון שבו רוצים לבדוק את הבעיה.

  3. עוברים לדף ניתוח > API Monitoring > חקירה.
  4. בוחרים את מסגרת הזמן הספציפית שבה הבחנתם בשגיאות.

  5. יש להציב את קוד השגיאה ביחס ל-Time.

  6. בוחרים תא שמכיל את קוד השגיאה messaging.adaptors.http.flow.ErrorResponseCode כפי שמוצג למטה:

    ( הצגת תמונה גדולה יותר)

  7. מידע על קוד התקלה messaging.adaptors.http.flow.ErrorResponseCode מוצג כפי שמוצג למטה:

    ( הצגת תמונה גדולה יותר)

  8. לוחצים על View Logs (הצגת היומנים) ומרחיבים את השורה של הבקשה שנכשלה.

    ( הצגת תמונה גדולה יותר)

  9. בחלון Logs, שימו לב לפרטים הבאים:
    • מזהה ההודעה של הבקשה
    • קוד סטטוס: 500
    • מקור התקלה: target
    • קוד שגיאה: messaging.adaptors.http.flow.ErrorResponseCode

נתוני מעקב

הליך מס' 2: שימוש בכלי המעקב

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

  1. מפעילים את סשן המעקב ואז
    • להמתין עד שתתרחש השגיאה 500 Internal Server Error עם קוד השגיאה messaging.adaptors.http.flow.ErrorResponseCode, או
    • אם הצלחת לשחזר את הבעיה, יש לבצע את הקריאה ל-API כדי לשחזר את הבעיה 500 Internal Server Error

  2. יש לוודא שהאפשרות Show allflowInfos מופעלת:

  3. בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
  4. אפשר לנווט בשלבים השונים של המעקב ולאתר את המיקום שבו אירעה הכשל.

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

    ( הצגת תמונה גדולה יותר)

  6. מנווטים לשלב AX (רישום נתונים ב-Analytics) במעקב ולוחצים עליו.

  7. גוללים למטה לקטע Phase Details Response Headers ומוצאים את הערכים של X-Apigee-fault-code ו-X-Apigee-fault-source, ושל X-Apigee-Message-ID, לפי ההוראות הבאות:

    ( הצגת תמונה גדולה יותר)

  8. שימו לב לערכים של X-Apigee-fault-code, X-Apigee-fault-source, ו-X-Apigee-Message-ID:
    9. כותרות תגובה Value
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

הליך מס' 3: שימוש ביומני גישה של NGINX

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

  1. אם אתם משתמשים בענן פרטי, תוכלו להשתמש ביומני הגישה של NGINX כדי לזהות את המידע העיקרי על HTTP 500 Internal Server Error.

  2. כדאי לבדוק את יומני הגישה של NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. אפשר לחפש כדי לראות אם יש שגיאות 500 עם קוד השגיאה messaging.adaptors.http.flow.ErrorResponseCode במהלך משך זמן ספציפי (אם הבעיה אירעה בעבר) או אם יש בקשות שעדיין נכשלות עם 500.

  4. אם יש שגיאות 500 כאשר X-Apigee-fault-code שתואם לערך של messaging.adaptors.http.flow.ErrorResponseCode, צריך לקבוע את הערך של X-Apigee-fault-source.

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

    ( הצגת תמונה גדולה יותר)

    הרשומה לדוגמה שלמעלה מיומן הגישה של NGINX כוללת את הערכים הבאים עבור X-Apigee-fault-code ו-X-Apigee-fault-code

    כותרות Value
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

הסיבה: שגיאה בשרת הקצה העורפי

אבחון

יכולות להיות כמה סיבות להצגת התגובה של שרת הקצה העורפי 500 Internal Server Error. תצטרכו לאבחן כל מצב בנפרד.

  1. קובעים את קוד ה-Fault, מקור ה-Fault של השגיאה שנצפתה באמצעות API Monitoring, כלי המעקב או יומני הגישה של NGINX, כמו שמוסבר בשלבי האבחון הנפוצים.
  2. אם Fault Source הוא target ו-Fault Code (קוד שגיאה) הוא messaging.adaptors.http.flow.ErrorResponseCode, המשמעות היא שהשגיאה מוחזרת על ידי שרת הקצה העורפי.
  3. כדי לאבחן את הגורם לבעיה, אפשר לבצע אחת מהפעולות הבאות:

    נתוני מעקב

    שימוש במעקב:

    אם יש לכם הפעלת מעקב לכשל, עליכם לבצע את השלבים הבאים:

    1. ב'מעקב', בוחרים את בקשת ה-API שנכשלה עם 500 Internal Server Error.

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

      ( הצגת תמונה גדולה יותר)

    3. גוללים למטה לקטע פרטי השלב ובודקים את תוכן התגובה,שמכיל את התגובה משרת הקצה העורפי.

      דוגמה לתוכן תשובה:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

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

    שרת לקצה העורפי של שיחות

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

    אתם יכולים לבצע שיחה ישירה לשרת הקצה העורפי, וגם:

    • יש לך אפשרות לאמת אם קיבלת את אותה תגובת 500 Internal Server Error שקיבלת כשהבקשה נשלחה דרך Apigee Edge
    • בדיקת הודעת השגיאה (תגובה) שהתקבלה משרת הקצה העורפי

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

    1. חשוב לוודא שיש לך את כל הכותרות הנדרשות, הפרמטרים של השאילתה וכל פרטי הכניסה שצריך להעביר לשרת הקצה העורפי כחלק מהבקשה.
    2. אם השירות לקצה העורפי נגיש לציבור, אפשר להשתמש בפקודה curl, ב-Postman או בכל לקוח REST אחר ולהפעיל את ה-API של שרת הקצה העורפי באופן ישיר.

    3. אם אפשר לגשת לשרת הקצה העורפי רק דרך מעבדי ההודעות, אפשר להשתמש בפקודה curl, ב-Postman או בכל לקוח REST אחר ולהפעיל את ה-API של שרת הקצה העורפי ישירות ממעבד ההודעות.

    4. צריך לבדוק אם השירות לקצה העורפי אכן מחזיר 500 Internal Server Error, לבדוק את הודעת השגיאה (תגובה) שהוחזרה על ידי השרת לקצה העורפי ולקבוע מה הסיבה לשגיאה הזו.

    יומנים של שרת קצה עורפי

    שימוש ביומנים של שרת הקצה העורפי

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

  4. צריך לבדוק אם נעשה שימוש בשרשור של שרת Proxy בנקודת הקצה הספציפית של היעד של שרת ה-Proxy שנכשל. כלומר, אם שרת היעד או נקודת הקצה של היעד מפעילים שרת proxy אחר ב-Apigee Edge. כדי לקבוע זאת:

    1. אם יש לכם את נתוני המעקב של הבקשה שנכשלה, מנווטים לשלב Request send to target server (הבקשה נשלחה לשרת יעד) ולוחצים על Show Curl.

    2. החלון Curl for Request Shet to Request to Target Server ייפתח, ממנו תוכלו לקבוע את הכינוי של שרת היעד כמארח.
    3. צריך לבדוק את נקודת הקצה של היעד של שרת ה-proxy של ה-API ולבדוק אם כתובת ה-URL של שרת הקצה העורפי או שם המארח בשרת היעד מפנה לשרת Proxy אחר או לשרת הקצה העורפי שלך.
    4. אם הכינוי של שרת היעד מפנה לכינוי מארח וירטואלי, מדובר בשרשור של שרת proxy. במקרה כזה, צריך לחזור על כל השלבים שלמעלה עבור שרת ה-proxy המשורשר עד שמוצאים את הגורם בפועל ל-500 Internal Server Error. במקרים האלה, 500 Internal Server Error עשוי להתרחש גם בשרתי proxy אחרים בשרשרת בשלבים אחרים, וניתן לאבחן ולפתור אותם לפי ההוראות במדריך הזה או ב מדריך 500 Internal Server Error.
    5. אם הכינוי של שרת היעד מפנה לשרת הקצה העורפי, עוברים אל פתרון.

רזולוציה

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

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

נקודות עיקריות שכדאי לשים לב אליהן

  1. ניתן להציג את הודעת השגיאה בפועל שהוחזרה על ידי שרת הקצה העורפי עבור 500 Internal Server Error רק אם תיעדת את פעילות המעקב לבקשות שנכשלו.
  2. מטעמי אבטחה, התגובה של שרת הקצה העורפי לא תירשם ב-API Monitoring, ביומני הגישה של NGINX או ביומנים של מעבד ההודעות.
  3. אפשר לעיין ביומנים של שרת הקצה העורפי או להפעיל את מצב ניפוי הבאגים בקצה העורפי כדי לקבל פרטים נוספים על 500 Internal Server Error או להציג את הודעת השגיאה שהוחזרה על ידי שרת הקצה העורפי.

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

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

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

  • שם הארגון
  • שם הסביבה
  • שם שרת proxy ל-API
  • צריך להשלים את הפקודה curl כדי לשחזר את השגיאה 500
  • קובץ מעקב שמכיל את הבקשות עם 500 Internal Server Error
  • אם השגיאות 500 לא מתרחשות כרגע, עליך לציין את תקופת הזמן עם פרטי אזור הזמן שבהם התרחשו שגיאות מסוג 500 בעבר.

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

  • זוהתה הודעת שגיאה מלאה בבקשות שנכשלו
  • הארגון, שם הסביבה ושם ה-proxy של ה-API שלגביהם מוצגות שגיאות מסוג 500
  • חבילת proxy ל-API
  • קובץ מעקב שמכיל את הבקשות עם 500 Internal Server Error
  • יומני הגישה של NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    היכן:ORG, ENV ו-PORT# מוחלפים בערכים בפועל.

  • יומני המערכת של מעבד ההודעות /opt/apigee/var/log/edge-message-processor/logs/system.log
  • תקופת הזמן עם פרטי אזור הזמן שבה אירעו השגיאות מסוג 500.