502 खराब गेटवे का अनचाहा ईओएफ़

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

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

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

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

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

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

संभावित कारण

502 Bad Gateway Error की एक आम वजह Unexpected EOF गड़बड़ी है. यह इन वजहों से हो सकती है:

वजह	जानकारी	इसके लिए दिए गए चरण
गलत तरीके से कॉन्फ़िगर किया गया टारगेट सर्वर	टारगेट सर्वर, TLS/एसएसएल कनेक्शन के साथ काम करने के लिए ठीक से कॉन्फ़िगर नहीं किया गया है.	Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता
बैकएंड सर्वर से EOFअपवाद	बैकएंड सर्वर अचानक ईओएफ़ भेज सकता है.	सिर्फ़ Edge प्राइवेट क्लाउड के उपयोगकर्ता
गलत तरीके से कॉन्फ़िगर किए गए 'ऐक्टिव रहने का टाइम आउट' चालू रखें	Apigee और बैकएंड सर्वर पर, टाइम आउट को गलत तरीके से कॉन्फ़िगर किए गए सेव रखें.	Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता

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

गड़बड़ी का पता लगाने के लिए, इनमें से किसी भी तरीके का इस्तेमाल किया जा सकता है:

• एपीआई को मॉनिटर करना
• ट्रेस टूल
• NGINX के ऐक्सेस लॉग

वजह: गलत तरीके से कॉन्फ़िगर किया गया टारगेट सर्वर

टारगेट सर्वर, TLS/एसएसएल कनेक्शन के साथ काम करने के लिए ठीक से कॉन्फ़िगर नहीं किया गया है.

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

1. 502 गड़बड़ी के लिए मैसेज आईडी, गड़बड़ी का कोड, और गड़बड़ी का सोर्स पता करने के लिए, एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करें.
2. जिस एपीआई पर असर पड़ा है उसके लिए, यूज़र इंटरफ़ेस (यूआई) में ट्रेस की सुविधा चालू करें.
3. अगर पूरे न होने वाले एपीआई अनुरोध के लिए ट्रेस में यह जानकारी दिखती है:
   1. टारगेट फ़्लो का अनुरोध शुरू होते ही 502 Bad Gateway गड़बड़ी दिखती है.
   2. error.class में messaging.adaptors.http.UnexpectedEOF. दिखता है

      इसके बाद, हो सकता है कि यह समस्या किसी गलत टारगेट सर्वर कॉन्फ़िगरेशन की वजह से हुई हो.

4. Edge मैनेजमेंट एपीआई कॉल का इस्तेमाल करके, टारगेट सर्वर की परिभाषा जानें:
   1. अगर आप सार्वजनिक क्लाउड उपयोगकर्ता हैं, तो इस एपीआई का इस्तेमाल करें:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

   2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो इस एपीआई का इस्तेमाल करें:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

      गड़बड़ी वाले TargetServer की परिभाषा का नमूना:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >
      

5. यहां उदाहरण के तौर पर TargetServer की परिभाषा दी गई है.

   मान लें कि टारगेट सर्वर mocktarget.apigee.net को, पोर्ट 443 पर सुरक्षित (एचटीटीपीएस) कनेक्शन स्वीकार करने के लिए कॉन्फ़िगर किया गया है. हालांकि, अगर आप टारगेट सर्वर की परिभाषा देखें, तो उसमें ऐसे दूसरे एट्रिब्यूट/फ़्लैग नहीं हैं जिनसे पता चलता हो कि यह सुरक्षित कनेक्शन के लिए है. इसकी वजह से Edge, टारगेट सर्वर पर जाने वाले एपीआई अनुरोधों को एचटीटीपी (असुरक्षित) अनुरोधों के तौर पर मेज़र करता है. इसलिए, Edge इस टारगेट सर्वर के साथ एसएसएल हैंडशेक प्रोसेस शुरू नहीं करेगा.

   टारगेट सर्वर को 443 पर सिर्फ़ एचटीटीपीएस (एसएसएल) अनुरोध स्वीकार करने के लिए कॉन्फ़िगर किया गया है. इसलिए, यह Edge से किए गए अनुरोध को अस्वीकार कर देगा या कनेक्शन बंद कर देगा. इस वजह से, आपको मैसेज प्रोसेसर पर UnexpectedEOFAtTarget गड़बड़ी मिलती है. मैसेज प्रोसेसर, क्लाइंट के रिस्पॉन्स के तौर पर 502 Bad Gateway भेजेगा.

