এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

499 ক্লায়েন্ট বন্ধ সংযোগ

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি API অনুরোধগুলির জন্য একটি টাইমআউট ত্রুটি পায় বা অনুরোধটি হঠাৎ বন্ধ হয়ে যায় যখন API অনুরোধটি এখনও Apigee-এ কার্যকর করা হচ্ছে।

আপনি API মনিটরিং এবং NGINX অ্যাক্সেস লগগুলিতে এই জাতীয় API অনুরোধগুলির জন্য স্ট্যাটাস কোড 499 পর্যবেক্ষণ করবেন। কখনও কখনও, আপনি API অ্যানালিটিক্সে বিভিন্ন স্ট্যাটাস কোড দেখতে পাবেন কারণ এটি মেসেজ প্রসেসর দ্বারা ফেরত দেওয়া স্ট্যাটাস কোড দেখায়।

ত্রুটি বার্তা

ক্লায়েন্ট অ্যাপ্লিকেশন ত্রুটি দেখতে পারে যেমন:

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

ক্লায়েন্ট টাইমআউটের কারণ কী?

এজ প্ল্যাটফর্মে একটি API অনুরোধের জন্য সাধারণ পথ হল ক্লায়েন্ট > রাউটার > বার্তা প্রসেসর > ব্যাকএন্ড সার্ভার নিম্নলিখিত চিত্রে দেখানো হয়েছে:

Apigee Edge প্ল্যাটফর্মের মধ্যে রাউটার এবং মেসেজ প্রসেসরগুলি উপযুক্ত ডিফল্ট টাইমআউট মানগুলির সাথে সেট আপ করা হয়েছে যাতে নিশ্চিত করা যায় যে API অনুরোধগুলি সম্পূর্ণ হতে খুব বেশি সময় নেয় না।

ক্লায়েন্টের উপর সময়সীমা

ক্লায়েন্ট অ্যাপ্লিকেশনগুলি আপনার প্রয়োজনের উপর ভিত্তি করে একটি উপযুক্ত টাইমআউট মান দিয়ে কনফিগার করা যেতে পারে।

ওয়েব ব্রাউজার এবং মোবাইল অ্যাপের মতো ক্লায়েন্টদের অপারেটিং সিস্টেম দ্বারা নির্ধারিত সময়সীমা রয়েছে।

রাউটারে টাইমআউট

রাউটারে কনফিগার করা ডিফল্ট টাইমআউট হল 57 সেকেন্ড। এজ-এ API অনুরোধ প্রাপ্ত হওয়ার সময় থেকে ব্যাকএন্ড প্রতিক্রিয়া এবং কার্যকর করা সমস্ত নীতি সহ প্রতিক্রিয়া ফেরত পাঠানো না হওয়া পর্যন্ত এটি একটি API প্রক্সি কার্যকর করতে পারে। ডিফল্ট টাইমআউট রাউটার এবং ভার্চুয়াল হোস্টগুলিতে ওভাররাইড করা যেতে পারে যেমন রাউটারে I/O টাইমআউট কনফিগার করার ব্যাখ্যা করা হয়েছে।

বার্তা প্রসেসরের সময়সীমা

মেসেজ প্রসেসরে কনফিগার করা ডিফল্ট টাইমআউট হল 55 সেকেন্ড। ব্যাকএন্ড সার্ভার অনুরোধটি প্রক্রিয়া করতে এবং বার্তা প্রসেসরে ফিরে প্রতিক্রিয়া জানাতে এটি সর্বাধিক সময় নিতে পারে । ডিফল্ট টাইমআউট মেসেজ প্রসেসরে বা API প্রক্সির মধ্যে ওভাররাইড করা যেতে পারে যেমনটি মেসেজ প্রসেসরগুলিতে I/O টাইমআউট কনফিগার করায় ব্যাখ্যা করা হয়েছে।

যদি API প্রক্সির সময় শেষ হওয়ার আগে ক্লায়েন্ট রাউটারের সাথে সংযোগ বন্ধ করে দেয়, তাহলে আপনি নির্দিষ্ট API অনুরোধের জন্য টাইমআউট ত্রুটি পর্যবেক্ষণ করবেন। স্ট্যাটাস কোড 499 Client Closed Connection এই ধরনের অনুরোধের জন্য রাউটারে লগ ইন করা আছে, যা API মনিটরিং এবং NGINX অ্যাক্সেস লগগুলিতে লক্ষ্য করা যেতে পারে।

