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

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

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

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

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

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

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

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

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

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

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

क्लाइंट पर समय खत्म हो गया

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

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

राऊटर पर टाइम आउट हो गया

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

मैसेज प्रोसेसर पर समय खत्म हो गया

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

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

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

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

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

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

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

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

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

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

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

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

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

    ट्रैफ़िक लॉग विंडो से, कुछ 499 गड़बड़ियों के लिए नीचे दी गई जानकारी पर ध्यान दें:

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

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

    एपीआई मॉनिटरिंग, एचटीटीपी 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. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो आपके पास 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
    • उपयोगकर्ता एजेंट: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 के ऐक्सेस लॉग से उपयोगकर्ता एजेंट तय करें. इससे, आपको खास क्लाइंट ऐप्लिकेशन का पता लगाने में मदद मिलेगी.
  4. यह भी हो सकता है कि Apigee के सामने लोड बैलेंसर मौजूद हो, जैसे कि Acamai, F5, AWS ELB वगैरह. अगर Apigee को कस्टम लोड बैलेंसर के तौर पर इस्तेमाल किया जा रहा है, तो लोड बैलेंसर के लिए अनुरोध के टाइम आउट को इस तरह कॉन्फ़िगर किया जाना चाहिए कि वह Apigee API के टाइम आउट से ज़्यादा हो. डिफ़ॉल्ट रूप से, Apigee राऊटर, 57 सेकंड के बाद टाइम आउट हो जाता है. इसलिए, लोड बैलेंसर पर अनुरोध के खत्म होने के 60 सेकंड के बाद, इसे कॉन्फ़िगर करना सही रहता है.

ट्रेस

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

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

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

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

रिज़ॉल्यूशन

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

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

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

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

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

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

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

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