रिज़ॉल्यूशन

हमेशा पक्का करें कि टारगेट सर्वर आपकी ज़रूरतों के मुताबिक सही तरीके से कॉन्फ़िगर किया गया हो.

ऊपर दिए गए उदाहरण में, किसी सुरक्षित (एचटीटीपीएस/एसएसएल) टारगेट सर्वर को अनुरोध भेजने के लिए आपको SSLInfo एट्रिब्यूट शामिल करना होगा. साथ ही, enabled फ़्लैग को true पर सेट करना होगा. टारगेट सर्वर के लिए, SSLInfo एट्रिब्यूट को टारगेट एंडपॉइंट डेफ़िनिशन में जोड़ने की अनुमति होती है. हालांकि, हमारा सुझाव है कि आप टारगेट सर्वर की परिभाषा के हिस्से के तौर पर SSLInfo एट्रिब्यूट जोड़ें, ताकि किसी तरह की गड़बड़ी से बचा जा सके.

1. अगर बैकएंड सेवा के लिए एकतरफ़ा एसएसएल कम्यूनिकेशन की ज़रूरत हो, तो:
   1. आपको TargetServer परिभाषा में TLS/एसएसएल को चालू करने के लिए, ऐसे SSLInfo एट्रिब्यूट शामिल करने होंगे जिनमें enabled फ़्लैग 'सही' पर सेट है, जैसा कि यहां दिखाया गया है:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
      

   2. अगर आपको Edge में टारगेट सर्वर के सर्टिफ़िकेट की पुष्टि करनी है, तो हमें नीचे बताए गए तरीके से ट्रस्टस्टोर (इसमें टारगेट सर्वर का सर्टिफ़िकेट शामिल है) भी शामिल करना होगा:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>
      

2. अगर बैकएंड सेवा के लिए दो-तरफ़ा एसएसएल कम्यूनिकेशन की ज़रूरत हो, तो:
   1. आपके पास SSLInfo एट्रिब्यूट के ClientAuthEnabled, Keystore, KeyAlias, और Truststore फ़्लैग सही तरीके से सेट होने चाहिए, जैसा कि यहां दिखाया गया है:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >
      

References

सभी बैकएंड सर्वर पर लोड बैलेंसिंग

वजह: बैकएंड सर्वर से मिलने वाला EOFअपवाद

बैकएंड सर्वर अचानक से ईओएफ़ (फ़ाइल के आखिर में) भेज सकता है.

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

1. 502 गड़बड़ी के लिए मैसेज आईडी, गड़बड़ी का कोड, और गड़बड़ी का सोर्स पता करने के लिए, एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करें.
2. मैसेज प्रोसेसर के लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) की जांच करें और यह देखें कि क्या आपके पास खास एपीआई के लिए eof unexpected है. इसके अलावा, अगर आपके पास एपीआई अनुरोध के लिए यूनीक messageid है, तो उसे खोजा जा सकता है.

   मैसेज प्रोसेसर लॉग से, अपवाद वाले स्टैक ट्रेस का सैंपल

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
   

   ऊपर दिए गए उदाहरण में, देखा जा सकता है कि जब मैसेज प्रोसेसर बैकएंड सर्वर से रिस्पॉन्स पढ़ने की कोशिश कर रहा था, तब java.io.EOFException: eof unexpected गड़बड़ी हुई. इस अपवाद से पता चलता है कि फ़ाइल खत्म हो गई है (ईओएफ़) या स्ट्रीम अचानक खत्म हो गई है.

   इसका मतलब है कि मैसेज प्रोसेसर ने बैकएंड सर्वर पर एपीआई अनुरोध भेजा और वह रिस्पॉन्स का इंतज़ार कर रहा था या उसे पढ़ रहा था. हालांकि, मैसेज प्रोसेसर को जवाब मिलने से पहले ही बैकएंड सर्वर ने कनेक्शन को अचानक बंद कर दिया या पूरा रिस्पॉन्स पढ़ पाया.

