499 क्लाइंट के लिए कनेक्शन बंद किया गया

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

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

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

आपको एपीआई मॉनिटरिंग और NGINX ऐक्सेस लॉग में, ऐसे एपीआई अनुरोधों के लिए स्टेटस कोड 499 दिखेगा. कभी-कभी, आपको एपीआई Analytics में अलग-अलग स्टेटस कोड दिखेंगे, क्योंकि यह मैसेज प्रोसेसर से मिले स्टेटस कोड को दिखाता है.

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

क्लाइंट ऐप्लिकेशन को इस तरह की गड़बड़ियां दिख सकती हैं: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

क्लाइंट टाइमआउट की वजह क्या होती है?

Edge प्लैटफ़ॉर्म पर एपीआई अनुरोध का सामान्य पाथ यह होता है: क्लाइंट > राउटर > मैसेज प्रोसेसर > बैकएंड सर्वर. इसे यहां दिए गए डायग्राम में दिखाया गया है:

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

क्लाइंट पर टाइम आउट

क्लाइंट ऐप्लिकेशन को, आपकी ज़रूरतों के हिसाब से टाइम आउट की सही वैल्यू के साथ कॉन्फ़िगर किया जा सकता है.

वेब ब्राउज़र और मोबाइल ऐप्लिकेशन जैसे क्लाइंट के लिए, ऑपरेटिंग सिस्टम टाइमआउट तय करता है.

राऊटर पर टाइम आउट

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

मैसेज प्रोसेसर का टाइम आउट हो गया है

मैसेज प्रोसेसर पर कॉन्फ़िगर किया गया डिफ़ॉल्ट टाइमआउट 55 सेकंड है. यह वह ज़्यादा से ज़्यादा समय है जो बैकएंड सर्वर, अनुरोध को प्रोसेस करने और Message Processor को जवाब देने में ले सकता है. मैसेज प्रोसेसर या एपीआई प्रॉक्सी में डिफ़ॉल्ट टाइम आउट को बदला जा सकता है. इसके बारे में मैसेज प्रोसेसर पर I/O टाइम आउट कॉन्फ़िगर करना लेख में बताया गया है.

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

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

Edge में, 499 Client Closed Connection गड़बड़ी होने की आम वजहें ये हैं:

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

गड़बड़ी का पता लगाने के सामान्य चरण

इस गड़बड़ी का पता लगाने के लिए, इनमें से किसी टूल/तकनीक का इस्तेमाल करें:

  • एपीआई मॉनिटरिंग
  • NGINX ऐक्सेस लॉग

एपीआई मॉनिटरिंग

एपीआई मॉनिटरिंग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:

  1. विश्लेषण करें > एपीआई मॉनिटरिंग > जांच करें पेज पर जाएं.
  2. 4xx गड़बड़ियों के लिए फ़िल्टर करें और समयावधि चुनें.
  3. टाइम के हिसाब से स्टेटस कोड का प्लॉट बनाएं.
  4. उस सेल को चुनें जिसमें 499 गड़बड़ियां हैं. जैसा कि यहां दिखाया गया है:

  5. आपको दाईं ओर मौजूद पैनल में, 499 गड़बड़ी के बारे में जानकारी दिखेगी. यह जानकारी यहां दी गई है:

  6. दाईं ओर मौजूद पैनल में, लॉग देखें पर क्लिक करें.

    ट्रैफ़िक लॉग विंडो में, 499 गड़बड़ियों के बारे में यहां दी गई जानकारी नोट करें:

    • अनुरोध:इससे कॉल करने के लिए इस्तेमाल किए गए अनुरोध के तरीके और यूआरआई की जानकारी मिलती है
    • जवाब का समय:इससे अनुरोध पूरा होने में लगने वाले कुल समय के बारे में पता चलता है.

    एपीआई मॉनिटरिंग GET logs API का इस्तेमाल करके भी सभी लॉग पाए जा सकते हैं. उदाहरण के लिए, org, env, timeRange, और status के लिए लॉग क्वेरी करके, उन सभी लेन-देन के लॉग डाउनलोड किए जा सकते हैं जिनमें क्लाइंट का सेशन खत्म हो गया था.

    एपीआई मॉनिटरिंग, HTTP 499 गड़बड़ियों के लिए प्रॉक्सी को - पर सेट करती है. इसलिए, एपीआई (Logs API) का इस्तेमाल करके, वर्चुअल होस्ट और पाथ के लिए प्रॉक्सी का पता लगाया जा सकता है.

    उदाहरण के लिए : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. अन्य 499 गड़बड़ियों के लिए, जवाब देने में लगने वाला समय देखें. साथ ही, यह देखें कि सभी 499 गड़बड़ियों के लिए, जवाब देने में लगने वाला समय एक जैसा है या नहीं. उदाहरण के लिए, 30 सेकंड.

