502 खराब गेटवे

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

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

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के रिस्पॉन्स के तौर पर, "खराब गेटवे" मैसेज के साथ 502 का एचटीटीपी स्टेटस कोड मिलता है.

एचटीटीपी स्टेटस कोड 502 का मतलब है कि क्लाइंट को बैकएंड सर्वर से मान्य रिस्पॉन्स नहीं मिल रहा है. ये रिस्पॉन्स सर्वर, अनुरोध को पूरा करते हैं.

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

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

HTTP/1.1 502 Bad Gateway

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

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

अगर गड़बड़ी बैकएंड सर्वर से आती है, तो आपको कुछ ऐसा दिख सकता है. बैकएंड से मिलने वाला गड़बड़ी का मैसेज पूरी तरह से इसके लागू होने पर निर्भर करता है. 

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

संभावित वजहें

यहां पर ऐसी कुछ संभावित वजहों के बारे में बताया गया है जिनकी वजह से, Apigee Edge से गुज़रने वाले एपीआई के लिए 502 बैड गेटवे की गड़बड़ी हो सकती है:

Cause Description समस्या हल करने वाले निर्देश इन पर लागू होते हैं
पूल में कोई एमपी उपलब्ध नहीं है यह गड़बड़ी तब दिखती है, जब पूल में मौजूद सभी एमपी उपलब्ध नहीं होते, यानी कि वे या तो काम नहीं कर रहे या व्यस्त होने की वजह से कोई जवाब नहीं दे रहा हो. Edge Private Cloud के उपयोगकर्ता
राउटर और एमपी के बीच गलत एसएसएल कॉन्फ़िगरेशन यह गड़बड़ी तब दिखती है, जब Edge के राऊटर के ट्रस्टस्टोर में क्लाइंट के CA से साइन किया गया रूट सर्टिफ़िकेट मौजूद न हो. Edge Private Cloud के उपयोगकर्ता
बैकएंड सर्वर में गड़बड़ी यह गड़बड़ी तब दिखेगी, जब बैकएंड सर्वर काम नहीं करेगा और यह रिस्पॉन्स भेज देगा. Edge Public और Private Cloud उपयोगकर्ता

वजह: पूल में कोई एमपी उपलब्ध नहीं है

यह गड़बड़ी तब होती है, जब राऊटर को पता चलता है कि दिए गए क्षेत्र/डेटा सेंटर में सभी मैसेज प्रोसेसर उपलब्ध नहीं हैं (उदाहरण के लिए, अगर वे सभी काम नहीं कर रहे हों).

Apigee Edge को इस तरह से कॉन्फ़िगर किया गया है कि किसी दिए गए क्षेत्र/डेटा सेंटर में आने वाले एपीआई ट्रैफ़िक (अनुरोध) को हमेशा, उसी क्षेत्र/डेटा सेंटर के राऊटर से मैसेज प्रोसेसर (MPs) में रूट किया जाता है. कुछ मामलों में, Apigee Edge के कॉम्पोनेंट, सिर्फ़ एक क्षेत्र/डेटा सेंटर में सेटअप किए जा सकते हैं और कुछ मामलों में, एक से ज़्यादा क्षेत्र/डेटा सेंटर में सेटअप किए जा सकते हैं. हर इलाके/डेटा सेंटर में, दो या उससे ज़्यादा राऊटर और मैसेज प्रोसेसर कॉन्फ़िगर किए जाएंगे.

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

  1. अगर एक से ज़्यादा क्षेत्र/डेटा सेंटर हैं, तो उन क्षेत्र/डेटा सेंटर का पता लगाएं जिनमें एपीआई अनुरोध, 502 बैड गेटवे की गड़बड़ी की वजह से फ़ेल हो रहे हैं. इसे ढूंढने के लिए, उस इलाके की पहचान करें जहां उपयोगकर्ता 502 की गड़बड़ियां देख रहे हैं या फिर अलग-अलग इलाकों से जुड़े हर राऊटर के लिए, /opt/apigee/var/log/edge-router/nginx/ डायरेक्ट्री में NGINX ऐक्सेस लॉग देखें.
  2. आपको NGINX गड़बड़ी लॉग (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log) में यह गड़बड़ी दिखेगी
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

स्थिति 1: सभी मैसेज प्रोसेसर काम नहीं कर रहे हैं

  1. देखें कि क्या किसी खास इलाके/डेटा सेंटर में, मैसेज प्रोसेसर चालू हैं और काम कर रहे हैं.
  2. अगर सभी मैसेज प्रोसेसर काम नहीं कर रहे हैं, तो उन्हें रीस्टार्ट करें.

रिज़ॉल्यूशन

नीचे दिए गए निर्देश का इस्तेमाल करके सभी मैसेज प्रोसेसर को रीस्टार्ट करें:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

स्थिति 2: सभी संदेश प्रोसेसर जारी अनुरोधों को प्रोसेस करने में व्यस्त हैं

