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

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

סרטונים

בסרטונים הבאים מוסבר איך לפתור 500 שגיאות שרת פנימיות.

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

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP 500 עם ההודעה "Internal Server Error" (שגיאה פנימית בשרת) כתגובה לקריאות ל-API. השגיאה ' 500 Internal Server' יכולה לנבוע משגיאה במהלך ביצוע של מדיניות כלשהי ב-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 יכולה להקפיץ מספר סיבות שונות. ב-Edge, ניתן לסווג את הסיבות לשתי קטגוריות עיקריות, על סמך המקום שבו אירעה השגיאה:

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

שגיאת ביצוע במדיניות Edge

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

אבחון

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

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

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

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

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

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

רזולוציה

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

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

אם אתם צריכים עזרה נוספת בפתרון שגיאת שרת פנימית 500 או שאתם חושדים שזו בעיה ב-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 'שגיאת שרת פנימית' נגרמת עקב שגיאה במדיניות לחילוץ משתני, נראה איך לפתור את הבעיה ולפתור אותה.

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. שימו לב למזהה ההודעה הייחודי "X-Apigee.Message-ID" לבקשת ה-API הספציפית הזו מהמעקב, באופן הבא:
   1. בוחרים את השלב 'נתוני 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 בשרת הקצה העורפי של מעבדי ההודעות. פקודת 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: כשל במדיניות Java של יתרונות מרכזיים

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

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

   

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

   

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

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

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

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

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

אבחון

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

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

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

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

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

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

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

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

   

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

   

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

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

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

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

   

פתרון

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

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

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

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

שימוש ב-Trace בממשק המשתמש

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

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

שימוש ב-API Monitoring

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

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

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

שימוש ביומני גישה של NGINX

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

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

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

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

   

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

   

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