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

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

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

   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 एमबी से ज़्यादा है और Apigee जब ऐप्लिकेशन का साइज़ 10 एमबी की तय सीमा से ज़्यादा होने लगता है, तब गड़बड़ी का कोड मिलता है protocol.http.TooBigBody

रिज़ॉल्यूशन

सीमाएं

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

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

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

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

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

   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 को 10m मान के साथ सेट कर दिया गया है http.properties.

   इससे पता चलता है कि अनुरोध पेलोड साइज़ की सीमा को Apigee प्राइवेट क्लाउड 10 एमबी का है.

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

ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी जानकारी इकट्ठा करना ज़रूरी है

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

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

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

अगर आप निजी 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