502 खराब गेटवे टाइमआउट गड़बड़ी

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

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

क्लाइंट ऐप्लिकेशन को 502 बैड गेटवे से जुड़ी गड़बड़ी मिलती है. जब मैसेज प्रोसेसर को बैकएंड सर्वर से कोई जवाब नहीं मिलता, तो मैसेज प्रोसेसर इस गड़बड़ी को क्लाइंट ऐप्लिकेशन को दिखाता है.

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

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

HTTP/1.1 502 Bad Gateway

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

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

संभावित वजह

इस समस्या की संभावित वजहों के बारे में यहां टेबल दी गई है:

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

कारण: TLS/एसएसएल हैंडशेक टाइम आउट

Apigee Edge में, बैकएंड सर्वर से TLS/एसएसएल कनेक्शन सेट अप किया जा सकता है. ऐसा करके, Edge Message प्रोसेसर और बैकएंड सर्वर के बीच TLS कम्यूनिकेशन चालू किया जा सकता है.

TLS/एसएसएल हैंडशेक में कई चरण शामिल होते हैं. यह गड़बड़ी आम तौर पर तब होती है, जब मैसेज प्रोसेसर और बैकएंड सर्वर के बीच TLS/एसएसएल हैंडशेक हो जाता है.

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

यह सेक्शन बताता है कि TLS/एसएसएल हैंडशेक टाइम आउट का सही तरीके से विश्लेषण कैसे करें. यहां Edge प्राइवेट क्लाउड और सार्वजनिक क्लाउड के लिए निर्देश दिए गए हैं.

ट्रेस सेशन के आउटपुट की जांच करें

Apigee Edge Trace टूल का इस्तेमाल करके, समस्या का शुरुआती डायग्नोसिस कैसे करें, इस बारे में नीचे बताया गया है.

1. Edge यूज़र इंटरफ़ेस (यूआई) में, जिस एपीआई प्रॉक्सी पर असर हुआ है उसके लिए ट्रेस सेशन चालू करें.

2. अगर विफल होने वाले API अनुरोध का ट्रेस निम्न दिखाता है, तो हो सकता है कि TLS/SSL हैंडशेक टाइम आउट की गड़बड़ी हुई हो. गड़बड़ी की संभावित वजह यह है कि बैकएंड सर्वर फ़ायरवॉल, Apigee से आने वाले ट्रैफ़िक को ब्लॉक कर रहा है.

   1. देखें कि क्या 502 खराब गेटवे गड़बड़ी, 55 सेकंड के बाद होती है. यह मैसेज प्रोसेसर पर सेट की गई डिफ़ॉल्ट टाइम आउट अवधि है. अगर आपको लगता है कि गड़बड़ी 55 सेकंड के बाद हुई है, तो इससे पता चलता है कि इस समस्या की वजह टाइम आउट होना ही था.
   2. देखें कि गड़बड़ी में गड़बड़ी दिखती है या नहीं: messaging.adaptors.http.BadGateway. ध्यान दें, यह गड़बड़ी आम तौर पर टाइम आउट होने की जानकारी देती है.

   3. अगर Edge Private Cloud का इस्तेमाल किया जा रहा है, तो ट्रेस आउटपुट में X-Apigee.Message-ID फ़ील्ड की वैल्यू पर ध्यान दें, जैसा कि यहां दिखाया गया है. निजी क्लाउड उपयोगकर्ता इस आईडी वैल्यू का इस्तेमाल, समस्या हल करने के लिए कर सकता है. इसके बारे में आगे बताया गया है.

      1. ट्रेस पाथ में, Analytics डेटा रिकॉर्ड किया गया आइकॉन पर क्लिक करें:

         

      2. नीचे की ओर स्क्रोल करें और X-Apigee.Message-ID नाम की फ़ील्ड की वैल्यू नोट करें.

यह पुष्टि करने के लिए कि TLS/एसएसएल हैंडशेक टाइम आउट की वजह से गड़बड़ी हुई थी, नीचे दिए गए सेक्शन में दिया गया तरीका अपनाएं. यह तरीका इस बात पर निर्भर करता है कि आप पब्लिक क्लाउड का इस्तेमाल कर रहे हैं या प्राइवेट क्लाउड.

सिर्फ़ Edge प्राइवेट क्लाउड का इस्तेमाल करने वालों के लिए, गड़बड़ी की जानकारी के अतिरिक्त चरण

