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

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

סרטונים

וידאו תיאור
500 Internal Server Error - caused by backend הסרטון מדגים שגיאה בזמן אמת 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 Private Cloud וב-Edge Public Cloud

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

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

API Monitoring

תהליך מספר 1: שימוש ב-API Monitoring

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

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

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

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

  5. משרטטים את קוד התקלה מול הזמן.

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

    ( הגדלת התמונה)

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

    ( הגדלת התמונה)

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

    ( הגדלת התמונה)

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

מעקב

תהליך מספר 2: שימוש בכלי המעקב

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

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

  2. מוודאים שהאפשרות הצגת כל פרטי הזרימה מופעלת:

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

  5. בדרך כלל השגיאה מופיעה בתהליך אחרי השלב Response received from target server (התקבלה תגובה משרת היעד), כמו שמוצג בהמשך:

    ( הגדלת התמונה)

  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. כותרות תגובה ערך
    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. אם אתם משתמשי Private Cloud, אתם יכולים להשתמש ביומני הגישה של 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-source הם:

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

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

אבחון

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

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

    מעקב

    שימוש ב-Trace:

    אם יש לכם סשן Trace של הכשל, אתם יכולים לבצע את השלבים הבאים:

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

    2. בוחרים את השלב Response received from target server (התקבלה תגובה משרת היעד) מתוך בקשת ה-API שנכשלה, כמו שמוצג באיור שלמטה:

      ( הגדלת התמונה)

    3. גוללים למטה לקטע Phase Details (פרטי השלב) ובודקים את Response Content (תוכן התגובה), שמכיל את התגובה משרת הקצה העורפי.

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

      <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 Authorised. המשמעות היא שהמשתמש העביר פרטי כניסה לא תקינים, ולכן הוא מקבל את השגיאה הזו.

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

    מתבצעת שיחה ישירה לשרת העורפי:

    אתם יכולים להתקשר ישירות לשרת העורפי ול:

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

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

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

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

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

    יומני שרתים עורפיים

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

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

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

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

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

רזולוציה

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

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

נקודות חשובות שכדאי לזכור

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

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

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

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

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

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

  • הודעת השגיאה המלאה שזוהתה בבקשות שנכשלו
  • שם הארגון, שם הסביבה ושם ה-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.