500 सर्वर में गड़बड़ी - स्ट्रीमिंग चालू की गई

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

समस्या का ब्यौरा

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के लिए, एचटीटीपी रिस्पॉन्स स्टेटस कोड 500 मिलता है. साथ ही, उसे Internal Server Error मैसेज मिलता है.

गड़बड़ी के मैसेज

क्लाइंट ऐप्लिकेशन को, यहां दिखाए गए तरीके से गड़बड़ी का जवाब मिल सकता है:

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 इंटरनल सर्वर की गड़बड़ी पर फ़ोकस करती है. यह गड़बड़ी, स्ट्रीमिंग की सुविधा चालू होने पर अनुरोध/जवाब के पेलोड को ऐक्सेस करने की वजह से होती है.

वजह: स्ट्रीमिंग की सुविधा चालू होने पर पेलोड ऐक्सेस करना

संक्रमण की जांच

पहली प्रोसेस: ट्रेस का इस्तेमाल करना

1. ट्रेस सेशन चालू करें और समस्या को फिर से दिखाने के लिए, एपीआई कॉल करें. इससे, सर्वर में गड़बड़ी (500) की समस्या दिखेगी.
2. पूरे न हो पाने वाले किसी अनुरोध को चुनें और उसके ट्रेस की जांच करें.
3. ट्रेस के अलग-अलग फ़ेज़ में नेविगेट करें और पता लगाएं कि गड़बड़ी कहां हुई.
4. यह गड़बड़ी तब हो सकती है, जब कोई नीति अनुरोध/जवाब के पेलोड को पार्स कर रही हो.
5. यहां ट्रेस का एक सैंपल स्क्रीनशॉट दिया गया है. इसमें JSONThreatProtection नीति के उल्लंघन की वजह से, "Expecting } at line 1" गड़बड़ी दिख रही है:

   

   ऊपर दिए गए स्क्रीनशॉट में दिखाए गए Trace Output से, यहां दी गई जानकारी नोट करें:
   

   उल्लंघन करने वाली नीति: JSONThreatProtection

   फ़्लो: प्रॉक्सी अनुरोध

6. नीति के उल्लंघन की वजह जानने के लिए, नीति की परिभाषा देखें. साथ ही, पार्स किए जा रहे पेलोड की जांच करें.

   उदाहरण के तौर पर दिए गए इस परिदृश्य में, JSON-Threat-Protection नाम की JSONThreatProtection नीति की जांच करें. यह नीति लागू नहीं हो सकी है. साथ ही, <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. की ओर इशारा करता है. इसका मतलब है कि अनुरोध के पेलोड को पार्स करते समय गड़बड़ी हुई.

7. एपीआई अनुरोध की जांच करके, यह पता लगाएं कि किस तरह के पेलोड को पार्स किया जा रहा है.

एपीआई अनुरोध में, अनुरोध के पेलोड और Content-Type हेडर का कॉन्टेंट देखा जा सकता है. यहां कर्ल कमांड के उदाहरण में, JSON पेलोड का इस्तेमाल किया गया है.

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

यह भी देखा जा सकता है कि कौनसी नीति का उल्लंघन हुआ है. साथ ही, यह पता लगाया जा सकता है कि किस तरह के पेलोड को पार्स किया जा रहा है. ऊपर दिए गए उदाहरण में, JSON-Threat-Protection नीति लागू नहीं हो रही है. इससे पता चलता है कि पेलोड, JSON फ़ॉर्मैट में होना चाहिए.

8. पुष्टि करें कि पेलोड सही फ़ॉर्मैट में है. अगर पेलोड मान्य नहीं है, तो आपको यह गड़बड़ी दिख सकती है.

