আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
সমস্যার উপসর্গ
ক্লায়েন্ট অ্যাপ্লিকেশন API অনুরোধের জন্য টাইম-আউট সংক্রান্ত সমস্যা পায় অথবা API অনুরোধ এখনও Apigee-তে এক্সিকিউট করা হচ্ছে এমন সময় অনুরোধটি হঠাৎ করে বন্ধ হয়ে যায়।
আপনি API মনিটরিং এবং
NGINX অ্যাক্সেস লগে এই ধরনের API অনুরোধের জন্য স্ট্যাটাস কোড 499 দেখতে পাবেন। কখনও কখনও, আপনি API Analytics-এ আলাদা স্ট্যাটাস কোড দেখতে পাবেন কারণ এটি
মেসেজ প্রসেসর দ্বারা রিটার্ন করা স্ট্যাটাস কোড দেখায়।
সমস্যা সংক্রান্ত মেসেজ
ক্লায়েন্ট অ্যাপ্লিকেশন এই ধরনের সমস্যা দেখতে পেতে পারে:
curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
ক্লায়েন্ট টাইম-আউট হওয়ার কারণ কী?
Edge প্ল্যাটফর্মে API অনুরোধের সাধারণ পাথ হল ক্লায়েন্ট > রাউটার > মেসেজ প্রসেসর > ব্যাকএন্ড সার্ভার, যা নিম্নলিখিত ছবিতে দেখানো হয়েছে:
Apigee Edge প্ল্যাটফর্মের মধ্যে রাউটার ও মেসেজ প্রসেসর উপযুক্ত ডিফল্ট টাইমআউট ভ্যালু সহ সেট-আপ করা হয় যাতে API অনুরোধ সম্পূর্ণ হতে বেশি সময় না লাগে।
ক্লায়েন্টে টাইম-আউট
আপনার প্রয়োজন অনুযায়ী উপযুক্ত টাইমআউট ভ্যালু দিয়ে ক্লায়েন্ট অ্যাপ্লিকেশন কনফিগার করা যেতে পারে।
ওয়েব ব্রাউজার ও মোবাইল অ্যাপের মতো ক্লায়েন্টদের জন্য অপারেটিং সিস্টেমের মাধ্যমে টাইম-আউট নির্ধারণ করা হয়।
রাউটারে টাইম-আউট
রাউটারে কনফিগার করা ডিফল্ট টাইম-আউট হল ৫৭ সেকেন্ড। এটি হল সর্বাধিক সময়সীমা যার মধ্যে কোনও API প্রক্সি Edge-এ API অনুরোধ পাওয়ার সময় থেকে শুরু করে উত্তর ফেরত পাঠানো পর্যন্ত এক্সিকিউট করতে পারে, এর মধ্যে ব্যাকএন্ড উত্তর ও এক্সিকিউট করা সব নীতি অন্তর্ভুক্ত। রাউটার ও ভার্চুয়াল হোস্টে ডিফল্ট টাইম-আউট ওভাররাইড করা যায়, যা রাউটারে I/O টাইম-আউট কনফিগার করা নিবন্ধে ব্যাখ্যা করা হয়েছে।
মেসেজ প্রসেসরের টাইম-আউট
মেসেজ প্রসেসরে কনফিগার করা ডিফল্ট টাইম-আউট হল ৫৫ সেকেন্ড। এটি হল সর্বাধিক সময় যা ব্যাকএন্ড সার্ভার অনুরোধ প্রসেস করতে এবং মেসেজ প্রসেসরকে উত্তর দিতে নিতে পারে। মেসেজ প্রসেসর বা API-এর মধ্যে ডিফল্ট টাইম-আউট ওভাররাইড করা যেতে পারে প্রক্সি, যা মেসেজ প্রসেসরে I/O টাইম-আউট কনফিগার করা নিবন্ধে ব্যাখ্যা করা হয়েছে।
API প্রক্সি টাইম-আউট হওয়ার আগে ক্লায়েন্ট রাউটারের সাথে কানেকশন বন্ধ করে দিলে, আপনি
নির্দিষ্ট API অনুরোধের জন্য টাইম-আউট সংক্রান্ত সমস্যা দেখতে পাবেন। এই ধরনের অনুরোধের জন্য রাউটারে 499 Client
Closed Connection স্ট্যাটাস কোড লগ করা হয়, যা API
মনিটরিং ও NGINX অ্যাক্সেস লগে দেখা যায়।
সম্ভাব্য কারণ
Edge-এ, 499 Client Closed Connection সমস্যার সাধারণ কারণগুলি হল:
| কারণ | বিবরণ | এর জন্য প্রযোজ্য সমস্যার সমাধান সংক্রান্ত নির্দেশাবলী |
|---|---|---|
| ক্লায়েন্ট হঠাৎ কানেকশন বন্ধ করে দিয়েছে | শেষ ব্যবহারকারী অনুরোধ সম্পূর্ণ হওয়ার আগে সেটি বাতিল করে দিলে ক্লায়েন্ট কানেকশন বন্ধ করে দেয়। এর ফলে এটি ঘটে। | পাবলিক ও প্রাইভেট ক্লাউড ব্যবহারকারী |
| ক্লায়েন্ট অ্যাপ্লিকেশন টাইমআউট | API প্রক্সি প্রসেস করার ও উত্তর পাঠানোর আগে ক্লায়েন্ট অ্যাপ্লিকেশন টাইম-আউট হয়ে গেলে এটি ঘটে। সাধারণত ক্লায়েন্ট টাইম-আউট রাউটার টাইম-আউটের চেয়ে কম হলে এটি ঘটে। | পাবলিক ও প্রাইভেট ক্লাউড ব্যবহারকারী |
সাধারণ ডায়াগনসিস ধাপ
এই সমস্যা ডায়াগনসিস করতে নিম্নলিখিত টুল/টেকনিকের মধ্যে একটি ব্যবহার করুন:
- API মনিটরিং
- NGINX অ্যাক্সেস লগ
API মনিটরিং
API মনিটরিং ব্যবহার করে সমস্যার ডায়াগনসিস করতে:
- বিশ্লেষণ করুন > API মনিটরিং > তদন্ত করুন পৃষ্ঠায় নেভিগেট করুন।
4xxসমস্যার জন্য ফিল্টার করুন এবং সময়সীমা বেছে নিন।- সময়ের বিপরীতে স্ট্যাটাস কোড প্লট করুন।
- নিচে দেখানো
499সমস্যা আছে এমন একটি সেল বেছে নিন:
- নিচে দেখানো ছবির মতো ডানদিকের প্যানেলে আপনি
499সমস্যা সম্পর্কিত তথ্য দেখতে পাবেন:
- ডানদিকের প্যানেলে, লগ দেখুন বিকল্পে ক্লিক করুন।
ট্রাফিক লগ উইন্ডো থেকে, কিছু
499ভুলের জন্য নিম্নলিখিত বিবরণ নোট করুন:- অনুরোধ:এটি কল করার জন্য ব্যবহৃত অনুরোধ পদ্ধতি ও URI প্রদান করে
- উত্তর সময়:এটি অনুরোধের জন্য মোট অতিক্রান্ত সময় প্রদান করে।
এছাড়াও, API মনিটরিং GET logs API ব্যবহার করে আপনি সব লগ পেতে পারেন। যেমন,
org,env,timeRangeওstatus-এর জন্য কোয়েরি লগ করে, আপনি সেইসব ট্রানজ্যাকশনের সব লগ ডাউনলোড করতে পারবেন যেখানে ক্লায়েন্ট টাইম-আউট হয়ে গেছে।API মনিটরিং
--এ HTTP499এরর প্রক্সি সেট করে বলে, আপনি 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সমস্যার ক্ষেত্রে একই (ধরা যাক ৩০ সেকেন্ড) আছে কিনা।
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সেকেন্ড। এর থেকে বোঝা যায় যে ১০.০০১ সেকেন্ড পরে ক্লায়েন্টের টাইম-আউট হয়ে গেছে - অনুরোধ:
GET /v1/products - হোস্ট:
api.acme.org - ইউজার এজেন্ট:
okhttp/3.9.1
- মোট উত্তর দেওয়ার সময় এবং ইউজার এজেন্ট সব
499সমস্যার ক্ষেত্রে একই রকম আছে কিনা তা চেক করুন।
কারণ: ক্লায়েন্ট হঠাৎ করে কানেকশন বন্ধ করে দিয়েছে
ডায়াগনসিস
- ব্রাউজার বা মোবাইল অ্যাপ্লিকেশনে রান করা কোনও সিঙ্গেল পেজ অ্যাপ থেকে কোনও API কল করা হলে, শেষ ব্যবহারকারী হঠাৎ করে ব্রাউজার বন্ধ করে দিলে, একই ট্যাবে অন্য ওয়েবপেজে নেভিগেট করলে অথবা লোডিং বন্ধ করুন বিকল্পে ক্লিক বা ট্যাপ করে পৃষ্ঠা লোড হওয়া বন্ধ করে দিলে, ব্রাউজার অনুরোধটি বাতিল করে দেবে।
- এটি ঘটলে, HTTP
499স্ট্যাটাস সহ ট্রানজ্যাকশনগুলি সাধারণত প্রতিটি অনুরোধের জন্য অনুরোধ প্রসেস করার সময় (উত্তর দেওয়ার সময়) আলাদা আলাদা হবে। -
রেসপন্স টাইম তুলনা করে এবং API মনিটরিং বা NGINX অ্যাক্সেস
লগ ব্যবহার করে
499সমস্যার প্রতিটি ক্ষেত্রে এটি আলাদা কিনা তা যাচাই করে আপনি নির্ধারণ করতে পারবেন যে এটিই কারণ কিনা। সাধারণ ডায়াগনসিস ধাপ-এ এটি ব্যাখ্যা করা হয়েছে।
রেজোলিউশন
- এটি স্বাভাবিক এবং HTTP
499সমস্যা কম সংখ্যায় হলে সাধারণত চিন্তার কোনও কারণ নেই। -
একই URL পাথের জন্য এটি প্রায়ই ঘটলে, এর কারণ হতে পারে যে সেই পাথের সাথে যুক্ত নির্দিষ্ট প্রক্সি খুব ধীরে কাজ করছে এবং ব্যবহারকারীরা অপেক্ষা করতে চাইছেন না।
কোন প্রক্সি প্রভাবিত হতে পারে তা জানার পরে, প্রক্সি লেটেন্সির কারণ কী তা আরও তদন্ত করতে লেটেন্সি বিশ্লেষণ ড্যাশবোর্ড ব্যবহার করুন।
- এই ক্ষেত্রে, সাধারণ ডায়াগনসিস ধাপ-এ দেওয়া ধাপগুলি ব্যবহার করে প্রভাবিত প্রক্সি নির্ধারণ করুন।
- প্রক্সি লেটেন্সি কী কারণে হচ্ছে তা আরও তদন্ত করতে এবং সমস্যা সমাধান করতে লেটেন্সি বিশ্লেষণ ড্যাশবোর্ড ব্যবহার করুন।
- আপনি যদি দেখেন যে নির্দিষ্ট প্রক্সির জন্য লেটেন্সি প্রত্যাশিত, তাহলে আপনাকে আপনার ব্যবহারকারীদের জানাতে হতে পারে যে এই প্রক্সি উত্তর দিতে কিছু সময় নেবে।
কারণ: ক্লায়েন্ট অ্যাপ্লিকেশন টাইম-আউট
বিভিন্ন পরিস্থিতিতে এটি ঘটতে পারে।
-
সাধারণ অপারেটিং কন্ডিশনে অনুরোধটি সম্পূর্ণ হতে একটি নির্দিষ্ট সময় (ধরা যাক ১০ সেকেন্ড) লাগবে বলে আশা করা হয়
। তবে, ক্লায়েন্ট অ্যাপ্লিকেশনটি ভুল
টাইমআউট মান (ধরা যাক ৫ সেকেন্ড) দিয়ে সেট করা আছে, যার ফলে 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 রাউটার ৫৭ সেকেন্ড পরে টাইম-আউট হয়ে যায়, তাই লোড ব্যালেন্সারে ৬০ সেকেন্ডের অনুরোধ টাইম-আউট কনফিগার করা উপযুক্ত।
ট্রেস
Trace ব্যবহার করে সমস্যার কারণ নির্ণয় করা
সমস্যা এখনও থাকলে (499 সংক্রান্ত সমস্যা এখনও হচ্ছে), তাহলে
নিচের ধাপগুলি অনুসরণ করুন:
- Edge UI-তে প্রভাবিত API-এর জন্য ট্রেস সেশন চালু করুন।
- সমস্যা না হওয়া পর্যন্ত অপেক্ষা করুন অথবা আপনার কাছে API কল থাকলে, কিছু API কল করুন এবং সমস্যাটি আবার তৈরি করুন।
- প্রতিটি ধাপে অতিবাহিত সময় চেক করুন এবং যে ধাপে সবচেয়ে বেশি সময় ব্যয় হয়েছে সেটি নোট করে রাখুন।
- নিম্নলিখিত ধাপগুলির মধ্যে কোনও একটির ঠিক পরেই সবচেয়ে বেশি সময় ধরে
ত্রুটিটি দেখতে পেলে, এটি ইঙ্গিত করে যে ব্যাকএন্ড সার্ভার ধীরে কাজ করছে অথবা অনুরোধ প্রসেস করতে
অনেক সময় নিচ্ছে:
- টার্গেট সার্ভারে অনুরোধ পাঠানো হয়েছে
- ServiceCallout নীতি
এখানে একটি নমুনা UI ট্রেস দেওয়া হল যেখানে অনুরোধ টার্গেট সার্ভারে পাঠানোর পরে গেটওয়ে টাইম-আউট দেখানো হয়েছে:
রেজোলিউশন
- Apigee Edge-এর মাধ্যমে API অনুরোধ ফ্লোতে জড়িত বিভিন্ন কম্পোনেন্টে কী ধরনের টাইমআউট ভ্যালু সেট করা উচিত তা বুঝতে I/O টাইমআউট কনফিগার করার পেশাদার পদ্ধতি দেখুন।
- পেশাদার পদ্ধতি অনুযায়ী ক্লায়েন্ট অ্যাপ্লিকেশনে উপযুক্ত টাইম-আউট ভ্যালু সেট করেছেন কিনা তা নিশ্চিত করুন।
এর পরেও সমস্যা থেকে গেলে, অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে লিঙ্কে যান।
অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে
সমস্যাটি থেকে গেলে, নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন এবং তারপরে Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন।
আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে, নিম্নলিখিত তথ্য প্রদান করুন:
- সংস্থার নাম
- পরিবেশের নাম
- API প্রক্সির নাম
- টাইম-আউট সংক্রান্ত সমস্যা আবার তৈরি করতে ব্যবহৃত
curlকমান্ড সম্পূর্ণ করুন - যেসব API অনুরোধের জন্য আপনি ক্লায়েন্ট টাইম-আউট সংক্রান্ত সমস্যা দেখতে পাচ্ছেন সেগুলির জন্য ট্রেস ফাইল
আপনি প্রাইভেট ক্লাউড ব্যবহারকারী হলে, নিম্নলিখিত তথ্য দিন:
- অনুরোধ সম্পূর্ণ না হওয়ার ক্ষেত্রে দেখা সম্পূর্ণ সমস্যার মেসেজ
- পরিবেশের নাম
- API Proxy বান্ডেল
- যেসব API অনুরোধের জন্য আপনি ক্লায়েন্ট টাইম-আউট সংক্রান্ত সমস্যা দেখতে পাচ্ছেন সেগুলির জন্য ট্রেস ফাইল
- NGINX অ্যাক্সেস লগ (
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) - মেসেজ প্রসেসর সিস্টেম লগ (
/opt/apigee/var/log/edge-message-processor/logs/system.log)