502 गलत गेटवे - ToBigBody

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

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

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

संभावित कारण

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

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

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

निदान के सामान्य चरण

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

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

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

1. एपीआई मॉनिटरिंग,ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके मिली गड़बड़ी के लिए, फ़ॉल कोड, गड़बड़ी का सोर्स, और रिस्पॉन्स पेलोड का साइज़ तय करें. समस्या #1 में बताए गए तरीके से डाइग्नोज़ के सामान्य तरीके जानें.
2. अगर गड़बड़ी सोर्स की वैल्यू target है, तो इससे पता चलता है कि टारगेट/बैकएंड सर्वर से Apigee को भेजा गया रिस्पॉन्स पेलोड साइज़, Apigee Edge में स्वीकार की गई सीमा से ज़्यादा है.
3. पहले चरण में दिए गए रिस्पॉन्स पेलोड के साइज़ की पुष्टि करें.
   • अगर पेलोड का साइज़ 10 एमबी से ज़्यादा है, तो यही गड़बड़ी है.
   • अगर पेलोड का साइज़ ~ 10 एमबी की अनुमति वाली सीमा है, तो हो सकता है कि रिस्पॉन्स पेलोड को कंप्रेस किए गए फ़ॉर्मैट में पास किया गया हो. वजह: डीकंप्रेशन के बाद रिस्पॉन्स पेलोड का साइज़, तय सीमा से ज़्यादा हो गया है पर जाएं.
4. नीचे दिए गए तरीके से असली रिस्पॉन्स की जांच करके पुष्टि करें कि रिस्पॉन्स पेलोड साइज़ 10 एमबी से ज़्यादा की है या नहीं:
   1. अगर आपके पास टारगेट/बैकएंड सर्वर से किए गए असल अनुरोध का ऐक्सेस नहीं है, तो रिज़ॉल्यूशन पर जाएं.
   2. अगर आपके पास टारगेट/बैकएंड सर्वर से किए गए असल अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:
      1. अगर आप पब्लिक क्लाउड/प्राइवेट क्लाउड के उपयोगकर्ता हैं, तो बैकएंड सर्वर या किसी ऐसी मशीन से सीधे बैकएंड सर्वर को अनुरोध भेजें जहां से आपके पास बैकएंड सर्वर को अनुरोध करने की अनुमति हो.
      2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो आपके पास मैसेज प्रोसेसर की मदद से भी बैकएंड सर्वर को अनुरोध भेजने का विकल्प होता है.
      3. कॉन्टेंट की लंबाई वाले हेडर की जांच करके, रिस्पॉन्स में पास किए गए पेलोड के साइज़ की पुष्टि करें.
      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 में बताए गए सामान्य तरीके से बताया गया है.
2. अगर फ़ॉल सोर्स की वैल्यू target है, तो इससे पता चलता है कि टारगेट/बैकएंड ऐप्लिकेशन से Apigee को भेजा गया रिस्पॉन्स पेलोड साइज़, Apigee Edge की अनुमति वाली सीमा से ज़्यादा है.
3. पहले चरण में दिए गए रिस्पॉन्स पेलोड के साइज़ की पुष्टि करें.
   • अगर पेलोड का साइज़ 10 एमबी से ज़्यादा है, तो यही गड़बड़ी है.
   • अगर पेलोड का साइज़ ~ 10 एमबी की अनुमति वाली सीमा में है, तो हो सकता है कि रिस्पॉन्स पेलोड को कंप्रेस किए गए फ़ॉर्मैट में पास किया गया हो. इस मामले में, कंप्रेस किए गए रिस्पॉन्स पेलोड के कंप्रेस किए गए साइज़ की जांच करें.
4. यह पुष्टि की जा सकती है कि टारगेट/बैकएंड से मिला जवाब, कंप्रेस किए गए फ़ॉर्मैट में भेजा गया था और कंप्रेस नहीं किया गया साइज़, तय सीमा से ज़्यादा था. इसके लिए, इनमें से किसी एक तरीके का इस्तेमाल करें:

   ट्रेस

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

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

   वास्तविक अनुरोध

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

   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 एमबी था.

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

   Messages प्रोसेसर के लॉग का इस्तेमाल करना:

   1. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो आपके पास मैसेज प्रोसेसर लॉग का इस्तेमाल करके, एचटीटीपी 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 एमबी से ज़्यादा है और जब साइज़ 10 एमबी से ज़्यादा होने लगता है, तब Apigee गड़बड़ी दिखाता है. साथ ही, गड़बड़ी का कोड protocol.http.TooBigBody होता है

रिज़ॉल्यूशन

सीमाएं

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

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

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

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

1. Message प्रोसेसर मशीन पर, /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 की सहायता टीम से संपर्क करें:

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

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

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

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

• 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