502 गलत गेटवे - ToBigBody

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

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

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के जवाब के तौर पर, गड़बड़ी कोड protocol.http.TooBigBody के साथ 502 Bad Gateway एचटीटीपी स्टेटस कोड मिलता है.

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

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

HTTP/1.1 502 Bad Gateway

इसके अलावा, आपको गड़बड़ी का यह मैसेज भी दिख सकता है:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

संभावित कारण

यह गड़बड़ी तब होती है, जब टारगेट/बैकएंड सर्वर से Apigee Edge को भेजे गए पेलोड का साइज़, एचटीटीपी रिस्पॉन्स के तौर पर Apigee Edge में तय की गई सीमा से ज़्यादा हो.

इस गड़बड़ी की ये वजहें हो सकती हैं:

गड़बड़ी का पता लगाने के सामान्य चरण

इस गड़बड़ी का पता लगाने के लिए, इनमें से किसी टूल/तकनीक का इस्तेमाल करें:

वजह: जवाब के पेलोड का साइज़, तय सीमा से ज़्यादा है

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

1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके देखी गई गड़बड़ी के लिए, गड़बड़ी का कोड, गड़बड़ी का सोर्स, और जवाब के पेलोड का साइज़ तय करें. इसके बारे में, गड़बड़ी का पता लगाने के सामान्य तरीके में पहले उदाहरण के साथ बताया गया है.
2. अगर गड़बड़ी की वजह target है, तो इसका मतलब है कि टारगेट/बैकएंड सर्वर ने Apigee को जो रिस्पॉन्स पेलोड भेजा है उसका साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा है.
3. पहले चरण में तय किए गए जवाब के पेलोड साइज़ की पुष्टि करें.
   • अगर पेलोड का साइज़, तय की गई सीमा 10 एमबी से ज़्यादा है, तो यह गड़बड़ी की वजह है.
   • अगर पेलोड का साइज़, तय की गई सीमा (10 एमबी) के आस-पास है, तो हो सकता है कि रिस्पॉन्स पेलोड को कंप्रेस किए गए फ़ॉर्मैट में पास किया गया हो. वजह: डीकंप्रेशन के बाद, जवाब के पेलोड का साइज़ तय सीमा से ज़्यादा है पर जाएं.
4. पुष्टि करें कि जवाब के पेलोड का साइज़, अनुमति वाली 10 एमबी की सीमा से ज़्यादा है. इसके लिए, यहां दिया गया तरीका अपनाकर जवाब की जांच करें:
   1. अगर आपके पास टारगेट/बैकएंड सर्वर को किए गए असली अनुरोध का ऐक्सेस नहीं है, तो समस्या हल करना पर जाएं.
   2. अगर आपके पास टारगेट/बैकएंड सर्वर को किए गए असली अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:
      1. अगर आप पब्लिक क्लाउड/प्राइवेट क्लाउड के उपयोगकर्ता हैं, तो सीधे बैकएंड सर्वर से अनुरोध करें. इसके लिए, बैकएंड सर्वर या किसी ऐसी मशीन का इस्तेमाल करें जिससे आपको बैकएंड सर्वर से अनुरोध करने की अनुमति मिली हो.
      2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो मैसेज प्रोसेसर में से किसी एक से बैकएंड सर्वर को अनुरोध भी भेजा जा सकता है.
      3. Content-Length हेडर की जांच करके, यह पुष्टि करें कि जवाब में पास किए गए पेलोड का साइज़ सही है.
      4. अगर आपको लगता है कि पेलोड का साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा है, तो यह समस्या की वजह हो सकती है.

   बैकएंड सर्वर से मिले जवाब का उदाहरण:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   ऊपर दिए गए उदाहरण में, आपको दिख सकता है कि Content-Length: 11534336 (which is ~11 MB) इस गड़बड़ी की वजह है, क्योंकि यह Apigee Edge में तय की गई सीमा से ज़्यादा है.

रिज़ॉल्यूशन

रिज़ॉल्यूशन देखें.

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

अगर रिस्पॉन्स पेलोड को कंप्रेस किए गए फ़ॉर्मैट में भेजा जाता है और रिस्पॉन्स हेडर Content-Encoding को gzip, पर सेट किया जाता है, तो Apigee रिस्पॉन्स पेलोड को डीकंप्रेस करता है. डीकंप्रेशन प्रोसेस के दौरान, अगर Apigee को पेलोड का साइज़ Apigee Edge में तय की गई सीमा से ज़्यादा मिलता है, तो वह डीकंप्रेशन की प्रोसेस को रोक देता है.साथ ही, 502 Bad Gateway और गड़बड़ी कोड protocol.http.TooBigBody के साथ तुरंत जवाब देता है.

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