यह गड़बड़ी तब होती है, जब राऊटर को पता चलता है कि दिए गए क्षेत्र/डेटा सेंटर में सभी मैसेज प्रोसेसर उपलब्ध नहीं हैं, क्योंकि वे सभी जारी अनुरोधों को प्रोसेस कर रहे हैं.

  1. देखें कि क्या किसी खास इलाके/डेटा सेंटर में, मैसेज प्रोसेसर चालू हैं और काम कर रहे हैं.
  2. अगर सभी मैसेज प्रोसेसर चालू हैं और चालू हैं, तो देखें कि क्या मैसेज प्रोसेसर का सीपीयू ज़्यादा इस्तेमाल हो रहा है. इसके बाद, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करने के लिए, इस निर्देश का इस्तेमाल करें:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. अगर मैसेज प्रोसेसर के लिए मेमोरी का ज़्यादा इस्तेमाल हो रहा है, तो यहां दिए गए निर्देश का इस्तेमाल करके हीप डंप जनरेट करें:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू और मेमोरी भी काम नहीं करेगी:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. एपीआई कॉल पर नज़र रखें, ताकि यह पक्का किया जा सके कि समस्या अब भी मौजूद है या नहीं.
  6. Apigee सहायता से संपर्क करें. साथ ही, सीपीयू/मेमोरी के ज़्यादा इस्तेमाल की वजह का पता लगाने के लिए, थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) की जानकारी दें.

वजह: राऊटर और एमपी के बीच गलत एसएसएल कॉन्फ़िगरेशन

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

  1. NGINX ऐक्सेस लॉग (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log) की जांच करें. आपको 502 रिस्पॉन्स दिखेगा, जैसा कि यहां दिखाया गया है:
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. NGINX गड़बड़ी लॉग (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log) की जांच करें. आपको इस तरह की गड़बड़ियां दिखेंगी:
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. यह दिखाता है कि राऊटर और मैसेज प्रोसेसर के बीच एसएसएल हैंडशेक काम नहीं करता.
  4. अगर आपको चरण #1 और #2 में गड़बड़ी का मैसेज ध्यान से दिखता है, तो मैसेज प्रोसेसर से संपर्क करने के लिए इस्तेमाल किया जाने वाला पोर्ट # 8998 है. यह एक असुरक्षित पोर्ट है, लेकिन प्रोटोकॉल एसएसएल (https) है. आम तौर पर, इस्तेमाल होने वाला सुरक्षित पोर्ट # 8443 होता है. गैर-सुरक्षित पोर्ट का इस्तेमाल सुरक्षित कम्यूनिकेशन के लिए किया जाता है, इसलिए इससे एसएसएल हैंडशेक काम नहीं करता.
  5. आम तौर पर ऐसा तब हो सकता है, जब राऊटर और मैसेज प्रोसेसर के बीच एसएसएल कॉन्फ़िगर करते समय कोई चरण छूट गया हो या गलत वैल्यू सेट की गई हो. यहां दिया गया तरीका देखें.
    उदाहरण के लिए, यह गड़बड़ी तब हो सकती है, जब
    1. /opt/apigee/customer/application/message-processor.properties as shown below में, पोर्ट # को 8443 के बजाय 8998 के तौर पर दिखाया गया है
              conf/message-processor-communication.properties+local.http.port=8998
    2. /opt/nginx/conf.d/* डायरेक्ट्री में राऊटर कॉन्फ़िगरेशन फ़ाइलें मिटाई नहीं जाती हैं और एसएसएल कॉन्फ़िगरेशन करते समय राऊटर को रीस्टार्ट नहीं किया गया है. इस स्थिति में, यह देखा जा सकता है कि कॉन्फ़िगरेशन फ़ाइलों में Message प्रोसेसर का पोर्ट# 8998 बना रहेगा.

रिज़ॉल्यूशन

  1. पक्का करें कि राउटर और मैसेज प्रोसेसर के बीच TLS को कॉन्फ़िगर करने में दिए गए सभी चरणों का ठीक से पालन किया गया है.
  2. अगर समस्या बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करें पर जाएं.

वजह: बैकएंड सर्वर में गड़बड़ी हुई

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

  1. अगर गड़बड़ी हर बार होती है, तो काम न करने वाले अनुरोधों के लिए यूज़र इंटरफ़ेस (यूआई) ट्रेस को कैप्चर किया जा सकता है. ऐसा अनुरोध चुनें जो काम न कर रहा हो और ट्रेस के अलग-अलग चरणों में नेविगेट करें. अगर आपको बैकएंड सर्वर से ही “502 बैड गेटवे” मिलता है, तो हो सकता है कि बैकएंड सर्वर में कुछ गड़बड़ी हुई हो.
    ट्रेस, जो 502 बैड गेटवे दिखा रहा है, जो बैकएंड सर्वर से आ रहा है
  2. अगर समस्या बार-बार होती है और ट्रेस कैप्चर नहीं हो पा रहे हैं, तो
    1. अगर आप 'सार्वजनिक क्लाउड' के उपयोगकर्ता हैं, तो एपीआई मॉनिटरिंग का इस्तेमाल करके, 502 गड़बड़ियों की जानकारी देखें.
      1. अगर आपको पता चलता है कि फ़ॉल्ट कोड messaging.adaptors.http.flow.ErrorResponseCode है और फ़ॉल्ट सोर्स target है, तो यह गड़बड़ी बैकएंड सर्वर से होती है.
    2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो आपके पास NGINX ऐक्सेस लॉग का विश्लेषण करने का विकल्प है
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      आपको फ़ेल हुए अनुरोध की एंट्री इस तरह दिखेगी:
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. अगर आपको पता चलता है कि फ़ॉल्ट कोड messaging.adaptors.http.flow.ErrorResponseCode है और फ़ॉल्ट सोर्स target है, तो यह गड़बड़ी बैकएंड सर्वर से होती है.

रिज़ॉल्यूशन

  1. बैकएंड में इस समस्या को ठीक करने के लिए, अपनी बैकएंड सर्वर टीम के साथ काम करें.

गड़बड़ी की जानकारी इकट्ठा करें

  1. NGINX ऐक्सेस लॉग
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    और गड़बड़ी के लॉग
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
  2. मैसेज प्रोसेसर के लॉग
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).