3. अपने बैकएंड सर्वर लॉग की जांच करें और देखें कि क्या उसमें ऐसी कोई गड़बड़ी या जानकारी है जिसकी वजह से बैकएंड सर्वर, कनेक्शन को अचानक बंद कर सकता है. अगर आपको कोई गड़बड़ी या जानकारी मिलती है, तो रिज़ॉल्यूशन पर जाएं. और अपने बैकएंड सर्वर में समस्या को सही तरीके से ठीक करें.
4. अगर आपको अपने बैकएंड सर्वर में कोई गड़बड़ी या जानकारी नहीं मिलती है, तो मैसेज प्रोसेसर पर tcpdump आउटपुट इकट्ठा करें:
   1. अगर आपके बैकएंड सर्वर होस्ट का एक ही आईपी पता है, तो यह निर्देश इस्तेमाल करें:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
      

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

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
      

      आम तौर पर, यह गड़बड़ी तब होती है, जब मैसेज प्रोसेसर, बैकएंड सर्वर को अनुरोध भेजता है. जैसे ही बैकएंड सर्वर, [FIN,ACK] के साथ रिस्पॉन्स देता है.

5. tcpdump के इस उदाहरण पर ध्यान दें.

   502 Bad Gateway Error (UnexpectedEOFAtTarget) होने पर लिया गया tcpdump नमूना

   

6. TCPDump आउटपुट से, आपको इवेंट का यह क्रम दिखता है:
   1. पैकेट 985 में, मैसेज प्रोसेसर, बैकएंड सर्वर को एपीआई अनुरोध भेजता है.
   2. पैकेट 986 में, बैकएंड सर्वर तुरंत [FIN,ACK] का जवाब देता है.
   3. पैकेट 987 में, मैसेज प्रोसेसर [FIN,ACK] के साथ बैकएंड सर्वर पर जवाब देता है.
   4. आखिरकार, [ACK] और [RST] दोनों तरफ़ से कनेक्शन बंद हो जाते हैं.
   5. बैकएंड सर्वर, [FIN,ACK] भेजता है, इसलिए आपको मैसेज प्रोसेसर पर java.io.EOFException: eof unexpected अपवाद मिलता है.
7. बैकएंड सर्वर पर नेटवर्क की कोई समस्या होने पर ऐसा हो सकता है. इस समस्या की आगे की जांच करने के लिए, अपनी नेटवर्क ऑपरेशंस टीम से संपर्क करें.

रिज़ॉल्यूशन

बैकएंड सर्वर पर सही तरीके से समस्या को ठीक करें.

अगर समस्या बनी रहती है और आपको 502 Bad Gateway Error से जुड़ी समस्या हल करने में मदद चाहिए या आपको लगता है कि यह समस्या Edge में है, तो Apigee Edge की सहायता टीम से संपर्क करें.

वजह: गलत तरीके से कॉन्फ़िगर किए गए 'लाइव स्ट्रीम को चालू रखें' टाइम आउट

502 गड़बड़ियों की वजह यही है या नहीं, इसका पता लगाने से पहले, कृपया इन सिद्धांतों को पढ़ें.

Apigee में स्थायी कनेक्शन

डिफ़ॉल्ट रूप से Apigee (और एचटीटीपी/1.1 स्टैंडर्ड के मुताबिक) टारगेट बैकएंड सर्वर से कम्यूनिकेट करते समय स्थायी कनेक्शन का इस्तेमाल करता है. स्थायी कनेक्शन, पहले से मौजूद टीसीपी और (अगर लागू हो) TLS/एसएसएल कनेक्शन को फिर से इस्तेमाल करने की अनुमति देकर, परफ़ॉर्मेंस को बेहतर बना सकते हैं. इससे, इंतज़ार का समय कम होता है. जिस अवधि तक कनेक्शन को बनाए रखने की ज़रूरत होती है उसे प्रॉपर्टी कीप अलाइव टाइम आउट (keepalive.timeout.millis) की मदद से कंट्रोल किया जाता है.

कनेक्शन को एक-दूसरे के साथ खुला रखने के लिए, बैकएंड सर्वर और Apigee Message प्रोसेसर, दोनों ही टाइम आउट बनाए रखते हैं. टाइम आउट की अवधि में कोई डेटा न मिलने पर, बैकएंड सर्वर या मैसेज प्रोसेसर, दूसरे कनेक्शन के साथ कनेक्शन को बंद कर सकता है.

डिफ़ॉल्ट रूप से, Apigee में मैसेज प्रोसेसर में डिप्लॉय किए गए एपीआई प्रॉक्सी का टाइम आउट तब तक 60s पर सेट रहता है, जब तक इसे ओवरराइड न कर दिया जाए. 60s के लिए कोई डेटा न मिलने पर, Apigee, बैकएंड सर्वर के साथ कनेक्शन बंद कर देगा. बैकएंड सर्वर, टाइम आउट की अवधि को भी बनाए रखेगा. इसकी समयसीमा खत्म होने के बाद, बैकएंड सर्वर, मैसेज प्रोसेसर के साथ कनेक्शन बंद कर देगा.

