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

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

  1. נכנסים ל-Apigee Edge UI כמשתמש עם התפקיד המתאים.

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

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

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

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

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

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

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

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

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

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

Trace

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

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

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

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

  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. כותרות של תשובות ערך
    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-source:

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

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

אבחון

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

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

    Trace

    באמצעות Trace:

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

    1. בקטע Trace, בוחרים את בקשת ה-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>

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

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

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

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

    • יש לבדוק אם מקבלים את אותו 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 ל-API שנכשלו. כלומר, אם שרת היעד/נקודת הקצה (endpoint) של היעד מפעיל שרת proxy אחר Apigee Edge. כדי לקבוע את זה:

    1. אם יש לכם את נתוני המעקב של הבקשה שנכשלה, עוברים אל הבקשה נשלחה אל שלב שרת היעד ולוחצים על Show Curl.

    2. החלון Curl עבור הבקשה שנשלחה לשרת היעד נפתח שממנו הוא יכול לקבוע את הכינוי של מארח שרת היעד.
    3. בודקים את נקודת הקצה (endpoint) של היעד של ה-API ל-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 Monitoring, ביומני הגישה ל-NGINX או יומני מעבד ההודעות מטעמי אבטחה.
  3. כדי לקבל עוד תוצאות, אפשר לבדוק את היומנים של השרת העורפי או להפעיל את מצב ניפוי הבאגים בקצה העורפי פרטים על 500 Internal Server Error ו/או להציג את הודעת השגיאה שהוחזרה על ידי שרת הקצה העורפי.

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

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

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

  • שם הארגון
  • שם הסביבה
  • שם ה-API של ה-Proxy
  • צריך להשלים את הפקודה 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 השגיאות.