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

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

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

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

दूसरी स्थिति: सभी मैसेज प्रोसेसर, चल रहे अनुरोधों को प्रोसेस करने में व्यस्त हैं

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

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

रिज़ॉल्यूशन

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

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

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

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