সম্ভাব্য কারণ

এজ-এ, 499 Client Closed Connection ত্রুটির জন্য সাধারণ কারণগুলি হল:

কারণ	বর্ণনা	সমস্যা সমাধানের নির্দেশাবলী প্রযোজ্য
ক্লায়েন্ট হঠাৎ সংযোগ বন্ধ	শেষ ব্যবহারকারী অনুরোধটি সম্পূর্ণ হওয়ার আগেই বাতিল করার কারণে ক্লায়েন্ট সংযোগটি বন্ধ করে দিলে এটি ঘটে।	পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারী
ক্লায়েন্ট আবেদনের সময়সীমা	এটি ঘটে যখন ক্লায়েন্ট অ্যাপ্লিকেশনটির সময় শেষ হওয়ার আগে API প্রক্সির প্রক্রিয়াকরণ এবং প্রতিক্রিয়া পাঠানোর সময় থাকে। সাধারণত এটি ঘটে যখন ক্লায়েন্ট টাইমআউট রাউটারের টাইমআউটের চেয়ে কম হয়।	পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারী

সাধারণ রোগ নির্ণয়ের পদক্ষেপ

এই ত্রুটি নির্ণয় করতে নিম্নলিখিত সরঞ্জাম/কৌশলগুলির মধ্যে একটি ব্যবহার করুন:

API মনিটরিং
NGINX অ্যাক্সেস লগ

API মনিটরিং

API মনিটরিং ব্যবহার করে ত্রুটি নির্ণয় করতে:

