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/SSL हैंडशेक टाइम आउट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण के तौर पर दिए गए किसी उदाहरण को देखना जो एपीआई मॉनिटरिंग का इस्तेमाल करके, आपके एपीआई की 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. इस Playbook के किन सेक्शन को आज़माया गया है. साथ ही, ऐसी कोई भी अहम जानकारी जो इस समस्या को जल्द से जल्द हल करने में हमारी मदद कर सके.