500 שגיאת שרת פנימית - הסטרימינג מופעל

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

תיאור הבעיה

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

הודעות שגיאה

אפליקציות הלקוח עשויות לקבל הודעת שגיאה, כפי שמפורט בהמשך:

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

גורמים אפשריים

'שגיאת שרת פנימית 500' יכולה להתרחש עקב מספר סיבות שונות. המדריך הזה מתמקד בשגיאה 500 של שגיאת שרת פנימית שנגרמה עקב גישה למטען הייעודי (payload) של הבקשה/התגובה בזמן הפעלת הסטרימינג.

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

הסיבה: גישה למטען ייעודי (payload) כשהסטרימינג פועל

אבחון

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

1. מפעילים את סשן המעקב ומבצעים את הקריאה ל-API כדי לשחזר את הבעיה – '500 שגיאת שרת פנימית'.
2. בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
3. אפשר לנווט בשלבים השונים של המעקב ולאתר את המיקום שבו אירעה הכשל.
4. יכול להיות שהשגיאה קרתה בזמן שמדיניות מנתחת את המטען הייעודי (payload) של הבקשה/התגובה.
5. לפניכם צילום מסך של נתוני מעקב לדוגמה שבו מוצגת המדיניות בנושא JSONThreatProtection JSONThreatProtection כשמוצגת השגיאה JSONThreatProtection :

   

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

   מדיניות נכשלת: JSONThreatProtection

   זרימה: בקשת שרת Proxy

6. יש לבדוק את הגדרת המדיניות הכושלת ולבדוק את המטען הייעודי (payload) שמנותח.

   בתרחיש לדוגמה, צריך לבדוק את המדיניות JSONThreatProtection בשם JSON-Threat-Protection שנכשלו ולבדוק את הרכיב <Source>.

   <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
      <DisplayName>JSON Threat Protection</DisplayName>
      <ArrayElementCount>20</ArrayElementCount>
      <ContainerDepth>10</ContainerDepth>
      <ObjectEntryCount>15</ObjectEntryCount>
      <ObjectEntryNameLength>50</ObjectEntryNameLength>
      <Source>request</Source>
      <StringValueLength>1000</StringValueLength>
   </JSONThreatProtection>
   

   שימו לב שהרכיב <Source> מפנה אל request., והמשמעות היא שהשגיאה אירעה במהלך ניתוח המטען הייעודי (payload) של הבקשה.

7. כדי לקבוע את סוג המטען הייעודי שמנותח, בודקים את בקשת ה-API.

אפשר לבדוק את התוכן של המטען הייעודי (payload) של הבקשה ואת הכותרת Content-Type בבקשת ה-API. בפקודת ה-Curl הבאה לדוגמה נעשה שימוש במטען ייעודי (payload) של JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

אפשר גם לבדוק את המדיניות שנכשלו ולקבוע את סוג המטען הייעודי (payload) שמנותח. בתרחיש לדוגמה שלמעלה, המדיניות JSON-Threat-Protection נכשלה. ההערה הזו מציינת שהמטען הייעודי (payload) חייב להיות בפורמט JSON.

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

9. אם המטען הייעודי תקין אבל עדיין מופיעות שגיאות שמפורטות בקטע הודעות שגיאה, הסיבה לשגיאות האלה היא שמתבצעת גישה למטען הייעודי (payload) בזמן שהשידור פועל.

   בהתאם למטען הייעודי (payload) שמנותח על ידי המדיניות (כפי שנקבע בשלב 6), יש לבדוק את התוכן של המטען הייעודי בכלי המעקב בשלב המתאים.

   בתרחיש לדוגמה, המטען הייעודי (payload) של הבקשה מנותח. לכן, צריך לבדוק את השלב 'בקשה שהתקבלה מהלקוח' במעקב ולבדוק את בקשת תוכן.

   

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

   הסיבה לכך היא שכאשר מפעילים סטרימינג, המטען הייעודי (payload) של הבקשה לא יופיע במעקב.

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

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

    בתרחיש לדוגמה, המדיניות שנכשלה בוצעה בתהליך הבקשה לשרת ה-proxy (כפי שנקבע בשלב 5 למעלה). לכן, יש לבדוק את נקודת הקצה של שרת ה-proxy:

    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
        <Properties>
          <Property name="response.streaming.enabled">true</Property>
          <Property name="request.streaming.enabled">true</Property>
        </Properties>
      </HTTPProxyConnection>
    </ProxyEndpoint>
    

    כפי שאפשר לראות בדוגמה שלמעלה, האפשרות להזרמת בקשות הופעלה, כפי שמצוין על ידי המאפיין "request.streaming.enabled" שהוגדר כ-True.

    לכן, הגורם לשגיאה הוא שימוש במדיניות JSONThreatProtection ב-API Proxy שניגש למטען הייעודי (payload) של הבקשה כשמופעלת סטרימינג. המצב הזה גורם לשגיאות כי הוא מפעיל תהליך אגירת נתונים בשרת ה-API של ה-API ומבטל את מטרת השימוש בסטרימינג ב-Apigee Edge.

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