NGINX ऐक्सेस लॉग

NGINX ऐक्सेस लॉग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:

  1. अगर आप Private Cloud का इस्तेमाल करते हैं, तो NGINX ऐक्सेस लॉग का इस्तेमाल करके, एचटीटीपी 499 गड़बड़ियों के बारे में अहम जानकारी पाई जा सकती है.
  2. NGINX के ऐक्सेस लॉग देखें:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. खोजें कि क्या किसी खास अवधि के दौरान 499 गड़बड़ियां हुई हैं (अगर समस्या पहले हुई थी) या क्या अब भी 499 गड़बड़ियां हो रही हैं.
  4. 499 गड़बड़ियों के बारे में यहां दी गई जानकारी का ध्यान रखें:
    • जवाब देने में लगने वाला कुल समय
    • अनुरोध URI
    • उपयोगकर्ता एजेंट

    NGINX के ऐक्सेस लॉग से, 499 कोड वाली गड़बड़ी का नमूना: 

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    इस उदाहरण के लिए, हमें यह जानकारी दिखती है:

    • जवाब देने में लगा कुल समय: 10.001 सेकंड. इससे पता चलता है कि क्लाइंट का टाइम आउट 10.001 सेकंड के बाद हुआ
    • अनुरोध: GET /v1/products
    • होस्ट:api.acme.org
    • User Agent:okhttp/3.9.1
  5. देखें कि क्या सभी 499 गड़बड़ियों के लिए, कुल जवाब का समय और उपयोगकर्ता एजेंट एक जैसा है.

वजह: क्लाइंट ने कनेक्शन को अचानक बंद कर दिया

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

  1. जब ब्राउज़र या मोबाइल ऐप्लिकेशन में चल रहे किसी सिंगल पेज ऐप्लिकेशन से एपीआई को कॉल किया जाता है, तो ब्राउज़र अनुरोध को रद्द कर देगा. ऐसा तब होगा, जब उपयोगकर्ता अचानक ब्राउज़र बंद कर देता है, उसी टैब में किसी दूसरे वेबपेज पर चला जाता है या लोड होना बंद करें पर क्लिक या टैप करके पेज को लोड होने से रोक देता है.
  2. ऐसा होने पर, एचटीटीपी 499 स्टेटस वाले लेन-देन के लिए, अनुरोध को प्रोसेस करने में लगने वाला समय (जवाब मिलने में लगने वाला समय) अलग-अलग होगा.
  3. यह पता लगाया जा सकता है कि इसकी वजह से गड़बड़ी हुई है या नहीं. इसके लिए, जवाब देने में लगने वाले समय की तुलना करें. साथ ही, यह पुष्टि करें कि एपीआई मॉनिटरिंग या NGINX ऐक्सेस लॉग का इस्तेमाल करके, 499 गड़बड़ियों में से हर एक के लिए यह समय अलग-अलग है या नहीं. इसके बारे में गड़बड़ी का पता लगाने के सामान्य तरीके में बताया गया है.