गलत तरीके से अलाइव रखा गया टाइम आउट कॉन्फ़िगरेशन का गलत असर

अगर Apigee या बैकएंड सर्वर को, गलत कीप अलाइव टाइम आउट के साथ कॉन्फ़िगर किया गया है, तो इससे एक रेस कंडिशन बन जाती है. इस वजह से, बैकएंड सर्वर किसी संसाधन के अनुरोध के जवाब में एक अनचाहा End Of File (FIN) भेजता है.

उदाहरण के लिए, अगर Keep aलाइव टाइम आउट को एपीआई प्रॉक्सी या मैसेज प्रोसेसर में कॉन्फ़िगर किया गया है, जिसकी वैल्यू अपस्ट्रीम बैकएंड सर्वर के टाइम आउट से ज़्यादा या उसके बराबर है, तो नीचे दी गई रेस कंडिशन हो सकती है. इसका मतलब है कि अगर मैसेज प्रोसेसर को बैकएंड सर्वर के थ्रेशोल्ड के बहुत करीब पहुंचने तक कोई डेटा नहीं मिलता है, तो टाइम आउट की अवधि तय करें. ऐसे में, उस प्रोसेस के लिए एक अनुरोध भेजा जाता है और मौजूदा कनेक्शन का इस्तेमाल करके बैकएंड सर्वर को भेज दिया जाता है. इस वजह से, ईओएफ़ में अनचाही गड़बड़ी की वजह से 502 Bad Gateway हो सकता है. इसके बारे में यहां बताया गया है:

1. मान लें कि Message प्रोसेसर और बैकएंड सर्वर, दोनों पर बनाए रखने के लिए टाइम आउट 60 सेकंड पर सेट है और कोई खास Message प्रोसेसर, पिछला अनुरोध पूरा करने के 59 सेकंड बाद तक कोई नया अनुरोध नहीं मिला.
2. मैसेज प्रोसेसर, 59वें सेकंड पर मिले अनुरोध को प्रोसेस करने के लिए, मौजूदा कनेक्शन का इस्तेमाल करता है. ऐसा इसलिए होता है, क्योंकि इसे सेव रखने के लिए टाइम आउट अब तक नहीं लिया गया है. इसके बाद, यह अनुरोध बैकएंड सर्वर पर भेजा जाता है.
3. हालांकि, बैकएंड सर्वर पर अनुरोध आने से पहले, बैकएंड सर्वर पर कीप अलाइव टाइम आउट की सीमा खत्म हो गई.
4. संसाधन के लिए Message प्रोसेसर का अनुरोध इन-फ़्लाइट होता है, लेकिन बैकएंड सर्वर Message प्रोसेसर को एक FIN पैकेट भेजकर कनेक्शन को बंद करने की कोशिश करता है.
5. जब मैसेज प्रोसेसर, डेटा मिलने का इंतज़ार कर रहा होता है, तब उसे अनचाहा FIN मिलता है और कनेक्शन बंद कर दिया जाता है.
6. इसकी वजह से, Unexpected EOF मिलता है और बाद में मैसेज प्रोसेसर की मदद से, क्लाइंट को 502 वापस भेजा जाता है.

इस मामले में, हमें 502 गड़बड़ी हुई. इसकी वजह यह है कि मैसेज प्रोसेसर और बैकएंड सर्वर, दोनों पर एक ही कीप अलाइव टाइम आउट वैल्यू को 60 सेकंड तक कॉन्फ़िगर किया गया था. इसी तरह, यह समस्या तब भी हो सकती है, जब Message प्रोसेसर पर लाइव टाइम आउट रखने के लिए बैकएंड सर्वर के बजाय, ज़्यादा वैल्यू को कॉन्फ़िगर किया गया हो.

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

1. अगर आप सार्वजनिक क्लाउड उपयोगकर्ता हैं, तो:
   1. एपीआई मॉनिटरिंग या ट्रेस टूल का इस्तेमाल करें (जैसा कि गड़बड़ी की जानकारी देने के सामान्य तरीके में बताया गया है) और पुष्टि करें कि आपके पास ये दोनों सेटिंग हैं:
      • गलत कोड: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • गलती का सोर्स: target
   2. आगे की जांच के लिए, tcpdump का इस्तेमाल करना पर जाएं.
