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

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

סרטונים

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

וידאו תיאור
מבוא הסבר על שגיאות מסוג 500 Internal Server Error ועל הסיבות האפשריות לשגיאות האלה. בנוסף, הוא מדגים שגיאת שרת פנימית 500 בזמן אמת, ומספק שלבים לפתרון הבעיה.
טיפול בשגיאות של רכיבי Service Callout ו-Extract Variable המאמר כולל דוגמה לשתי שגיאות מסוג 500 Internal Server Error (שגיאת שרת פנימית) שנגרמות על ידי כללי מדיניות מסוג Service Callout ו-Extract Variable, ומסביר איך לפתור את השגיאות האלה.
טיפול בשגיאות מדיניות של JavaScript מוצגת שגיאת שרת פנימית 500 שנגרמת בגלל מדיניות JavaScript, ומוסבר איך לפתור את השגיאה.
טיפול בכשלים משרתים עורפיים מוצגות דוגמאות לשגיאות 500 Internal Server Errors שנגרמות בגלל כשל בשרת העורפי, ומוצגים שלבים לפתרון השגיאות.

תיאור הבעיה

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

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

הודעות שגיאה

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

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 Private Cloud וב-Edge Public Cloud
שגיאה בשרת העורפי יכול להיות שהשרת העורפי ייכשל מסיבה כלשהי. משתמשים ב-Edge Private Cloud וב-Edge Public Cloud

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

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

אבחון

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

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

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

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

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

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

רזולוציה

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

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

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

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

אם הקריאה לשרת העורפי נכשלת במסגרת מדיניות Service Callout עם שגיאה כלשהי, כמו 4XX או 5XX, היא תטופל כשגיאת שרת פנימית 500.

  1. הנה דוגמה שבה שירות ה-Backend נכשל עם שגיאה 404 במדיניות Service Callout. הודעת השגיאה הבאה נשלחת למשתמש הקצה: 
    {
"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 שנגרם בגלל שגיאה במדיניות של Service Callout:

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

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

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

דוגמה 2: כשל במדיניות Extract Variables

עכשיו נסתכל על דוגמה נוספת, שבה שגיאת שרת פנימית 500 נגרמת בגלל שגיאה במדיניות Extract Variables. נראה איך לפתור את הבעיה.

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

  2. בוחרים במדיניות Extract Variables (חילוץ משתנים) שנכשלה, גוללים למטה ומעיינים בקטע Error Content (תוכן השגיאה) כדי לקבל פרטים נוספים:

  3. התוכן של השגיאה מציין שהמשתנה serviceCallout.oamCookieValidationResponse לא זמין במדיניות Extract Variables. כפי שאפשר להבין משם המשתנה, הוא אמור להכיל את התגובה של מדיניות Service Callout הקודמת.
  4. בוחרים במדיניות Service Callout (קריאה לשירות) ב-trace, ואולי תגלו שהמשתנה serviceCallout.oamCookieValidationResponse לא הוגדר. השגיאה הזו מציינת שהקריאה לשירות לקצה העורפי נכשלה, ולכן משתנה התגובה ריק.
  5. למרות שהמדיניות בנושא Service Callout נכשלה, הביצוע של המדיניות אחרי Service Callout נמשך כי הדגל continueOnError במדיניות Service Callout מוגדר כ-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

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

  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.
    • אם השרת העורפי לא מאזין ביציאה הספציפית.

    בדוגמה שלמעלה, למרות שהמדיניות Extract Variables נכשלה, הסיבה האמיתית לכך היא ש-Edge לא הצליח להתחבר לשרת העורפי במדיניות Service Callout. הסיבה לכשל הזה הייתה שהשרת העורפי לא הוגדר לאפשר תנועה ממעבדי ההודעות של Edge.

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

דוגמה 2: פתרון

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

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

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

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

  2. בוחרים את הרכיב Flow בשם Error ואחריו את הרכיב Java Callout Policy שנכשל כדי לקבל את פרטי השגיאה כמו שמוצג באיור הבא:

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

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

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

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

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

אבחון

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

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

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

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

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

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

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

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

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

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

אם ה-backend הוא שרת Node.js:

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

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

פתרון

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

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

איך מזהים את מקור הבעיה

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

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

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

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

שימוש ב-API Monitoring

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

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

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

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

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

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