9. अगर पेलोड मान्य है, लेकिन आपको अब भी गड़बड़ी के मैसेज सेक्शन में दी गई गड़बड़ियां दिख रही हैं, तो इन गड़बड़ियों की वजह यह है कि स्ट्रीमिंग चालू होने पर पेलोड को ऐक्सेस किया जा रहा है.

   नीति के हिसाब से पार्स किए जा रहे पेलोड के आधार पर (जैसा कि छठे चरण में तय किया गया है), सही फ़ेज़ में Trace टूल में पेलोड के कॉन्टेंट की जांच करें.

   उदाहरण के तौर पर दिए गए इस मामले में, अनुरोध पेलोड को पार्स किया जा रहा है. इसलिए, ट्रेस में "क्लाइंट से मिला अनुरोध" फ़ेज़ की जांच करें और अनुरोध का कॉन्टेंट देखें.

   

   अगर ऊपर दिए गए स्क्रीनशॉट में दिखाए गए तरीके से, अनुरोध किए गए कॉन्टेंट को खाली पाया जाता है, तब भी जब आपने मान्य पेलोड भेजा है, तो इसका मतलब है कि इस समस्या की वजह यह हो सकती है कि अनुरोध की स्ट्रीमिंग चालू है.

   ऐसा इसलिए होता है, क्योंकि स्ट्रीमिंग चालू होने पर, अनुरोध पेलोड ट्रेस पर नहीं दिखेगा.

   इसी तरह, अगर गड़बड़ी होने पर रिस्पॉन्स पेलोड को पार्स किया जा रहा है, तो "टारगेट सर्वर से मिला रिस्पॉन्स" फ़ेज़ में रिस्पॉन्स कॉन्टेंट देखें.

10. इसके बाद, प्रॉक्सी और टारगेट एंडपॉइंट की परिभाषाओं की जांच करें. यह इस बात पर निर्भर करता है कि एपीआई प्रॉक्सी फ़्लो में, नीति का उल्लंघन कहां हुआ है. पुष्टि करें कि स्ट्रीमिंग की सुविधा चालू हो.

    उदाहरण के तौर पर दिए गए इस मामले में, नीति का उल्लंघन करने वाली कार्रवाई, प्रॉक्सी अनुरोध फ़्लो में की गई थी. इसकी जानकारी ऊपर दिए गए पांचवें चरण में दी गई है. इसलिए, प्रॉक्सी एंडपॉइंट की जांच करें:

    <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" प्रॉपर्टी को सही पर सेट किया गया है.

    इसलिए, गड़बड़ी की वजह यह है कि एपीआई प्रॉक्सी में JSONThreatProtection नीति का इस्तेमाल किया जा रहा है. यह नीति, स्ट्रीमिंग चालू होने पर अनुरोध पेलोड को ऐक्सेस करती है. इससे गड़बड़ियां होती हैं, क्योंकि यह एपीआई प्रॉक्सी में बफ़रिंग को ट्रिगर करता है. साथ ही, Apigee Edge में स्ट्रीमिंग का इस्तेमाल करने का मकसद पूरा नहीं होता.

    छोटे पेलोड में यह गड़बड़ी नहीं दिखती. हालांकि, बड़े पेलोड का इस्तेमाल करने पर, आपको ये गड़बड़ियां दिख सकती हैं.

11. नीचे दिए गए चरणों का इस्तेमाल करके, यह पुष्टि की जा सकती है कि नीति की वजह से 500 गड़बड़ी हुई है. इसके लिए, ट्रेस में "AX" (Analytics Data Recorded) फ़ेज़ में "X-Apigee-fault-source" की वैल्यू देखें:
    1. नीचे दिए गए स्क्रीनशॉट में दिखाए गए तरीके से, "AX" (Analytics Data Recorded) फ़ेज़ पर क्लिक करें:

       

    2. नीचे की ओर स्क्रोल करके, फ़ेज़ की जानकारी में मौजूद "गड़बड़ी के हेडर" सेक्शन पर जाएं. इसके बाद, यहां दी गई वैल्यू तय करें: "X-Apigee-fault-code", "X-Apigee-fault-source" और "X-Apigee-fault-policy"

       

    3. अगर ऊपर दी गई इमेज में दिखाए गए "X-Apigee-fault-source" की वैल्यू "policy" है, तो इसका मतलब है कि स्ट्रीमिंग चालू होने पर, नीति के पेलोड को ऐक्सेस करने की वजह से गड़बड़ी हुई है.

रिज़ॉल्यूशन

स्ट्रीमिंग की सुविधा चालू होने पर पेलोड को ऐक्सेस करना, एक एंटीपैटर्न है. इसके बारे में एंटीपैटर्न: स्ट्रीमिंग की सुविधा चालू होने पर अनुरोध/जवाब के पेलोड को ऐक्सेस करना में बताया गया है.

1. अगर आपको पेलोड को प्रोसेस करना है, तो प्रॉक्सी/टारगेट एंडपॉइंट में स्ट्रीमिंग की सुविधा बंद करनी होगी. इसके लिए, "request.streaming.enabled" and "response.streaming.enabled" प्रॉपर्टी हटाएं. यहां दिए गए उदाहरण में ProxyEndpoint में ऐसा करने का तरीका बताया गया है:

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

   या