अगर आप Apigee Edge के प्राइवेट क्लाउड का इस्तेमाल कर रहे हैं, तो हैंडशेक से जुड़ी गड़बड़ी की वजह की पुष्टि करने के लिए, नीचे दिया गया तरीका अपनाएं. इस चरण में, आपको काम की जानकारी के लिए Message प्रोसेसर की लॉग फ़ाइल की जांच करनी होती है. अगर आप Edge Public Cloud का इस्तेमाल कर रहे हैं, तो इस सेक्शन को छोड़कर, निजी और सार्वजनिक क्लाउड उपयोगकर्ताओं के लिए डाइग्नोस्टिक्स के ज़्यादा चरण पर जाएं.

1. देखें कि क्या telnet कमांड का इस्तेमाल करके, हर मैसेज प्रोसेसर से सीधे तौर पर किसी बैकएंड सर्वर से कनेक्ट किया जा सकता है:

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

      telnet BackendServer-IPaddress 443

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

      telnet BackendServer-HostName 443

   अगर आपको बैकएंड सर्वर से कनेक्ट करने में कोई गड़बड़ी नहीं मिली, तो अगले चरण पर जाएं.

   अगर telnet कमांड काम नहीं करता, तो आपको अपनी नेटवर्क टीम के साथ मिलकर, मैसेज प्रोसेसर और बैकएंड सर्वर के बीच कनेक्टिविटी की जांच करनी होगी.

2. हैंडशेक फ़ेल होने के सबूत के लिए, मैसेज प्रोसेसर की लॉग फ़ाइल देखें. फ़ाइल खोलें:

   /opt/apigee/var/log/edge-message-processor/system.log

   और यूनीक मैसेज आईडी (ट्रेस फ़ाइल में मिलने वाले X-Apigee.Message-ID की वैल्यू) को खोजें. तय करें कि क्या आपको मैसेज आईडी से जुड़ा हैंडशेक गड़बड़ी का मैसेज दिखता है, जैसा कि नीचे दिखाया गया है:

   org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
   HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
   isOpen=true handshake timeout
   

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

अगर आपको लॉग फ़ाइल में हैंडशेक मैसेज नहीं दिखता, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं

Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ताओं के लिए, गड़बड़ी की जानकारी के कुछ और चरण

समस्या की ज़्यादा सटीक जानकारी पाने के लिए, टीसीपी/आईपी पैकेट का विश्लेषण करने के लिए tcpdump टूल इस्तेमाल किया जा सकता है. इस टूल की मदद से, यह पुष्टि की जा सकती है कि TLS/एसएसएल हैंडशेक के दौरान टाइम आउट हुआ या नहीं.

1. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो आपके पास बैकएंड सर्वर या मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट कैप्चर करने का विकल्प होता है. आम तौर पर, उन्हें बैकएंड सर्वर पर कैप्चर करें, क्योंकि पैकेट बैकएंड सर्वर पर डिक्रिप्ट होते हैं.
2. अगर आप पब्लिक क्लाउड उपयोगकर्ता हैं, तो आपके पास Message प्रोसेसर का ऐक्सेस नहीं है. हालांकि, बैकएंड सर्वर पर टीसीपी/आईपी पैकेट कैप्चर करने से, समस्या को पिन करने में मदद मिल सकती है.

3. टीसीपी/आईपी पैकेट को कैप्चर करने की जगह तय करने के बाद, टीसीपी/आईपी पैकेट कैप्चर करने के लिए, यहां दिए गए tcpdump कमांड का इस्तेमाल करें.

   tcpdump -i any -s 0 host <IP address> -w <File name>
   

   • अगर आपको बैकएंड सर्वर पर टीसीपी/आईपी पैकेट लेना है, तो tcpdump कमांड में मैसेज प्रोसेसर के सार्वजनिक आईपी पते का इस्तेमाल करें. बैकएंड सर्वर ट्रैफ़िक की जांच करने के निर्देश का इस्तेमाल करने में मदद पाने के लिए, tcpdump देखें.

   • अगर आपको Message प्रोसेसर पर टीसीपी/आईपी पैकेट लेना है, तो tcpdump कमांड में बैकएंड सर्वर के सार्वजनिक आईपी पते का इस्तेमाल करें. Message प्रोसेसर के ट्रैफ़िक की जांच करने के निर्देश का इस्तेमाल करने में मदद पाने के लिए, tcpdump देखें.

   • अगर बैकएंड सर्वर/मैसेज प्रोसेसर के लिए एक से ज़्यादा आईपी पते हैं, तो आपको tcpdump कमांड का एक और इस्तेमाल करके देखना होगा. इस टूल और इस कमांड के दूसरे वैरिएंट के बारे में ज़्यादा जानने के लिए, tcpdump देखें.

