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

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

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

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

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

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

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 सर्वर की गड़बड़ी पर फ़ोकस करता है स्ट्रीमिंग के दौरान पेलोड चालू है.

Cause	जानकारी	समस्या हल करने के तरीके कौन पूरा कर सकता है
इससे पेलोड को ऐक्सेस किया जा सकता है स्ट्रीमिंग की सुविधा चालू है	स्ट्रीमिंग चालू होने पर अनुरोध/रिस्पॉन्स पेलोड ऐक्सेस किए जाने की वजह से कोई गड़बड़ी हुई.	Edge के निजी और सार्वजनिक क्लाउड उपयोगकर्ता

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

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

प्रक्रिया #1: ट्रेस का इस्तेमाल करना

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

   

   जैसा कि ऊपर दिखाया गया है, ट्रेस आउटपुट में दी गई जानकारी को नोट कर लें स्क्रीनशॉट:
   

   फ़ेल होने से जुड़ी नीति: JSONJSONProtection

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

6. काम न करने वाली नीति की परिभाषा की जांच करें और पार्स किए जा रहे पेलोड की जांच करें.

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

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

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

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

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

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

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

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

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

   

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

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

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

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

    उदाहरण के तौर पर, काम न करने वाली नीति को प्रॉक्सी अनुरोध के फ़्लो में लागू किया गया था (जैसा कि ऊपर चरण #5 में तय किया गया है); इसलिए, प्रॉक्सी एंडपॉइंट की जांच करें:

    <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" 'सही' पर सेट है.

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

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

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

       

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

       

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

रिज़ॉल्यूशन

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

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

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

   या

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

ध्यान दें:

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

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

अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो इस प्रोसेस को छोड़ दें.

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

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

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

गड़बड़ी की जानकारी ज़रूर इकट्ठा करें

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

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

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

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

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