रिज़ॉल्यूशन

  1. यह सामान्य है. अगर एचटीटीपी 499 गड़बड़ियां कम संख्या में हो रही हैं, तो आम तौर पर इससे कोई समस्या नहीं होती.

  2. अगर एक ही यूआरएल पाथ के लिए ऐसा बार-बार हो रहा है, तो इसकी वजह यह हो सकती है कि उस पाथ से जुड़ी प्रॉक्सी बहुत धीमी है और उपयोगकर्ता इंतज़ार नहीं करना चाहते.

    यह पता चलने के बाद कि किस प्रॉक्सी पर असर पड़ सकता है, लेटेंसी विश्लेषण डैशबोर्ड का इस्तेमाल करके, यह पता लगाएं कि प्रॉक्सी की लेटेंसी किस वजह से बढ़ रही है.

    1. इस मामले में, सामान्य तौर पर गड़बड़ी का पता लगाने के तरीके में दिए गए चरणों का इस्तेमाल करके, उस प्रॉक्सी का पता लगाएं जिस पर असर पड़ा है.
    2. प्रॉक्सी के इंतज़ार के समय की वजह जानने और समस्या ठीक करने के लिए, इंतज़ार के समय का विश्लेषण करने वाले डैशबोर्ड का इस्तेमाल करें.
    3. अगर आपको लगता है कि किसी खास प्रॉक्सी के लिए, इंतज़ार का समय सामान्य है, तो आपको अपने उपयोगकर्ताओं को यह बताना होगा कि इस प्रॉक्सी को जवाब देने में कुछ समय लगेगा.

वजह: क्लाइंट ऐप्लिकेशन का टाइम आउट होना

ऐसा कई स्थितियों में हो सकता है.

  1. सामान्य तौर पर, अनुरोध को पूरा होने में कुछ समय लगता है. मान लें कि इसमें 10 सेकंड लगते हैं. हालांकि, क्लाइंट ऐप्लिकेशन के लिए टाइमआउट की गलत वैल्यू सेट की गई है. मान लें कि यह वैल्यू पांच सेकंड है. इससे एपीआई अनुरोध पूरा होने से पहले ही क्लाइंट ऐप्लिकेशन का टाइमआउट हो जाता है. इसलिए, 499 दिखता है. इस मामले में, हमें क्लाइंट के लिए टाइम आउट की वैल्यू को सही वैल्यू पर सेट करना होगा.
  2. किसी टारगेट सर्वर या कॉलआउट में उम्मीद से ज़्यादा समय लग रहा है. इस मामले में, आपको सही कॉम्पोनेंट को ठीक करना होगा. साथ ही, टाइमआउट की वैल्यू को भी सही तरीके से अडजस्ट करना होगा.
  3. क्लाइंट को अब जवाब की ज़रूरत नहीं है. इसलिए, उसने अनुरोध को रद्द कर दिया. ऐसा ज़्यादा फ़्रीक्वेंसी वाले एपीआई के लिए हो सकता है. जैसे, ऑटोकंप्लीट या शॉर्ट पोलिंग.

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

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