4. Wireshark टूल या इसी तरह के टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट का विश्लेषण करें. नीचे दिया गया स्क्रीनशॉट, Wireshark में टीसीपी/आईपी पैकेट दिखाता है.

   

5. वायर शार्क आउटपुट में ध्यान दें कि थ्री-वे टीसीपी हैंडशेक पहले तीन पैकेट में सफलता से पूरा हो जाता है.

6. इसके बाद, मैसेज प्रोसेसर पैकेट #4 में "क्लाइंट हैलो" मैसेज भेजता है.

7. बैकएंड सर्वर ने इसे स्वीकार नहीं किया, इसलिए मैसेज प्रोसेसर पहले से तय किए गए समय के अंतराल का इंतज़ार करने के बाद, "क्लाइंट हैलो" मैसेज को पैकेट 5, 6, और 7 में कई बार फिर से ट्रांसमिट करता है.

8. तीन बार कोशिश करने के बाद भी जब मैसेज प्रोसेसर को कोई पुष्टि नहीं मिलती है, तो यह बैकएंड सर्वर को एफ़आईएन, ACK मैसेज भेजता है. इससे यह पता चलता है कि मैसेज प्रोसेसर, कनेक्शन को बंद कर रहा है.

9. जैसा कि आपने Wireshark सेशन के उदाहरण में दिखाया है, बैकएंड से कनेक्शन हो गया (पहला कदम). हालांकि, एसएसएल हैंडशेक का समय खत्म हो गया, क्योंकि बैकएंड सर्वर ने कभी जवाब नहीं दिया.

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

किसी समस्या का पता लगाने के लिए, एपीआई मॉनिटरिंग का इस्तेमाल करना

एपीआई मॉनिटरिंग की मदद से, समस्या वाले क्षेत्रों को तुरंत अलग-अलग करके, गड़बड़ियों, परफ़ॉर्मेंस, और इंतज़ार के समय से जुड़ी समस्याओं और उनके सोर्स, जैसे कि डेवलपर ऐप्लिकेशन, एपीआई प्रॉक्सी, बैकएंड टारगेट या एपीआई प्लैटफ़ॉर्म का पता लगाया जा सकता है.

उदाहरण के तौर पर दिए गए उदाहरण को देखें जिसमें एपीआई मॉनिटरिंग का इस्तेमाल करके, एपीआई की 5xx समस्याओं को हल करने का तरीका बताया गया हो. उदाहरण के लिए, ऐसा हो सकता है कि आप एक सूचना सेट अप करना चाहें, ताकि जब messaging.adaptors.http.BadGateway गड़बड़ी की संख्या किसी खास थ्रेशोल्ड से ज़्यादा हो, तो आपको इसकी सूचना दी जाए.

रिज़ॉल्यूशन

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

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

अगर फ़ायरवॉल की कोई पाबंदी नहीं है और/या समस्या अब भी बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

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

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

1. अगर आप Public Cloud का इस्तेमाल करते हैं, तो यह जानकारी दें:
   1. संगठन का नाम
   2. एनवायरमेंट का नाम
   3. एपीआई प्रॉक्सी का नाम
   4. गड़बड़ी को फिर से सामने लाने के लिए कर्ल कमांड पूरा करें
   5. ट्रेस फ़ाइल की गड़बड़ी दिखा रही है
   6. बैकएंड सर्वर पर कैप्चर किए गए टीसीपी/आईपी पैकेट
2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
   1. पूरा गड़बड़ी का मैसेज देखा गया
   2. एपीआई प्रॉक्सी बंडल
   3. ट्रेस फ़ाइल की गड़बड़ी दिखा रही है
   4. मैसेज प्रोसेसर के लॉग /opt/apigee/var/log/edge-message-processor/logs/system.log
   5. बैकएंड सर्वर या मैसेज प्रोसेसर पर कैप्चर किए गए टीसीपी/आईपी पैकेट.
3. इस प्लेबुक में मौजूद उन सेक्शन के बारे में जानकारी जिन्हें आपने आज़माया है. साथ ही, ऐसी अन्य अहम जानकारी जो इस समस्या को तेज़ी से हल करने में हमारी मदद करेगी.