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 Internal Server Error (שגיאת שרת פנימית) יכולה להתרחש בגלל מספר סיבות שונות. המדריך הזה מתמקד בשגיאת שרת פנימית 500 שנגרמת בגלל גישה למטען הייעודי (payload) של הבקשה או התגובה כשהזרמה מופעלת.

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

אבחון

תהליך מספר 1: שימוש בכלי 'מעקב'

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

   

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

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

   תהליך: בקשה משרת proxy

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

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

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

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

   בתרחיש לדוגמה, מטען הבקשה מנותח, לכן צריך לבדוק את השלב Request Received from Client במעקב ולבדוק את Request Content.

   

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

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

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

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 Proxy ומבטלת את המטרה של שימוש בסטרימינג ב-Apigee Edge.

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

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

       

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

       

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

רזולוציה

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

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

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

   או

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

הערה:

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

אבחון בעיות באמצעות 'מעקב אחר API'

אם אתם משתמשים ב-Private Cloud, אתם יכולים לדלג על התהליך הזה.

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

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

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

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

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

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

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

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

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