1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके देखी गई गड़बड़ी के लिए, गड़बड़ी का कोड, गड़बड़ी का सोर्स और जवाब के पेलोड का साइज़ तय करें. इसके बारे में, गड़बड़ी का पता लगाने के सामान्य तरीके में बताया गया है. इसमें दूसरा उदाहरण देखें.
2. अगर Fault Source की वैल्यू target है, तो इसका मतलब है कि टारगेट/बैकएंड ऐप्लिकेशन ने Apigee को जो रिस्पॉन्स पेलोड भेजा है उसका साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा है.
3. पहले चरण में तय किए गए जवाब के पेलोड साइज़ की पुष्टि करें.
   • अगर पेलोड का साइज़, तय की गई सीमा (10 एमबी) से ज़्यादा है, तो यह गड़बड़ी की वजह है.
   • अगर पेलोड का साइज़, तय की गई सीमा (करीब 10 एमबी) से ज़्यादा है, तो हो सकता है कि रिस्पॉन्स पेलोड को कंप्रेस किए गए फ़ॉर्मैट में पास किया गया हो. ऐसे मामले में, कंप्रेस किए गए रिस्पॉन्स पेलोड के अनकंप्रेस किए गए साइज़ की जांच करें.
4. इनमें से किसी एक तरीके का इस्तेमाल करके, यह पुष्टि की जा सकती है कि टारगेट/बैकएंड से जवाब कंप्रेस किए गए फ़ॉर्मैट में भेजा गया था और कंप्रेस न किए गए जवाब का साइज़, तय सीमा से ज़्यादा था:

   ट्रेस

   ट्रेस टूल का इस्तेमाल करना:

   1. अगर आपने अनुरोध पूरा न होने की वजह का पता लगाने के लिए ट्रेस कैप्चर किया है, तो ट्रेस और
      में दिए गए चरणों को देखें
      1. target.received.content.length की वैल्यू तय करना
      2. पुष्टि करें कि क्लाइंट के अनुरोध में Content-Encoding: gzip हेडर शामिल है या नहीं
   2. अगर target.received.content.length की वैल्यू, अनुमति वाली 10 एमबी की सीमा के आस-पास है और रिस्पॉन्स हेडर Content-Encoding: gzip, तो इस गड़बड़ी की वजह यही है.

   असल अनुरोध

   असल अनुरोध का इस्तेमाल करके:

   1. अगर आपके पास टारगेट/बैकएंड सर्वर को किए गए अनुरोध का ऐक्सेस नहीं है, तो समस्या हल करना पर जाएं.
   2. अगर आपके पास टारगेट/बैकएंड सर्वर को किए गए असली अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:
      1. जवाब में पास किए गए पेलोड के साइज़ की पुष्टि करें. साथ ही, जवाब में भेजे गए Content-Encoding हेडर की पुष्टि करें.
      2. अगर आपको लगता है कि रिस्पॉन्स हेडर Content-Encoding को gzip पर सेट किया गया है और पेलोड का कंप्रेस नहीं किया गया साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा है, तो इस गड़बड़ी की वजह यही है.

         बैकएंड सर्वर से मिला रिस्पॉन्स का सैंपल:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         ऊपर दिए गए उदाहरण में, हेडर Content-Encoding: gzip भेजा गया है और जवाब में फ़ाइल testzippedfile.gz का साइज़, तय सीमा से कम है. हालांकि, कंप्रेस नहीं की गई फ़ाइल testzippedfile का साइज़ ~15 एमबी था.

   मैसेज प्रोसेसर के लॉग

   Message Processor के लॉग का इस्तेमाल करना:

   1. अगर आप Private Cloud के उपयोगकर्ता हैं, तो एचटीटीपी 502 गड़बड़ियों के बारे में अहम जानकारी पाने के लिए, मैसेज प्रोसेसर के लॉग का इस्तेमाल किया जा सकता है.

   2. मैसेज प्रोसेसर के लॉग देखना

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. खोजें कि क्या किसी खास समयावधि के दौरान 502 गड़बड़ियां हुई हैं (अगर समस्या पहले हुई थी) या क्या अब भी 502 गड़बड़ियों की वजह से अनुरोध पूरे नहीं हो रहे हैं. इन सर्च स्ट्रिंग का इस्तेमाल किया जा सकता है:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. आपको system.log से इस तरह की लाइनें दिखेंगी, जैसा कि यहां दिखाया गया है (TotalRead और chunkCount आपके मामले में अलग-अलग हो सकते हैं):

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)

   5. डिकंप्रेशन की प्रोसेस के दौरान, जैसे ही मैसेज प्रोसेसर को पता चलता है कि पढ़े गए कुल बाइट 10 एमबी से ज़्यादा हैं, वह प्रोसेस को रोक देता है और यह लाइन प्रिंट करता है:

      Message is too large. TotalRead 10489856 chunkCount 2571

      इसका मतलब है कि जवाब के पेलोड का साइज़ 10 एमबी से ज़्यादा है. Apigee, साइज़ 10 एमबी की सीमा से ज़्यादा होने पर गड़बड़ी दिखाता है. गड़बड़ी का कोड protocol.http.TooBigBody होता है

