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/SSL हैंडशेक के दौरान टाइम आउट होता है.	Edge Private और Public Cloud के उपयोगकर्ता

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

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

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

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

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

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

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

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

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

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

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

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

         

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

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

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

अगर आपने Apigee Edge Private Cloud का इस्तेमाल किया है, तो हैंडशेक से जुड़ी गड़बड़ी की वजह की पुष्टि करने के लिए, यह तरीका अपनाएं. इस चरण में, काम की जानकारी के लिए मैसेज प्रोसेसर की लॉग फ़ाइल की जांच की जाती है. अगर आप Edge 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. अगर आप निजी क्लाउड उपयोगकर्ता हैं, तो आपके पास बैकएंड सर्वर या मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट कैप्चर करने का विकल्प है. बेहतर होगा कि उन्हें बैकएंड सर्वर पर कैप्चर करें, क्योंकि पैकेट को बैकएंड सर्वर पर डिक्रिप्ट किया जाता है.
2. अगर आप सार्वजनिक क्लाउड उपयोगकर्ता हैं, तो आपके पास मैसेज प्रोसेसर का ऐक्सेस नहीं है. हालांकि, बैकएंड सर्वर पर टीसीपी/आईपी पैकेट कैप्चर करने से, किसी समस्या का पता लगाने में मदद मिल सकती है.

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. जब तीन बार कोशिश करने के बाद, मैसेज प्रोसेसर को कोई मैसेज नहीं मिलता है, तो वह बैकएंड सर्वर को एफ़आईएन, एसीके मैसेज भेजता है. इस मैसेज से पता चलता है कि वह कनेक्शन बंद कर रहा है.

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

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