এনালাইজ > API মনিটরিং > ইনভেস্টিগেট পেজে নেভিগেট করুন।
4xx ত্রুটির জন্য ফিল্টার করুন এবং সময়সীমা নির্বাচন করুন।
সময়ের বিপরীতে প্লট স্ট্যাটাস কোড ।
নীচে দেখানো হিসাবে 499 ত্রুটি আছে এমন একটি ঘর নির্বাচন করুন:
আপনি নীচে দেখানো হিসাবে ডান হাত ফলকে 499 ত্রুটি সম্পর্কে তথ্য দেখতে পাবেন:
ডানদিকের ফলকে, লগগুলি দেখুন ক্লিক করুন।
ট্র্যাফিক লগ উইন্ডো থেকে, কিছু 499 ত্রুটির জন্য নিম্নলিখিত বিবরণ নোট করুন:
- অনুরোধ : এটি কল করার জন্য ব্যবহৃত অনুরোধের পদ্ধতি এবং URI প্রদান করে
- প্রতিক্রিয়ার সময় : এটি অনুরোধের জন্য অতিবাহিত মোট সময় প্রদান করে।
দ্রষ্টব্য : নিম্নোক্ত ক্ষেত্র মান প্রদর্শন করবে - HTTP 499 ত্রুটির জন্য:
- ফল্ট উত্স
- ফল্ট কোড
- ফল্ট ফ্লো
- ফল্ট পলিসি
- ফল্ট প্রক্সি
এই ক্ষেত্রগুলি মেসেজ প্রসেসর দ্বারা পপুলেট করা হয় এবং রাউটার মেসেজ প্রসেসরের কাছ থেকে একটি প্রতিক্রিয়া পেলেই উপযুক্ত মান দিয়ে সেট করা হবে। এই ক্ষেত্রে, ক্লায়েন্ট অ্যাপ্লিকেশন রাউটারের সাথে সংযোগ বন্ধ করে দেয় আগে রাউটার বার্তা প্রসেসর থেকে একটি প্রতিক্রিয়া ফিরে পায়। এটি রাউটারকে স্ট্যাটাস কোড 499 এ সেট করতে বাধ্য করে এবং ফলস্বরূপ উপরে উল্লিখিত সমস্ত ক্ষেত্র - হিসাবে প্রদর্শিত হয়।
আপনি API মনিটরিং GET লগ API ব্যবহার করে সমস্ত লগ পেতে পারেন। উদাহরণস্বরূপ, org , env , timeRange , এবং status জন্য লগ জিজ্ঞাসা করে, আপনি লেনদেনের জন্য সমস্ত লগ ডাউনলোড করতে সক্ষম হবেন যেখানে ক্লায়েন্টের সময় শেষ হয়েছে৷
যেহেতু API মনিটরিং প্রক্সি সেট করে - HTTP 499 ত্রুটির জন্য, আপনি ভার্চুয়াল হোস্ট এবং পাথের জন্য সংশ্লিষ্ট প্রক্সি পেতে API ( Logs API ) ব্যবহার করতে পারেন।
যেমন:
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
```
অতিরিক্ত 499 ত্রুটির জন্য প্রতিক্রিয়া সময় পর্যালোচনা করুন এবং 499 ত্রুটির সমস্ত জুড়ে প্রতিক্রিয়া সময় সামঞ্জস্যপূর্ণ কিনা তা পরীক্ষা করুন (আসুন 30 সেকেন্ড বলি)।

NGINX অ্যাক্সেস লগ

NGINX অ্যাক্সেস লগ ব্যবহার করে ত্রুটি নির্ণয় করতে:

আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন, তাহলে আপনি HTTP 499 ত্রুটি সম্পর্কে মূল তথ্য নির্ধারণ করতে NGINX অ্যাক্সেস লগ ব্যবহার করতে পারেন।
NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন:
/opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
একটি নির্দিষ্ট সময়ের মধ্যে কোন 499 ত্রুটি আছে কিনা তা দেখতে অনুসন্ধান করুন (যদি সমস্যাটি অতীতে ঘটে থাকে) বা 499 সাথে এখনও কোনও অনুরোধ ব্যর্থ হচ্ছে কিনা।
কিছু 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
টোটাল রেসপন্স টাইম এবং ইউজার এজেন্ট সমস্ত 499 ত্রুটির মধ্যে সামঞ্জস্যপূর্ণ কিনা তা পরীক্ষা করে দেখুন।

কারণ: ক্লায়েন্ট হঠাৎ সংযোগ বন্ধ করে দিয়েছে

রোগ নির্ণয়

যখন ব্রাউজার বা মোবাইল অ্যাপ্লিকেশনে চলমান একটি একক পৃষ্ঠার অ্যাপ্লিকেশন থেকে একটি API কল করা হয়, তখন শেষ ব্যবহারকারী যদি হঠাৎ করে ব্রাউজারটি বন্ধ করে দেয়, একই ট্যাবে অন্য ওয়েবপেজে নেভিগেট করে বা ক্লিক করে পৃষ্ঠাটি লোড হওয়া বন্ধ করে দেয় তাহলে ব্রাউজার অনুরোধটি বাতিল করবে অথবা লোড বন্ধ ট্যাপ.
যদি এটি ঘটে, তবে HTTP 499 স্ট্যাটাস সহ লেনদেনগুলি সাধারণত প্রতিটি অনুরোধের জন্য অনুরোধ প্রক্রিয়াকরণের সময় ( প্রতিক্রিয়া সময় ) পরিবর্তিত হবে৷
আপনি প্রতিক্রিয়া সময় তুলনা করে এবং সাধারণ নির্ণয়ের ধাপে ব্যাখ্যা করা API মনিটরিং বা NGINX অ্যাক্সেস লগ ব্যবহার করে 499 ত্রুটিগুলির প্রতিটির জন্য আলাদা কিনা তা যাচাই করে এটি কারণ কিনা তা নির্ধারণ করতে পারেন।

রেজোলিউশন

এটি স্বাভাবিক এবং HTTP 499 ত্রুটিগুলি অল্প পরিমাণে ঘটলে সাধারণত উদ্বেগের কারণ নয়৷
যদি এটি একই URL পাথের জন্য প্রায়শই ঘটতে থাকে, তবে এটি হতে পারে কারণ সেই পথের সাথে যুক্ত বিশেষ প্রক্সিটি খুব ধীর এবং ব্যবহারকারীরা অপেক্ষা করতে ইচ্ছুক নয়৷
কোন প্রক্সি প্রভাবিত হতে পারে তা জানলে, প্রক্সি লেটেন্সির কারণ কী তা আরও তদন্ত করতে লেটেন্সি অ্যানালাইসিস ড্যাশবোর্ড ব্যবহার করুন৷
1. এই ক্ষেত্রে, সাধারণ রোগ নির্ণয়ের ধাপগুলির ধাপগুলি ব্যবহার করে প্রভাবিত প্রক্সি নির্ধারণ করুন৷
2. প্রক্সি লেটেন্সির কারণ কী তা আরও তদন্ত করতে লেটেন্সি বিশ্লেষণ ড্যাশবোর্ড ব্যবহার করুন এবং সমস্যাটি সমাধান করুন৷
3. আপনি যদি খুঁজে পান যে নির্দিষ্ট প্রক্সির জন্য বিলম্ব প্রত্যাশিত, তাহলে আপনাকে আপনার ব্যবহারকারীদের জানাতে হতে পারে যে এই প্রক্সিটি প্রতিক্রিয়া জানাতে কিছু সময় নেবে৷

কারণ: ক্লায়েন্ট অ্যাপ্লিকেশন সময়সীমা

এটি বিভিন্ন পরিস্থিতিতে ঘটতে পারে।

এটি প্রত্যাশিত যে অনুরোধটি স্বাভাবিক অপারেটিং অবস্থার অধীনে সম্পূর্ণ হতে একটি নির্দিষ্ট সময় (আসুন 10 সেকেন্ড বলি) লাগবে৷ যাইহোক, ক্লায়েন্ট অ্যাপ্লিকেশনটি একটি ভুল টাইমআউট মান দিয়ে সেট করা হয়েছে (আসুন 5 সেকেন্ড বলি) যার ফলে ক্লায়েন্ট অ্যাপ্লিকেশনটি API অনুরোধ সম্পূর্ণ হওয়ার আগে টাইমআউট হয়ে যায়, যার ফলে 499 হয়। এই ক্ষেত্রে, আমাদের ক্লায়েন্ট টাইমআউট একটি উপযুক্ত মান সেট করতে হবে।
একটি লক্ষ্য সার্ভার বা কলআউট প্রত্যাশার চেয়ে বেশি সময় নিচ্ছে৷ এই ক্ষেত্রে, আপনাকে উপযুক্ত উপাদান ঠিক করতে হবে এবং সময়সীমার মানগুলি যথাযথভাবে সামঞ্জস্য করতে হবে।
ক্লায়েন্টের আর প্রতিক্রিয়ার প্রয়োজন নেই এবং তাই বাতিল করা হয়েছে। এটি উচ্চ ফ্রিকোয়েন্সি APIগুলির জন্য ঘটতে পারে যেমন স্বয়ংক্রিয়-সম্পূর্ণ বা সংক্ষিপ্ত পোলিং।

রোগ নির্ণয়

API মনিটরিং বা NGINX অ্যাক্সেস লগ

API মনিটরিং বা NGINX অ্যাক্সেস লগ ব্যবহার করে ত্রুটি নির্ণয় করুন:

সাধারণ নির্ণয়ের ধাপে ব্যাখ্যা করা HTTP 499 লেনদেনের জন্য API মনিটরিং লগ বা NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন৷
রেসপন্স টাইম 499 ত্রুটির জন্য সামঞ্জস্যপূর্ণ কিনা তা নির্ধারণ করুন।
যদি হ্যাঁ, তাহলে এটি হতে পারে যে একটি নির্দিষ্ট ক্লায়েন্ট অ্যাপ্লিকেশন তার শেষের দিকে একটি নির্দিষ্ট সময়সীমা কনফিগার করেছে। যদি একটি API প্রক্সি বা টার্গেট সার্ভার ধীরে ধীরে সাড়া দেয়, তাহলে ক্লায়েন্ট প্রক্সি টাইম আউট হওয়ার আগেই টাইম আউট হয়ে যাবে, যার ফলে একই URI পাথের জন্য প্রচুর পরিমাণে HTTP 499s হবে। এই ক্ষেত্রে, NGINX অ্যাক্সেস লগ থেকে ব্যবহারকারী এজেন্ট নির্ধারণ করুন যা আপনাকে নির্দিষ্ট ক্লায়েন্ট অ্যাপ্লিকেশন নির্ধারণ করতে সাহায্য করতে পারে।
এটাও সম্ভব হতে পারে যে Apigee এর সামনে একটি লোড ব্যালেন্সার আছে যেমন Akamai, F5, AWS ELB, ইত্যাদি। Apigee একটি কাস্টম লোড ব্যালেন্সারের পিছনে চললে, লোড ব্যালেন্সারের অনুরোধের সময়সীমা Apigee API টাইমআউটের চেয়ে বেশি কনফিগার করা আবশ্যক। ডিফল্টরূপে, Apigee রাউটার 57 সেকেন্ডের পরে শেষ হয়ে যায়, তাই লোড ব্যালেন্সারে 60 সেকেন্ডের অনুরোধের সময়সীমা কনফিগার করার জন্য এটি উপযুক্ত।

ট্রেস

ট্রেস ব্যবহার করে ত্রুটি নির্ণয় করুন

যদি সমস্যাটি এখনও সক্রিয় থাকে ( 499 ত্রুটি এখনও ঘটছে), তাহলে নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করুন:

এজ UI-তে প্রভাবিত API-এর জন্য ট্রেস সেশন সক্রিয় করুন।
হয় ত্রুটি হওয়ার জন্য অপেক্ষা করুন, অথবা আপনার যদি API কল থাকে, তাহলে কিছু API কল করুন এবং ত্রুটিটি পুনরুত্পাদন করুন।
প্রতিটি পর্যায়ে অতিবাহিত সময় পরীক্ষা করুন এবং যে পর্যায়ে বেশিরভাগ সময় ব্যয় হয় তার একটি নোট করুন।
আপনি যদি নিম্নলিখিত পর্যায়গুলির মধ্যে একটির পরে অবিলম্বে দীর্ঘতম অতিবাহিত সময়ের সাথে ত্রুটিটি পর্যবেক্ষণ করেন, তবে এটি নির্দেশ করে যে ব্যাকএন্ড সার্ভারটি ধীর গতিতে বা অনুরোধটি প্রক্রিয়া করতে দীর্ঘ সময় নিচ্ছে:
- টার্গেট সার্ভারে অনুরোধ পাঠানো হয়েছে
- সার্ভিস কলআউট নীতি
এখানে একটি নমুনা UI ট্রেস রয়েছে যা লক্ষ্য সার্ভারে অনুরোধ পাঠানোর পরে একটি গেটওয়ে টাইমআউট দেখাচ্ছে:

রেজোলিউশন

Apigee Edge-এর মাধ্যমে API অনুরোধ প্রবাহের সাথে জড়িত বিভিন্ন উপাদানে কোন টাইমআউট মান সেট করা উচিত তা বোঝার জন্য I/O টাইমআউট কনফিগার করার জন্য সেরা অনুশীলনগুলি দেখুন।
নিশ্চিত করুন যে আপনি সর্বোত্তম অনুশীলন অনুসারে ক্লায়েন্ট অ্যাপ্লিকেশনে একটি উপযুক্ত সময়সীমার মান সেট করেছেন।

যদি সমস্যাটি এখনও থেকে যায়, তাহলে অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন এ যান।

ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে

সমস্যাটি অব্যাহত থাকলে, নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন এবং তারপর Apigee Edge সহায়তার সাথে যোগাযোগ করুন।

আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:

প্রতিষ্ঠানের নাম
পরিবেশের নাম
API প্রক্সি নাম
টাইমআউট ত্রুটি পুনরুত্পাদন করতে ব্যবহৃত সম্পূর্ণ curl কমান্ড
API অনুরোধগুলির জন্য ট্রেস ফাইল যার জন্য আপনি ক্লায়েন্ট টাইমআউট ত্রুটিগুলি দেখছেন৷

আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন তবে নিম্নলিখিত তথ্য প্রদান করুন:

ব্যর্থ অনুরোধের জন্য পরিলক্ষিত সম্পূর্ণ ত্রুটি বার্তা
পরিবেশের নাম
API প্রক্সি বান্ডেল
API অনুরোধগুলির জন্য ট্রেস ফাইল যার জন্য আপনি ক্লায়েন্ট টাইমআউট ত্রুটিগুলি দেখছেন৷
NGINX অ্যাক্সেস লগ ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )
বার্তা প্রসেসর সিস্টেম লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log )