500 שגיאת שרת פנימית

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

סרטונים

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

וידאו תיאור
מבוא מבוא ל-500 שגיאות שרת פנימיות וסיבות אפשריות לכך. מדגים גם שגיאת שרת פנימית 500 בזמן אמת, יחד עם שלבים לפתרון השגיאה.
טיפול בשגיאות בהסבר על השירות וחילוץ משתנים הדגמת שתי 500 שגיאות פנימיות בחיבור לשרת שנגרמו על-ידי מדיניות Service Callout וחילוץ משתנה ומראה איך לפתור את השגיאות האלה.
טיפול בשגיאות שקשורות למדיניות בנושא JavaScript מוצגת שגיאת שרת פנימית 500 שנגרמה על ידי מדיניות JavaScript והשלבים כדי לפתור את השגיאה.
טיפול בכשלים משרתי קצה עורפי דוגמה ל-500 שגיאות שרת פנימיות שנגרמו על ידי כשל בשרת העורפי, ושלבים כדי לפתור את השגיאות.

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 500 עם ההודעה "שגיאת שרת פנימית" כתגובה לקריאות ל-API. שרת 500 הפנימי שגיאה יכולה להיגרם משגיאה במהלך ביצוע מדיניות כלשהי ב-Edge או משגיאה בשרת היעד/בשרת הקצה העורפי.

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

הודעות שגיאה

יכול להיות שתתקבל הודעת השגיאה הבאה:

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

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

השגיאה 500 Internal Server Error עשויה להידרש בגלל מספר סיבות. ב-Edge, אפשר לסווג את הסיבות לשתי קטגוריות עיקריות, בהתאם למקום שבו אירעה השגיאה:

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

שגיאת הפעלה במדיניות Edge

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

אבחון

שלבי האבחון למשתמשים בענן הפרטי ובענן הציבורי

אם יש את הסשן של ממשק המשתמש למעקב עבור השגיאה:

  1. מוודאים שהשגיאה נגרמה על ידי הפעלת מדיניות. פרטים נוספים זמינים בדף זיהוי המקור של הבעיה.
  2. אם השגיאה אירעה במהלך הפעלת המדיניות, אפשר להמשיך. אם השגיאה נגרמה על ידי יש לעבור אל שגיאה בשרת העורפי.
  3. בוחרים את בקשת ה-API שנכשלה עם השגיאה 500 Internal Server Error במעקב.
  4. לבדוק את הבקשה ולבחור את המדיניות הספציפית שנכשלה או את התהליך שנקרא "שגיאה" שמיד אחריה בהתאם למדיניות שנכשלה במעקב.
  5. כדי לקבל פרטים נוספים על השגיאה, אפשר לסמן את התיבה 'שגיאה' בשדה 'מאפיינים' או בקטע 'תוכן השגיאה'.
  6. נסו לקבוע את הסיבה לשגיאה באמצעות הפרטים שאספתם.

שלבי אבחון למשתמשים בענן פרטי בלבד

אם אין לכם את הסשן של ממשק המשתמש של המעקב:

  1. מוודאים שהשגיאה התרחשה במהלך הפעלת המדיניות. פרטים נוספים זמינים בדף זיהוי המקור של הבעיה.
  2. אם השגיאה נגרמה בגלל הפעלת המדיניות, ממשיכים. אם השגיאה אירעה במהלך ביצוע המדיניות ביצוע, המשך. אם השגיאה נגרמה על ידי שרת הקצה העורפי, צריך לעבור אל שגיאה בשרת הקצה העורפי.
  3. משתמשים ביומני הגישה ל-NGINX כמו שמוסבר במאמר קביעת מקור הבעיה כדי לקבוע מהי המדיניות שנכשלה בשרת ה-proxy של ה-API וגם מזהה ייחודי של הודעת הבקשה
  4. בדיקת היומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log) ומחפשים את המזהה הייחודי של הודעת הבקשה.
  5. אם מוצאים את המזהה הייחודי של הודעת הבקשה, אפשר לקבל מידע נוסף על את הסיבה לכשל.

