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 है जो नीचे दी गई वजहों से हो सकती है:

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

गड़बड़ी की जांच करने के सामान्य तरीके

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

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

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

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

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

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

      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.

रिज़ॉल्यूशन

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

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

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

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

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

      <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. आपके पास ClientAuthEnabled के साथ SSLInfo एट्रिब्यूट होने चाहिए, 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 >
      

रेफ़रंस

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

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

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

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

1. एपीआई मॉनिटरिंग, ट्रेस टूल का इस्तेमाल करें या मैसेज आईडी तय करने के लिए, NGINX ऐक्सेस लॉग, गड़बड़ी का कोड और 502 गड़बड़ी का स्रोत.
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 गड़बड़ी हुई भी डाउनलोड कर सकता है. यह अपवाद बताता है कि फ़ाइल के आखिर में (EOF) है या स्ट्रीम के आखिर में अचानक संपर्क किया गया हो.

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

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 मैसेज प्रोसेसर, दोनों को बनाए रखने के लिए, ऐक्टिव टाइम आउट की सुविधा का इस्तेमाल करते हैं कनेक्शन एक-दूसरे के साथ खुलते हैं. कीप अलाइव टाइम आउट के दौरान कोई डेटा न मिलने पर अवधि के दौरान, बैकएंड सर्वर या मैसेज प्रोसेसर एक-दूसरे के साथ कनेक्शन बंद कर सकते हैं.

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

का मतलब गलत है कि अलाइव (चालू रखें) टाइम आउट का गलत कॉन्फ़िगरेशन

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

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

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

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

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

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

      नीचे बताए गए तरीके से, 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. इस बार, बैकएंड सर्वर मैसेज प्रोसेसर को FIN, ACK दिखाता है (पैकेट 6285) कनेक्शन बंद करने की प्रक्रिया शुरू करता है.

   इस उदाहरण में, एक ही कनेक्शन का दो बार फिर से इस्तेमाल किया गया है. हालांकि, तीसरे अनुरोध पर, बैकएंड सर्वर कनेक्शन को बंद करने की प्रक्रिया शुरू कर देता है, जबकि मैसेज प्रोसेसर बैकएंड सर्वर से डेटा मिलने का इंतज़ार कर रहे हैं. इससे पता चलता है कि बैकएंड सर्वर आम तौर पर, टाइम आउट की अवधि, एपीआई प्रॉक्सी में सेट की गई वैल्यू के बराबर या कम होती है. पुष्टि करने के लिए इसके बाद, 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. एपीआई प्रॉक्सी में, कीप अलाइव (चालू रखें) टाइम आउट प्रॉपर्टी के लिए सही वैल्यू कॉन्फ़िगर करें या मैसेज प्रोसेसर का इस्तेमाल करें, जैसे कि Keep अलाइव (चालू रखें) टाइम आउट प्रॉपर्टी, बैकएंड सर्वर, यहां बताए गए चरणों का इस्तेमाल करता है मैसेज प्रोसेसर पर, कीप अलाइव रहने का टाइम आउट कॉन्फ़िगर करना.

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

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

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

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

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

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

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

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

अगर आप निजी 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 को मैसेज प्रोसेसर या बैकएंड सर्वर पर या दोनों पर इकट्ठा किया जाता है हुआ