502 गलत गेटवे - सॉकेट बंद करें

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

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

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

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

क्लाइंट को यह रिस्पॉन्स कोड दिखेगा: 

HTTP/1.1 502 Bad Gateway

जवाब में नीचे दिया गया गड़बड़ी का मैसेज शामिल होगा: 

{"message":"socket hang up","code":"ECONNRESET"}

संभावित कारण

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

निदान के सामान्य चरण

  1. एज माइक्रोगेटवे लॉग की जांच करें: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. यह देखें कि किसी खास अवधि के दौरान (अगर यह समस्या पहले हुई है) कोड ECONNRESET के साथ 502 की गड़बड़ी तो नहीं मिली है या 502 से जुड़े ऐसे अनुरोध हैं जो अब भी पूरे नहीं हो रहे हैं. 
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
[emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
[microgateway-core][][GET][502][socket hang up][ECONNRESET][]
  3. अगर आपने लॉगिंग लेवल को warn या info पर सेट किया है, तो एक [warn] मैसेज भी दिखेगा. इसमें टारगेट सर्वर के होस्टनेम और दूसरे एलिमेंट में पोर्ट शामिल होगा. इस उदाहरण में, यह X.X.X.X:8080 है और इसे बाद में tcpdump को कैप्चर करने के लिए इस्तेमाल किया जा सकता है. 
    2021-06-23T03:52:24.109Z
[warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
[][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
[targetRequest error][GET][][socket hang up][ECONNRESET][395]
  4. गड़बड़ी कोड [socket hang up][ECONNRESET] से पता चलता है कि टारगेट सर्वर ने Edge माइक्रोगेटवे के साथ कनेक्शन बंद कर दिया है. इस गड़बड़ी को लॉग में खोजा जा सकता है, ताकि यह पता लगाया जा सके कि ऐसा कितनी बार होता है.

वजह: कीप-अलाइव (चालू रखें) के टाइम आउट को गलत तरीके से कॉन्फ़िगर किया गया है

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

  1. गड़बड़ी की जानकारी के सामान्य तरीके में दिए गए तरीके का इस्तेमाल करें और पुष्टि करें कि आपको [socket hang up][ECONNRESET] गड़बड़ी मिली है या नहीं.

  2. अगर हां, तो tcpdump की मदद से आगे की जांच करें. इसके बारे में यहां बताया गया है:

tcpdump का इस्तेमाल करना

  1. इस निर्देश की मदद से, Edge माइक्रोगेटवे होस्ट ऑपरेटिंग सिस्टम पर Edge माइक्रोगेटवे और बैकएंड सर्वर के बीच tcpdump कैप्चर करें: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. कैप्चर किए गए tcpdump का विश्लेषण करें:

    tcpdump आउटपुट का सैंपल: ( बड़ी इमेज देखें)

    ऊपर दिए गए सैंपल tcpdump में, आपको यह जानकारी दिखती है:

    1. पैकेट 250288 में, क्लाइंट POST अनुरोध भेजता है.
    2. पैकेट 250371 में, सर्वर 200 OK के साथ जवाब देता है.
    3. पैकेट 250559 में, क्लाइंट एक ACK. भेजता है
    4. पैकेट 250560 में, सर्वर Continuation मैसेज भेजता है.
    5. पैकेट 250561 में, क्लाइंट एक ACK. भेजता है
    6. पैकेट 262436 में, सर्वर, क्लाइंट को कनेक्शन बंद करने के लिए, एक FIN, ACK भेजता है. ध्यान दें कि यह पिछले पैकेट (250561) के करीब पांच सेकंड बाद का समय है.
    7. पैकेट 262441 में, क्लाइंट एक और POST अनुरोध भेजता है. हालांकि, ऐसा नहीं हो पाता, क्योंकि सर्वर ने पहले ही कनेक्शन बंद करना शुरू कर दिया है. यह पैकेट में RST के साथ 262441 जवाब देता है.

    इस उदाहरण में एक ही कनेक्शन को कम से कम एक बार फिर से इस्तेमाल किया गया था. हालांकि, आखिरी बार अनुरोध करने पर सर्वर पांच सेकंड के कुछ समय बाद, कनेक्शन बंद करने की प्रोसेस शुरू कर देता है. ऐसा तब होता है, जब क्लाइंट ने नया अनुरोध भेजा था. इससे, पता चलता है कि बैकएंड सर्वर कीप-अलाइव स्ट्रीमिंग के लिए, टाइम आउट की अवधि, क्लाइंट में सेट की गई वैल्यू से कम या उसके बराबर होती है. इसकी पुष्टि करने के लिए, Edge माइक्रोगेटवे और बैकएंड सर्वर पर, कीप अलाइव टाइम आउट की तुलना करना देखें.

कीप-अलाइव (चालू रखें) टाइम आउट की तुलना करें

  1. एज माइक्रोगेटवे में कोई खास कीप-अलाइव टाइम प्रॉपर्टी नहीं है. यह उस ऑपरेटिंग सिस्टम से तय होता है जिस पर यह काम कर रहा है. इसके सामान्य उदाहरण Windows, Linux, और Docker कंटेनर हैं.
  2. ऐसा भी हो सकता है कि इसे ऑपरेटिंग सिस्टम में पसंद के मुताबिक बनाया गया हो. अपने सिस्टम एडमिन से संपर्क करें. डिफ़ॉल्ट रूप से, Linux ऑपरेटिंग सिस्टम में कीप-अलाइव (चालू रखें) के लिए डिफ़ॉल्ट तौर पर दो घंटे का टाइम आउट होता है.
  3. इसके बाद, अपने बैकएंड सर्वर पर कॉन्फ़िगर की गई कीप-अलाइव टाइम आउट प्रॉपर्टी देखें. मान लें कि आपका बैकएंड सर्वर 10 सेकंड की वैल्यू के साथ कॉन्फ़िगर किया गया है.
  4. अगर आपको पता चलता है कि ऑपरेटिंग सिस्टम पर कीप-अलाइव टाइम आउट की वैल्यू, बैकएंड सर्वर पर कीप-अलाइव टाइम आउट प्रॉपर्टी की वैल्यू से ज़्यादा है, तो इसी वजह से 502 गड़बड़ियां होती हैं.

रिज़ॉल्यूशन

यह पक्का करें कि ऑपरेटिंग सिस्टम पर कीप-अलाइव टाइम आउट प्रॉपर्टी हमेशा कम हो, जहां Edge सर्वर की तुलना में Edge माइक्रोगेटवे चल रहा हो.

  1. बैकएंड सर्वर पर कीप-अलाइव टाइम आउट के लिए सेट की गई वैल्यू तय करें.
  2. ऑपरेटिंग सिस्टम में कीप-अलाइव टाइम आउट प्रॉपर्टी के लिए कोई सही वैल्यू कॉन्फ़िगर करें. जैसे, कीप-अलाइव टाइम आउट प्रॉपर्टी की वैल्यू, बैकएंड सर्वर पर सेट की गई वैल्यू से कम हो. इसके लिए, उन तरीकों का इस्तेमाल करें जो आपके ऑपरेटिंग सिस्टम पर लागू होते हैं.

सबसे सही तरीका

यह सलाह दी जाती है कि इस तरह की नस्ल की स्थितियों और 502 गड़बड़ियों से बचने के लिए, डाउनस्ट्रीम कॉम्पोनेंट के लिए हमेशा बनाए रखने की टाइम आउट की सीमा, अपस्ट्रीम सर्वर पर कॉन्फ़िगर किए गए टाइम आउट की संख्या के मुकाबले कम होती है. हर डाउनस्ट्रीम हॉप की वैल्यू, हर अपस्ट्रीम हॉप से कम होनी चाहिए. एज माइक्रोगेटवे में, इन दिशा-निर्देशों का इस्तेमाल करना बेहतर है:

  1. क्लाइंट ऐप्लिकेशन या लोड बैलेंसर के लिए कीप-अलाइव टाइम आउट, Edge माइक्रोगेटवे कीप-अलाइव टाइम आउट से कम होना चाहिए.

    Edge माइक्रोगेटवे पर कीप-अलाइव टाइम आउट को कॉन्फ़िगर करने के लिए, अपनी ~/.edgemicro/org-env-config.yaml फ़ाइल में keep_alive_timeout वैल्यू जोड़ें.

    edgemicro:
  keep_alive_timeout: 65000
  2. Edge माइक्रोगेटवे ऑपरेटिंग सिस्टम की-अलाइव स्ट्रीमिंग टाइम आउट, टारगेट सर्वर कीप-अलाइव टाइम आउट से कम होना चाहिए.
  3. अगर आपके पास एज माइक्रोगेटवे के आगे या पीछे कोई और हॉप है, तो वही नियम लागू करना चाहिए. अपस्ट्रीम के साथ कनेक्शन बंद करने की ज़िम्मेदारी आपको हमेशा डाउनस्ट्रीम क्लाइंट की ज़िम्मेदारी के तौर पर देनी चाहिए.

वजह: टारगेट सर्वर, कनेक्शन को समय से पहले बंद कर देता है

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

  1. गड़बड़ी की जानकारी के सामान्य तरीके में बताए गए तरीके का इस्तेमाल करें और पुष्टि करें कि आपको [socket hang up][ECONNRESET] गड़बड़ी हुई है या नहीं.
  2. अगर हां, तो tcpdump की मदद से आगे की जांच करें. इसके बारे में नीचे बताया गया है.

    ऊपर दिए गए उदाहरण में गड़बड़ी का मैसेज [targetRequest error][GET][][socket hang up][ECONNRESET] बताता है कि यह गड़बड़ी तब हुई, जब Edge माइक्रोगेटवे बैकएंड (टारगेट) सर्वर को अनुरोध भेज रहा था. इसका मतलब है कि Edge Microgateway ने एपीआई अनुरोध को बैकएंड सर्वर पर भेजा था. यह अनुरोध रिस्पॉन्स का इंतज़ार कर रहा था. हालांकि, Edge माइक्रोगेटवे से जवाब मिलने से पहले ही बैकएंड सर्वर ने कनेक्शन को अचानक बंद कर दिया.

  3. अपने बैकएंड सर्वर लॉग की जांच करें और देखें कि क्या उसमें ऐसी कोई गड़बड़ी या जानकारी है जिसकी वजह से बैकएंड सर्वर, कनेक्शन को अचानक बंद कर सकता है. अगर आपको कोई गड़बड़ी या जानकारी मिलती है, तो रिज़ॉल्यूशन पर जाएं और अपने बैकएंड सर्वर में समस्या को सही तरीके से ठीक करें.
  4. अगर आपको अपने बैकएंड सर्वर में कोई गड़बड़ी या जानकारी नहीं मिलती है, तो Edge माइक्रोगेटवे सर्वर पर tcpdump आउटपुट इकट्ठा करें: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. कैप्चर किए गए tcpdump का विश्लेषण करें:

    tcpdump आउटपुट का सैंपल: ( बड़ी इमेज देखें)

    ऊपर दिए गए सैंपल tcpdump में, आपको यह जानकारी दिखती है:

    1. पैकेट 4 में, Edge Microgateway ने टारगेट सर्वर को एक GET अनुरोध भेजा.
    2. पैकेट 5 में, टारगेट सर्वर ने अनुरोध को स्वीकार करने के लिए ACK का जवाब दिया.
    3. हालांकि, पैकेट 6 में, रिस्पॉन्स पेलोड के साथ जवाब देने के बजाय, टारगेट सर्वर कनेक्शन को बंद करने के लिए FIN, ACK भेजता है.
    4. पैकेट 7 के बाद से, कनेक्शन आपस में बंद हो जाता है. रिस्पॉन्स भेजने से पहले कनेक्शन बंद कर दिया गया था. इसलिए, Edge माइक्रोगेटवे क्लाइंट को एचटीटीपी 502 गड़बड़ी वापस कर देगा.
    5. ध्यान दें कि पैकेट 8 का टाइमस्टैंप, 2021-06-23T03:52:24.110Z उस टाइमस्टैंप के मुताबिक होता है जिस पर एज माइक्रोगेटवे लॉग में गड़बड़ी को लॉग किया गया था. लॉग फ़ाइलों और tcpdump में मौजूद टाइमस्टैंप का इस्तेमाल, गड़बड़ियों को असल पैकेट के साथ जोड़ने के लिए किया जा सकता है.

    रिज़ॉल्यूशन

    बैकएंड सर्वर पर सही तरीके से समस्या को ठीक करें.

    अगर समस्या बनी रहती है और आपको 502 Bad Gateway Error को हल करने में मदद चाहिए या आपको लगता है कि यह समस्या Edge माइक्रोगेटवे में है, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

    ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी जानकारी इकट्ठा करनी होगी

    अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो गड़बड़ी से जुड़ी यह जानकारी इकट्ठा करें. इसके बाद, Apigee Edge की सहायता टीम से संपर्क करें:

    • लॉग फ़ाइलें: डिफ़ॉल्ट फ़ोल्डर /var/tmp है, लेकिन मुख्य config.yaml फ़ाइल (logging > dir parameter) में इसे बदला जा सकता है. हमारा सुझाव है कि Apigee सहायता को लॉग फ़ाइलें उपलब्ध कराने से पहले, log > level को बदलकर info कर दें.
    • कॉन्फ़िगरेशन फ़ाइल: Edge माइक्रोगेटवे का मुख्य कॉन्फ़िगरेशन, डिफ़ॉल्ट Edge माइक्रोगेटवे फ़ोल्डर में YAML फ़ाइल में मौजूद है, $HOME/.edgemicro. इसमें default.yaml नाम की एक डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल होती है. इसके बाद, हर एनवायरमेंट ORG-ENV-config.yaml के लिए एक फ़ाइल मौजूद होती है. जिस संगठन और एनवायरमेंट पर असर पड़ा है उसके लिए, कृपया इस फ़ाइल को पूरा अपलोड करें.