רזולוציה

אם גיליתם את הגורם לבעיה במדיניות, נסו לפתור אותה על ידי תיקון המדיניות ופריסה מחדש של שרת ה-proxy.

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

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

דוגמה 1: כשל במדיניות 'יתרונות מרכזיים בשירות' עקב שגיאה בקצה העורפי שרת

אם הקריאה לשרת הקצה העורפי תיכשל בהתאם למדיניות 'יתרונות מרכזיים של שירות' ותופיע שגיאה כלשהי, 4XX או 5XX, המערכת תתייחס אליה בתור 'שגיאת שרת פנימית' 500.

  1. דוגמה למקרה שבו שירות הקצה העורפי נכשל עם שגיאת 404 בתוך השירות מדיניות בנושא יתרונות מרכזיים. הודעת השגיאה הבאה נשלחת למשתמש הקצה: 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. בסשן הבא של ממשק המשתמש למעקב מוצג קוד סטטוס של 500 שנגרם בגלל שגיאה בשירות. מדיניות בנושא יתרונות מרכזיים:

  3. בדוגמה הזאת, המילה 'error' פירוט של הסיבה למדיניות בנושא יתרונות מרכזיים של שירות כישלון בתור "ResponseCode 404 נחשב כשגיאה". השגיאה הזו עשויה להתרחש אם אין גישה למשאב דרך כתובת ה-URL של שרת הקצה העורפי במדיניות 'הסבר על שירות' זמינים.
  4. לבדוק את הזמינות של המשאב בשרת העורפי. יכול להיות שהיא לא זמינה באופן זמני/קבוע, או שייתכן שהוא הועבר למיקום אחר.

פתרון לדוגמה 1

  1. לבדוק את הזמינות של המשאב בשרת העורפי. יכול להיות שהיא לא זמינה באופן זמני/קבוע, או שייתכן שהוא הועבר למיקום אחר.
  2. צריך לתקן את כתובת ה-URL של שרת הקצה העורפי במדיניות בנושא יתרונות מרכזיים לשירות כדי להפנות לכתובת תקינה וקיימת משאב.
  3. אם המשאב לא זמין רק באופן זמני, נסו לשלוח את בקשת ה-API אחרי זמין.

דוגמה 2: כשל במדיניות בנושא חילוץ משתנים

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

  1. במעקב הבא בסשן של ממשק המשתמש מוצג קוד סטטוס 500 בגלל שגיאה בחילוץ מדיניות בנושא משתנים:

  2. בוחרים את מדיניות חילוץ משתני החילוץ שנכשלו, גוללים למטה ומעיינים ב"שגיאה" בקטע 'תוכן' לפרטים נוספים:

  3. תוכן השגיאה מציין המשתנה "serviceCallout.oamCookieValidationResponse" לא זמין במדינות הבאות את המדיניות חילוץ משתנים. כפי שמציין שם המשתנה, הוא צריך להכיל את בהתאם למדיניות הקודמת בנושא יתרונות מרכזיים של שירות.
  4. בחרו במדיניות 'יתרונות מרכזיים בשירות' במעקב, ואולי תגלו "serviceCallout.oamCookieValidationResponse" לא הוגדר משתנה. הזה מציין שהקריאה לשירות הקצה העורפי נכשלה, וכתוצאה מכך התקבלה תגובה ריקה מותאם אישית.
  5. למרות שהמדיניות בנושא יתרונות מרכזיים של שירות נכשלה, הפעלת המדיניות אחרי השירות המדיניות בנושא יתרונות מרכזיים ממשיכה כי "continueOnError" בסימון המדיניות בנושא יתרונות מרכזיים של שירות ל-true, כפי שמוצג בהמשך:

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. שימו לב למזהה ההודעה הייחודי &quot;X-Apigee.Message-ID&quot; עבור ה-API הספציפי הזה כבקשה מהמעקב, באופן הבא:
    1. בוחרים באפשרות 'Analytics Data Recorded' (תיעוד נתונים של Analytics) שלב מהבקשה.
    2. גוללים למטה ובודקים את הערך של X-Apigee.Message-ID.

  7. הצגת יומן מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/system.log) ולחפש את הערך מזהה ההודעה צוין בשלב 6. הודעת השגיאה הבאה זוהתה לגבי ה-API הספציפי בקשה: 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

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

  8. כדי לקבוע את הסיבה לשגיאה של הזמן הקצוב לחיבור, מריצים את פקודת telnet לשרת הקצה העורפי ממעבדי ההודעות. The telnet הפקודה נתנה את הכיתוב "תם פרק הזמן שהוקצב להתחברות" כפי שמוצג בהמשך: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    בדרך כלל השגיאה הזו מתרחשת בנסיבות הבאות:

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

    בדוגמה שלמעלה, למרות שהמדיניות 'חילוץ משתנים' נכשלה, בפועל הסיבה לכך הייתה ש-Edge לא הצליח להתחבר לשרת הקצה העורפי בבקשת השירות המדיניות בנושא והסיבה לכשל זה הייתה ששרת הקצה העורפי לא הוגדר מאפשרת תעבורת נתונים ממעבדי ההודעות של Edge.

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