2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं:
   1. 502 गड़बड़ी का मैसेज आईडी, गड़बड़ी का कोड, और गड़बड़ी का सोर्स पता करने के लिए, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करें.
   2. मैसेज प्रोसेसर लॉग
      (/opt/apigee/var/log/edge-message-processor/logs/system.log) में मैसेज आईडी खोजें.
   3. आपको java.io.EOFEXception: eof unexpected इस तरह दिखेगा:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
      

   4. गड़बड़ी java.io.EOFException: eof unexpected से पता चलता है कि मैसेज प्रोसेसर को EOF तब मिला, जब वह बैकएंड सर्वर से रिस्पॉन्स पढ़ने का इंतज़ार कर रहा था.
   5. ऊपर दिए गए गड़बड़ी के मैसेज में useCount=7 एट्रिब्यूट से पता चलता है कि Message प्रोसेसर ने इस कनेक्शन को करीब सात बार फिर से इस्तेमाल किया था. साथ ही, bytesWritten=159 एट्रिब्यूट से पता चलता है कि मैसेज प्रोसेसर ने बैकएंड सर्वर को, 159 बाइट का अनुरोध पेलोड भेजा था. हालांकि, अचानक EOF होने पर इसे शून्य बाइट वापस मिले.

   6. इससे पता चलता है कि मैसेज प्रोसेसर ने एक ही कनेक्शन को कई बार फिर से इस्तेमाल किया है. इस दौरान, इसने डेटा भी भेजा, लेकिन कुछ समय बाद ही कोई डेटा मिलने से पहले ही EOF मिल गया. इसका मतलब है कि इस बात की काफ़ी संभावना है कि बैकएंड सर्वर के 'लाइव रहने का समय' टाइम आउट, एपीआई प्रॉक्सी में सेट किए गए टाइम आउट से कम या उसके बराबर हो.

      नीचे बताए गए तरीके से, tcpdump की मदद से आगे की जांच की जा सकती है.

tcpdump का इस्तेमाल करना

1. बैकएंड सर्वर पर tcpdump कैप्चर करने के लिए, इस निर्देश का इस्तेमाल करें:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name
   

2. कैप्चर किए गए tcpdump का विश्लेषण करें:

   यहां tcpdump आउटपुट का सैंपल दिया गया है:

   

   ऊपर दिए गए सैंपल tcpdump में, आपको यह जानकारी दिखती है:

   1. पैकेट 5992, में बैकएंड सर्वर को GET का अनुरोध मिला.
   2. पैकेट 6064 में, यह 200 OK. के साथ जवाब देता है
   3. पैकेट 6084 में, बैकएंड सर्वर को GET का एक और अनुरोध मिला.
   4. पैकेट 6154 में, यह 200 OK के साथ जवाब देता है.
   5. पैकेट 6228 में, बैकएंड सर्वर को GET का तीसरा अनुरोध मिला.
   6. इस बार, बैकएंड सर्वर, कनेक्शन बंद करने की शुरुआत करते हुए, मैसेज प्रोसेसर (पैकेट 6285) को FIN, ACK दिखाता है.

   इस उदाहरण में, एक ही कनेक्शन को दो बार फिर से इस्तेमाल किया गया था. हालांकि, तीसरे अनुरोध पर, बैकएंड सर्वर कनेक्शन को बंद करने की प्रक्रिया शुरू कर देता है. इस दौरान, मैसेज प्रोसेसर, बैकएंड सर्वर से डेटा का इंतज़ार कर रहा होता है. इससे पता चलता है कि बैकएंड सर्वर के चालू रहने का टाइम आउट, एपीआई प्रॉक्सी में सेट की गई वैल्यू से कम या उसके बराबर है. इसकी पुष्टि करने के लिए, Apigee और बैकएंड सर्वर पर, 'चालू रखें' टाइम आउट की तुलना करना देखें.

Apigee और बैकएंड सर्वर पर, सेव रखने के टाइम आउट की तुलना करना

1. डिफ़ॉल्ट रूप से, Apigee, Keep अलाइव टाइम आउट प्रॉपर्टी के लिए 60 सेकंड की वैल्यू का इस्तेमाल करता है.

2. हालांकि, यह संभव है कि आपने एपीआई प्रॉक्सी में डिफ़ॉल्ट वैल्यू को बदल दिया हो. इसकी पुष्टि करने के लिए, 502 गड़बड़ियां देने वाले एपीआई के उस प्रॉक्सी में खास TargetEndpoint परिभाषा की जांच करें जो काम न कर रहा हो.

   TargetEndpoint कॉन्फ़िगरेशन का सैंपल:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

   ऊपर दिए गए उदाहरण में, कीप अलाइव टाइम आउट प्रॉपर्टी को 30 सेकंड (30000 मिलीसेकंड) की वैल्यू से बदल दिया गया है.

