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

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

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

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

एचटीटीपी स्टेटस कोड 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 गड़बड़ी है. यह गड़बड़ी इन वजहों से हो सकती है:

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

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

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

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

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

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

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

      ऐसे में, हो सकता है कि टारगेट सर्वर का कॉन्फ़िगरेशन गलत हो.

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

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

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

      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. अगर बैकएंड सेवा के लिए एकतरफ़ा SSL कम्यूनिकेशन की ज़रूरत है, तो:
   1. आपको TargetServer की परिभाषा में टीएलएस/एसएसएल चालू करना होगा. इसके लिए, आपको 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. अगर बैकएंड सेवा के लिए दोनों तरफ़ से SSL कम्यूनिकेशन की ज़रूरत है, तो:
   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 >

रेफ़रंस

बैकएंड सर्वर के बीच लोड बैलेंस करना

वजह: बैकएंड सर्वर से EOFException

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

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

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] भेजता है. इसलिए, आपको Message Processor पर java.io.EOFException: eof unexpected अपवाद मिलता है.
7. ऐसा तब हो सकता है, जब बैकएंड सर्वर में नेटवर्क की कोई समस्या हो. इस समस्या की ज़्यादा जांच करने के लिए, अपनी नेटवर्क ऑपरेशंस टीम से संपर्क करें.

रिज़ॉल्यूशन

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

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

वजह: कीप अलाइव टाइमआउट को गलत तरीके से कॉन्फ़िगर किया गया है

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

Apigee में परसिस्टेंट कनेक्शन

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

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

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

Keep Alive टाइमआउट कॉन्फ़िगरेशन गलत होने का असर

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

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

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

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

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

1. अगर आप Public Cloud के उपयोगकर्ता हैं, तो:
   1. एपीआई मॉनिटरिंग या ट्रेस टूल का इस्तेमाल करें. इसके बारे में डाइग्नोसिस के सामान्य चरणों में बताया गया है. साथ ही, पुष्टि करें कि आपके पास ये दोनों सेटिंग हैं:
      • गड़बड़ी का कोड: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • समस्या का सोर्स: target
   2. ज़्यादा जानकारी के लिए, tcpdump का इस्तेमाल करना लेख पढ़ें.
2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो:
   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 से पता चलता है कि मैसेज प्रोसेसर ने इस कनेक्शन का इस्तेमाल करीब सात बार किया था. साथ ही, एट्रिब्यूट 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, कीप अलाइव टाइमआउट प्रॉपर्टी के लिए 60 सेकंड की वैल्यू का इस्तेमाल करता है.

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

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

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

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

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

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

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

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

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

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

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

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