502 खराब गेटवे

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

पर क्लिक करें.

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

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

एचटीटीपी स्टेटस कोड 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 Bad Gateway गड़बड़ी होने की कुछ संभावित वजहें यहां दी गई हैं:

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

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

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

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

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

  1. अगर एक से ज़्यादा क्षेत्र/डेटा सेंटर हैं, तो यह पता लगाएं कि किस क्षेत्र/डेटा सेंटर में एपीआई के अनुरोध पूरे नहीं हो रहे हैं. ऐसा 502 Bad Gateway गड़बड़ी की वजह से हो रहा है. इसके लिए, आपको यह पता लगाना होगा कि उपयोगकर्ताओं को किस इलाके में 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. देखें कि किसी खास इलाके/डेटा सेंटर में मैसेज प्रोसेसर काम कर रहे हैं या नहीं.
  2. अगर सभी मैसेज प्रोसेसर बंद हैं, तो उन्हें फिर से चालू करें.

रिज़ॉल्यूशन

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

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

दूसरा उदाहरण: सभी मैसेज प्रोसेसर, मौजूदा अनुरोधों को प्रोसेस करने में व्यस्त हैं

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

  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. अगर आपने पहले और दूसरे चरण में गड़बड़ी के मैसेज को ध्यान से देखा है, तो आपको पता चलेगा कि मैसेज प्रोसेसर से कम्यूनिकेट करने के लिए पोर्ट # 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/* डायरेक्ट्री में मौजूद राऊटर की कॉन्फ़िगरेशन फ़ाइलें नहीं मिटाई जाती हैं. साथ ही, राऊटर को रीस्टार्ट नहीं किया जाता है. इस स्थिति में, आपको पता चलेगा कि कॉन्फ़िगरेशन फ़ाइलों में मैसेज प्रोसेसर का पोर्ट# 8998 ही रहेगा.

रिज़ॉल्यूशन

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

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

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

  1. अगर यह गड़बड़ी हर बार होती है, तो गड़बड़ी वाले अनुरोधों के लिए यूज़र इंटरफ़ेस (यूआई) ट्रेस कैप्चर करें. अनुरोध पूरा न होने की वजह चुनें और ट्रेस में अलग-अलग फ़ेज़ पर जाएं. अगर आपको बैकएंड सर्वर से ही “502 Bad Gateway” गड़बड़ी का मैसेज मिलता है, तो हो सकता है कि बैकएंड सर्वर में कोई समस्या हुई हो.
    बैकएंड सर्वर से आ रही 502 गड़बड़ी वाले गेटवे को दिखाने वाला ट्रेस
  2. अगर समस्या कभी-कभी होती है और आपको ट्रेस कैप्चर करने में परेशानी आ रही है, तो
    1. अगर आप Public Cloud के उपयोगकर्ता हैं, तो एपीआई मॉनिटरिंग का इस्तेमाल करें. साथ ही, 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).