2. अगर आपको अपनी एपीआई प्रॉक्सी के लिए स्ट्रीमिंग का इस्तेमाल करना है, तो एपीआई प्रॉक्सी में ऐसी किसी भी नीति का इस्तेमाल न करें जो अनुरोध/जवाब के पेलोड को ऐक्सेस करती हो.

ध्यान दें:

• इस प्लेबुक में, JSONThreatProtection नीति का इस्तेमाल अनुरोध के पेलोड को प्रोसेस करने के लिए किया गया था. उदाहरण के तौर पर दिए गए इस मामले में, स्ट्रीमिंग की सुविधा चालू थी. इस वजह से, सर्वर में गड़बड़ी (500) हुई और अलग-अलग गड़बड़ियां हुईं.
• ये गड़बड़ियां, JSONToXML और XMLToJSON जैसी नीतियों के साथ भी दिख सकती हैं. ये नीतियां, स्ट्रीमिंग चालू होने पर अनुरोध या जवाब के पेलोड को प्रोसेस करती हैं.
• हमारा सुझाव है कि स्ट्रीमिंग की सुविधा चालू होने पर, पेलोड को ऐक्सेस करने की ज़रूरत वाली प्रॉक्सी में ऐसी किसी भी नीति का इस्तेमाल न करें.
• ऐसा करना एक एंटीपैटर्न है. इसके बारे में एंटीपैटर्न: स्ट्रीमिंग की सुविधा चालू होने पर अनुरोध/जवाब के पेलोड को ऐक्सेस करना लेख में बताया गया है.

एपीआई मॉनिटरिंग का इस्तेमाल करके समस्याओं का पता लगाना

अगर आप Private Cloud का इस्तेमाल करते हैं, तो इस प्रक्रिया को छोड़ दें.

एपीआई मॉनिटरिंग की मदद से, गड़बड़ी, परफ़ॉर्मेंस, और लोड होने में लगने वाले समय से जुड़ी समस्याओं और उनके सोर्स का पता लगाया जा सकता है. जैसे, डेवलपर ऐप्लिकेशन, एपीआई प्रॉक्सी, बैकएंड टारगेट या एपीआई प्लैटफ़ॉर्म.

एक सैंपल परिदृश्य देखें, जिसमें एपीआई मॉनिटरिंग का इस्तेमाल करके, अपने एपीआई से जुड़ी 5xx समस्याओं को हल करने का तरीका बताया गया है. उदाहरण के लिए, आपको ऐसी सूचना सेट अप करनी हो सकती है जो 500 गड़बड़ियों की संख्या किसी तय थ्रेशोल्ड से ज़्यादा होने पर आपको सूचना दे.

अगर आपको नीति से 500 गड़बड़ी का रिस्पॉन्स मिलने पर सूचना चाहिए, तो आपको 500 स्टेटस कोड के लिए सूचना सेट अप करनी होगी. इसके लिए, गड़बड़ी का सोर्स के तौर पर प्रॉक्सी को सेट करना होगा.

गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है

अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया डाइग्नोस्टिक्स से जुड़ी यह जानकारी इकट्ठा करें. इनसे संपर्क करें और इन्हें Apigee की सहायता टीम के साथ शेयर करें.

अगर आप पब्लिक क्लाउड का इस्तेमाल करते हैं, तो यह जानकारी दें:

• संगठन का नाम
• एनवायरमेंट का नाम
• एपीआई प्रॉक्सी का नाम
• 500 गड़बड़ी को फिर से बनाने के लिए, अनुरोध पेलोड (अगर कोई हो) के साथ पूरी कर्ल कमांड
• ट्रेस फ़ाइल, जिसमें 500 इंटरनल सर्वर एरर वाले अनुरोध शामिल हैं
• अगर फ़िलहाल 500 गड़बड़ियां नहीं हो रही हैं, तो उस समयावधि की जानकारी दें, जब पहले 500 गड़बड़ियां हुई थीं. साथ ही, टाइमज़ोन की जानकारी भी दें.

अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:

• अनुरोध पूरे न होने पर, गड़बड़ी का पूरा मैसेज दिखता है
• उस संगठन, एनवायरमेंट के नाम, और एपीआई प्रॉक्सी का नाम जिसके लिए आपको 500 गड़बड़ियां दिख रही हैं
• एपीआई प्रॉक्सी बंडल
• अनुरोध में इस्तेमाल किया गया पेलोड (अगर कोई है)
• ट्रेस फ़ाइल, जिसमें 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 गड़बड़ियां हुई थीं.