रिज़ॉल्यूशन

सीमाएं

Apigee को उम्मीद है कि क्लाइंट ऐप्लिकेशन और बैकएंड सर्वर, पेलोड के साइज़ को तय सीमा से ज़्यादा नहीं भेजेंगे. यह सीमा, Apigee Edge की सीमाएं में Request/response size के लिए बताई गई है.

1. अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो अनुरोध और जवाब के पेलोड के साइज़ की ज़्यादा से ज़्यादा सीमा वही होगी जो Request/response size के लिए, Apigee Edge की सीमाएं में बताई गई है.
2. अगर आप Private Cloud का इस्तेमाल करते हैं, तो हो सकता है कि आपने अनुरोध और जवाब के पेलोड साइज़ की डिफ़ॉल्ट मैक्सिमम लिमिट में बदलाव किया हो. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता है. अनुरोध के पेलोड के साइज़ की ज़्यादा से ज़्यादा सीमा तय की जा सकती है. इसके लिए, मौजूदा सीमा की जांच कैसे करें में दिए गए निर्देशों का पालन करें.

मौजूदा सीमा कैसे देखें?

इस सेक्शन में बताया गया है कि यह पुष्टि कैसे करें कि मैसेज प्रोसेसर पर, प्रॉपर्टी HTTPResponse.body.buffer.limit को नई वैल्यू के साथ अपडेट किया गया है.

1. मैसेज प्रोसेसर मशीन पर, /opt/apigee/edge-message- processor/conf डायरेक्ट्री में HTTPResponse.body.buffer.limit प्रॉपर्टी खोजें. इसके बाद, देखें कि नीचे दिखाए गए तरीके से कौनसी वैल्यू सेट की गई है:

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. ऊपर दिए गए कमांड का सैंपल नतीजा यहां दिया गया है:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

3. ऊपर दिए गए उदाहरण में, ध्यान दें कि HTTPResponse.body.buffer.limit प्रॉपर्टी को http.properties में 10m वैल्यू के साथ सेट किया गया है.

   इससे पता चलता है कि Private Cloud के लिए Apigee में कॉन्फ़िगर किए गए अनुरोध के पेलोड का साइज़ 10 एमबी है.

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

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

गड़बड़ी की यह जानकारी इकट्ठा करें. इसके बाद, Apigee Edge की सहायता टीम से संपर्क करें:

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

• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी का नाम
• 502 गड़बड़ी को फिर से बनाने के लिए इस्तेमाल किया गया पूरा curl निर्देश
• एपीआई अनुरोधों के लिए ट्रेस फ़ाइल
• टारगेट/बैकएंड सर्वर से मिले जवाब का पूरा आउटपुट और पेलोड का साइज़

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

• अनुरोध पूरे न होने पर, गड़बड़ी का पूरा मैसेज दिखता है
• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी बंडल
• एपीआई के अनुरोध पूरे न होने की समस्या के लिए ट्रेस फ़ाइल
• 502 गड़बड़ी को फिर से बनाने के लिए इस्तेमाल किया गया पूरा curl निर्देश
• टारगेट/बैकएंड सर्वर से मिले जवाब का पूरा आउटपुट और पेलोड का साइज़

• NGINX ऐक्सेस लॉग /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  यहां: ORG, ENV, और PORT# को असल वैल्यू से बदल दिया जाता है.

• मैसेज प्रोसेसर के सिस्टम लॉग /opt/apigee/var/log/edge-message-processor/logs/system.log