एपीआई मॉनिटरिंग या NGINX ऐक्सेस लॉग का इस्तेमाल करके, गड़बड़ी का पता लगाएं:

  1. समस्या हल करने के सामान्य तरीके में बताए गए तरीके से, एचटीटीपी 499 लेन-देन के लिए, एपीआई मॉनिटरिंग लॉग या NGINX ऐक्सेस लॉग देखें.
  2. यह तय करें कि 499 गड़बड़ियों के लिए, जवाब देने में लगने वाला समय एक जैसा है या नहीं.
  3. अगर हां, तो ऐसा हो सकता है कि किसी क्लाइंट ऐप्लिकेशन ने अपने एंड पर टाइम आउट की अवधि तय की हो. अगर कोई एपीआई प्रॉक्सी या टारगेट सर्वर धीरे-धीरे जवाब दे रहा है, तो प्रॉक्सी का समय खत्म होने से पहले क्लाइंट का समय खत्म हो जाएगा. इससे एक ही यूआरआई पाथ के लिए, बड़ी संख्या में एचटीटीपी 499s स्टेटस कोड मिलेंगे. इस मामले में, NGINX ऐक्सेस लॉग से User Agent का पता लगाएं. इससे आपको क्लाइंट ऐप्लिकेशन के बारे में पता चल सकता है.
  4. ऐसा भी हो सकता है कि Apigee के सामने कोई लोड बैलेंसर हो. जैसे, Akamai, F5, AWS ELB वगैरह. अगर Apigee, कस्टम लोड बैलेंसर के पीछे चल रहा है, तो लोड बैलेंसर के अनुरोध टाइमआउट को Apigee API के टाइमआउट से ज़्यादा पर कॉन्फ़िगर किया जाना चाहिए. डिफ़ॉल्ट रूप से, Apigee राऊटर 57 सेकंड के बाद टाइम आउट हो जाता है. इसलिए, लोड बैलेंसर पर अनुरोध के टाइम आउट को 60 सेकंड पर कॉन्फ़िगर करना सही है.

ट्रेस

Trace का इस्तेमाल करके गड़बड़ी का पता लगाना

अगर समस्या अब भी बनी हुई है (499 गड़बड़ियां अब भी हो रही हैं), तो यह तरीका अपनाएं:

  1. Edge UI में, समस्या वाले एपीआई के लिए ट्रेस सेशन चालू करें.
  2. गड़बड़ी होने का इंतज़ार करें. अगर आपके पास एपीआई कॉल है, तो कुछ एपीआई कॉल करें और गड़बड़ी को फिर से दिखाएं.
  3. हर फ़ेज़ में लगे समय की जांच करें. साथ ही, उस फ़ेज़ को नोट करें जिसमें सबसे ज़्यादा समय लगा.
  4. अगर आपको इनमें से किसी एक फ़ेज़ के तुरंत बाद, सबसे ज़्यादा समय तक रहने वाली गड़बड़ी दिखती है, तो इसका मतलब है कि बैकएंड सर्वर धीमा है या अनुरोध को प्रोसेस करने में ज़्यादा समय ले रहा है:
    • टारगेट सर्वर को अनुरोध भेजा गया
    • ServiceCallout नीति

    यहां यूज़र इंटरफ़ेस (यूआई) ट्रेस का एक सैंपल दिया गया है. इसमें टारगेट सर्वर को अनुरोध भेजने के बाद, गेटवे टाइमआउट दिखाया गया है:

रिज़ॉल्यूशन

  1. Apigee Edge के ज़रिए एपीआई अनुरोध के फ़्लो में शामिल अलग-अलग कॉम्पोनेंट पर, टाइम आउट की कौनसी वैल्यू सेट की जानी चाहिए, यह समझने के लिए I/O टाइमआउट को कॉन्फ़िगर करने के सबसे सही तरीके पढ़ें.
  2. पक्का करें कि आपने क्लाइंट ऐप्लिकेशन पर, सबसे सही तरीकों के मुताबिक टाइमआउट की सही वैल्यू सेट की हो.

अगर समस्या अब भी बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं .

डाइग्नोस्टिक जानकारी इकट्ठा करना ज़रूरी है

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

अगर आप पब्लिक क्लाउड का इस्तेमाल करते हैं, तो यह जानकारी दें:

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

अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:

  • अनुरोध पूरे न होने पर, गड़बड़ी का पूरा मैसेज दिखता है
  • परिवेश का नाम
  • एपीआई प्रॉक्सी बंडल
  • उन एपीआई अनुरोधों के लिए ट्रेस फ़ाइल जिनमें आपको क्लाइंट टाइमआउट की गड़बड़ियां दिख रही हैं
  • NGINX के ऐक्सेस लॉग (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • मैसेज प्रोसेसर के सिस्टम लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log)