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

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

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד הסטטוס 500 של תשובת HTTP עם את ההודעה שגיאת שרת פנימית לגבי קריאות ל-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) באמצעות הסטרימינג מופעל	אירעה שגיאה כי מתבצעת גישה למטען הייעודי (payload) של הבקשה/תגובה כשמופעל סטרימינג.	משתמשי Edge בענן פרטי וציבורי

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

אבחון

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

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

   

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

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

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

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

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

   

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

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

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

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

    בתרחיש לדוגמה, המדיניות שנכשלה בוצעה בתהליך הבקשה של שרת ה-proxy (כפי שנקבע בשלב 5 למעלה); לכן, יש לבדוק את נקודת הקצה (endpoint) של שרת ה-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 ב-proxy ל-API שניגש למטען הייעודי (payload) של הבקשה כשמופעל סטרימינג. היא גורמת לשגיאות כי מפעיל אגירת נתונים בשרת ה-proxy ל-API ומבטל את מטרת השימוש בסטרימינג ב-Apigee Edge.

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

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

1. אם רוצים לעבד את המטען הייעודי (payload), צריך להשבית את הסטרימינג בשרת ה-proxy או היעד. נקודת קצה (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, אל תשתמשו בכללי מדיניות שרת proxy ל-API שניגשים למטען הייעודי (payload) של הבקשה/תגובה.

הערה:

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

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

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

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

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

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

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

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

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

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

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

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