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

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

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

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

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

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

HTTP/1.1 502 Bad Gateway

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

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

संभावित वजह

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

वजह: TLS/SSL हैंडशेक का टाइम आउट होना

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

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

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

इस सेक्शन में, TLS/SSL हैंडशेक के टाइम आउट होने की समस्या का सही तरीके से पता लगाने का तरीका बताया गया है. इसमें Edge Private Cloud और Public Cloud के लिए निर्देश दिए गए हैं.

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

Apigee Edge के ट्रेस टूल का इस्तेमाल करके, समस्या का शुरुआती तौर पर पता लगाने का तरीका यहां बताया गया है.

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

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

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

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

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

         

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

यह पुष्टि करने के लिए कि गड़बड़ी की वजह TLS/SSL हैंडशेक का टाइम आउट होना है, Public Cloud या Private Cloud का इस्तेमाल करने के आधार पर, यहां दिए गए सेक्शन में बताया गया तरीका अपनाएं.

सिर्फ़ Edge Private Cloud के उपयोगकर्ताओं के लिए, समस्या की जानकारी पाने का अतिरिक्त तरीका

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

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

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

      telnet BackendServer-IPaddress 443

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

      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 Private और Public Cloud के उपयोगकर्ताओं के लिए, समस्या की जानकारी पाने का अतिरिक्त तरीका पर जाएं.

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

Edge Private और Public Cloud के उपयोगकर्ताओं के लिए, समस्या की जानकारी पाने का अतिरिक्त तरीका

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

रिज़ॉल्यूशन

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

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

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

समस्या की जानकारी पाने के लिए ज़रूरी जानकारी इकट्ठा करना

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

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