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 टाइम आउट कॉन्फ़िगर करना.

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

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

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

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

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

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

गड़बड़ी की जांच करने के सामान्य तरीके

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

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

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

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

  1. विश्लेषण करें > एपीआई मॉनिटरिंग > पेज की जांच करें.
  2. 4xx गड़बड़ियों को फ़िल्टर करें और समयसीमा चुनें.
  3. समय के हिसाब से स्टेटस कोड प्लॉट करें.
  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 गड़बड़ियां.

NGINX ऐक्सेस लॉग

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

  1. अगर आप प्राइवेट 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
    • उपयोगकर्ता एजेंट:okhttp/3.9.1
  5. देख लें कि जवाब देने में लगने वाला कुल समय और उपयोगकर्ता एजेंट एक जैसा है या नहीं सभी 499 गड़बड़ियों में.

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

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

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

रिज़ॉल्यूशन

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

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

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

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

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

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

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

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

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

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

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

ट्रेस

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

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

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

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

रिज़ॉल्यूशन

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

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

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

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

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

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

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

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