3. इसके बाद, अपने बैकएंड सर्वर पर कॉन्फ़िगर की गई कीप अलाइव टाइम आउट प्रॉपर्टी देखें. मान लें कि आपका बैकएंड सर्वर 25 seconds वैल्यू के साथ कॉन्फ़िगर किया गया.
4. अगर आपको पता चलता है कि Apigee पर कीप अलाइव टाइम आउट प्रॉपर्टी की वैल्यू, बैकएंड सर्वर पर सेव किए गए टाइम आउट प्रॉपर्टी की वैल्यू से ज़्यादा है, तो इसी वजह से 502 गड़बड़ियां हुईं.

रिज़ॉल्यूशन

पक्का करें कि Apigee (एपीआई प्रॉक्सी और मैसेज प्रोसेसर कॉम्पोनेंट में) पर, लाइव को सेव रखने की टाइम आउट प्रॉपर्टी हमेशा बैकएंड सर्वर की तुलना में कम हो.

1. बैकएंड सर्वर पर, 'चालू रखें' टाइम आउट के लिए सेट की गई वैल्यू तय करें.
2. एपीआई प्रॉक्सी या मैसेज प्रोसेसर में Keep aलाइव टाइम आउट प्रॉपर्टी के लिए कोई सही वैल्यू कॉन्फ़िगर करें, जैसे कि कीप अलाइव टाइम आउट प्रॉपर्टी की वैल्यू, बैकएंड सर्वर पर सेट की गई वैल्यू से कम हो. ऐसा करने के लिए, Message प्रोसेसर पर Keep aलाइव टाइम आउट को कॉन्फ़िगर करना में बताया गया तरीका अपनाएं.

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

सबसे सही तरीका

यह सलाह दी जाती है कि डाउनस्ट्रीम कॉम्पोनेंट के लिए, लाइव टाइम आउट की तय सीमा हमेशा कम होती है, जो अपस्ट्रीम सर्वर पर कॉन्फ़िगर किए गए टाइम आउट की सीमा से कम होती है, ताकि इस तरह की रेस की स्थितियों और 502 गड़बड़ियों से बचा जा सके. हर डाउनस्ट्रीम हॉप की वैल्यू, हर अपस्ट्रीम हॉप से कम होनी चाहिए. Apigee Edge में, इन दिशा-निर्देशों का पालन करना बेहतर है:

1. क्लाइंट के पास लाइव रखने का टाइम आउट, Edge राऊटर को सेव रखने के टाइम आउट से कम होना चाहिए.
2. Edge राऊटर को लाइव रखने का टाइम आउट, मैसेज प्रोसेसर को लाइव रखने के टाइम आउट से कम होना चाहिए.
3. मैसेज प्रोसेसर को लाइव रखने का टाइम आउट, टारगेट सर्वर के पास अलाइव रखने के टाइम आउट से कम होना चाहिए.
4. अगर आपके पास Apigee के आगे या पीछे कोई और हॉप है, तो भी वही नियम लागू किया जाना चाहिए. अपस्ट्रीम के साथ कनेक्शन बंद करने की ज़िम्मेदारी हमेशा आपको डाउनस्ट्रीम क्लाइंट की ज़िम्मेदारी के तौर पर छोड़नी चाहिए.

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

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

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

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

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

• असफल अनुरोधों के लिए देखा गया पूरा गड़बड़ी का मैसेज
• संगठन, एनवायरमेंट का नाम, और एपीआई प्रॉक्सी का नाम, जिसके लिए 502 गड़बड़ियां देखी जा रही हैं
• एपीआई प्रॉक्सी बंडल
• 502 Bad Gateway - Unexpected EOF गड़बड़ी वाले अनुरोधों वाली ट्रेस फ़ाइल
• NGINX के ऐक्सेस लॉग
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• मैसेज प्रोसेसर के लॉग
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• वह समयावधि जिसमें 502 गड़बड़ी हुई. टाइमज़ोन की जानकारी के साथ वह समयावधि
• गड़बड़ी होने के दौरान, Tcpdumps को मैसेज प्रोसेसर या बैकएंड सर्वर पर या दोनों पर इकट्ठा किया गया था