רזולוציה לדוגמה 2

  1. צריך לתקן בהתאם את הסיבה לשגיאה או לכשל במדיניות 'חילוץ משתנים'.
  2. בדוגמה שלמעלה הפתרון היה לתקן את תצורת הרשת כך תאפשר את תעבורת הנתונים ממעבדי ההודעות של Edge לשרת העורפי שלכם. הפעולה בוצעה על ידי להוסיף את מעבדי ההודעות לרשימת ההיתרים כתובות IP בשרת העורפי הספציפי. לדוגמה, ב-Linux, ניתן להשתמש ב-iptables כדי לאפשר תעבורת נתונים כתובות ה-IP של מעבד ההודעות בשרת הקצה העורפי.

דוגמה 3: כשל במדיניות JavaCallout

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

  1. במעקב הבא של ממשק המשתמש מוצג קוד סטטוס 500 בגלל שגיאה במדיניות ההסבר על Java:

  2. בוחרים את התהליך שנקרא "שגיאה" ולאחר מכן את המדיניות בנושא יתרונות מרכזיים ב-Java שנכשלו לקבל את פרטי השגיאה, כפי שאפשר לראות באיור הבא:

  3. בדוגמה זו, המאפיין "error" בקטע 'מאפיינים' חושף שהכשל נגרם עקב שימוש בסיסמה שפג תוקפה במהלך ההתחברות למסד הנתונים של Oracle מתוך מדיניות JavaCallout. אופן הפעולה של תוסף היתרונות המרכזיים שלכם ב-Java יהיה שונה לאכלס הודעה אחרת במאפיין error.
  4. בודקים את קוד המדיניות של JavaCallout ומאשרים את ההגדרה הנכונה שצריך בשימוש.

רזולוציה של דוגמה 3

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

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

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

אבחון

שלבי האבחון לכל המשתמשים

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

  1. מוודאים שהשגיאה נגרמה על ידי שרת הקצה העורפי. פרטים נוספים זמינים בדף זיהוי המקור של הבעיה.
  2. אם השגיאה נגרמה על ידי שרת הקצה העורפי, ממשיכים. אם השגיאה אירעה במהלך הפעלת המדיניות, עוברים לקטע שגיאת הפעלה ב-Edge מדיניות.
  3. צריך לפעול לפי השלבים הבאים, אם יש לכם גישה לסשן מעקב או לא ממשק API שנכשלו, או אם הקצה העורפי הוא שרת Node.js:

אם אין לכם סשן Trace עבור הקריאה ל-API שנכשלה:

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

אם יש לכם סשן Trace עבור הקריאה ל-API שנכשלה:

אם יש לכם סשן Trace, השלבים הבאים יעזרו לכם לאבחן את הבעיה.

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

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

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

אם הקצה העורפי הוא שרת Node.js:

  1. אם הקצה העורפי הוא שרת קצה עורפי של Node.js, צריך לבדוק את יומני Node.js לשרת ה-Proxy ל-API הספציפי בממשק המשתמש של Edge (גם משתמשי ענן ציבורי וגם משתמשים בענן פרטי יכולים צריך לבדוק את היומנים של Node.js). אם אתם משתמשים ב-Edge Private Cloud, הוא יכול גם לבדוק את יומני מעבד ההודעות שלך (/opt/apigee/var/log/edge-message-processor/logs/system.log) לפרטים נוספים על השגיאה.

    האפשרות 'יומני NodeJS' בממשק המשתמש של Edge – הכרטיסייה 'סקירה כללית' של ה-API ל-API

רזולוציה

  1. אחרי שתזהו את הגורם לשגיאה, תקנו את הבעיה בשרת הקצה העורפי.
  2. אם מדובר בשרת עורפי של Node.js:
    1. בודקים אם השגיאה מופיעה מהקוד המותאם אישית ומתקנים את הבעיה, אם אפשר.
    2. אם השגיאה לא מופיעה מהקוד המותאם אישית או אם אתם צריכים עזרה, אפשר ליצור קשר תמיכה ב-Apigee.

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

זיהוי המקור של הבעיה

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

שימוש במעקב בממשק המשתמש

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

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

שימוש ב-API Monitoring

הערה: את השלבים בקטע הזה יכולים לבצע רק משתמשי Public Cloud.

בעזרת API Monitoring תוכלו לבודד במהירות אזורים בעייתיים כדי לאבחן בעיות של שגיאות, ביצועים וזמן אחזור ואת המקור שלהן, כגון אפליקציות למפתחים, שרתי proxy ל-API, יעדים לקצה העורפי או פלטפורמת ה-API.

תרחיש לדוגמה שמדגים איך לפתור בעיות מסוג 5xx באמצעות ממשקי API באמצעות API Monitoring. לדוגמה, אפשר להגדיר התראה שתקבלו כשמספר 500 קודי הסטטוס או השגיאות של steps.servicecallout.ExecutionFailed יחרוג מסף מסוים.

שימוש בגישת NGINX יומנים

הערה: השלבים בקטע הזה מיועדים למשתמשי Edge Private Cloud פרטי. בלבד.

אפשר גם לעיין ביומני NGINX Access כדי לבדוק אם קוד הסטטוס 500 נסרק. במהלך ביצוע מדיניות בשרת ה-proxy ל-API או על ידי שרת הקצה העורפי. הדבר שימושי במיוחד אם הבעיה התרחשה בעבר או אם היא מתרחשת לסירוגין, אין אפשרות לתעד את המעקב בממשק המשתמש. כדי לקבוע את המידע הזה, צריך לפעול לפי השלבים הבאים: יומני גישה ל-NGINX:

  1. צריך לבדוק את יומני הגישה ל-NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
  2. מחפשים אם יש 500 שגיאות עבור שרת ה-proxy הספציפי ל-API משך הזמן.
  3. אם יש 500 שגיאות, צריך לבדוק אם השגיאה היא מדיניות או שגיאה בחיבור לשרת יעד. כפי שמוצג בהמשך:

    רשומה לדוגמה שמציגה שגיאה שקשורה למדיניות

    רשומה לדוגמה שמציגה שגיאה בשרת היעד

  4. אחרי שזיהיתם אם מדובר בשגיאת מדיניות או בשרת יעד:
    1. המשיכו אל שגיאת ביצוע במדיניות Edge אם מדובר בשגיאה שקשורה למדיניות.
    2. ממשיכים אל שגיאה בשרת הקצה העורפי אם זהו יעד שגיאה בחיבור לשרת.