11. כדי לוודא שהשגיאה 500 נגרמת בגלל המדיניות, אפשר לבדוק את הערך של "X-Apigee-fault-source" בשלב "AX" (נתוני Analytics מתועדים) בשלב המעקב, באמצעות השלבים הבאים:
    1. צריך ללחוץ על השלב 'AX' ('רישום נתונים ב-Analytics') כפי שמוצג בצילום המסך הבא:

       

    2. גוללים למטה בקטע 'פרטי השלב' לקטע "כותרות שגיאה" ו קובעים את הערכים של "X-Apigee-fault-code", "X-Apigee-fault-source" ו-"X-Apigee-fault-policy", כפי שמוצג בהמשך:

       

    3. אם הערך של "X-Apigee-fault-source" הוא "policy", כפי שמוצג בתמונה שלמעלה, השגיאה נגרמת עקב מדיניות גישה למטען הייעודי (payload) כשסטרימינג מופעל.

רזולוציה

גישה למטען ייעודי (payload) כשמפעילים סטרימינג היא דפוס נגד, כפי שמוסבר במאמר Antipattern: גישה למטען הייעודי (payload) של הבקשה/התגובה בזמן שהסטרימינג מופעל.

1. כדי לעבד את המטען הייעודי (payload), צריך להשבית את הסטרימינג ב-Proxy/Target Endpoint על ידי הסרת המאפיינים "request.streaming.enabled" and "response.streaming.enabled" כפי שמוצג בדוגמה הבאה של ProxyEndpoint:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>
   

   או

2. אם רוצים להשתמש בסטרימינג בממשקי ה-API של שרת ה-API, אין להשתמש בכללי מדיניות בשרת ה-API של ה-API שיש להם גישה למטען הייעודי(payload) של הבקשה/התגובה.

הערה:

• במדריך הזה, נעשה שימוש במדיניות JSONThreatProtection לצורך עיבוד של המטען הייעודי (payload) של הבקשה, תוך הפעלת סטרימינג בתרחיש לדוגמה. התוצאה הייתה 500 שגיאת שרת פנימית עם שגיאות שונות.
• ניתן לראות את השגיאות האלה גם בכללי מדיניות כמו JSONToXML ו-XMLToJSON, שמעבדים מטענים ייעודיים של בקשות או תגובות כאשר הסטרימינג מופעל.
• מומלץ מאוד לא להשתמש בכללי מדיניות כאלה בשרתי proxy שדורשים גישה למטענים ייעודיים (payloads) כשמופעלת סטרימינג.
• פעולה כזו מהווה נוגדי תבנית, כפי שמתואר במאמר Antipattern: גישה למטען הייעודי (payload) של הבקשה/התגובה בזמן שהסטרימינג מופעל.

אבחון בעיות באמצעות API Monitoring

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

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

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

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

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

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

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

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

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

• זוהתה הודעת שגיאה מלאה בבקשות שנכשלו
• הארגון, שם הסביבה ושם ה-API של ה-API שיש לגביהם 500 שגיאות.
• חבילת שרת proxy ל-API
• המטען הייעודי (payload) שנעשה בו שימוש בבקשה (אם יש)
• קובץ מעקב שמכיל את הבקשות עם שגיאת שרת פנימית 500
• יומני הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
• יומנים של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log)
• תקופת הזמן עם פרטי אזור הזמן שבו התרחשו 500 השגיאות.