আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।
লক্ষণ
একটি এপিআই প্রক্সি কলের পর ক্লায়েন্ট অ্যাপ্লিকেশনটি Service Unavailable বার্তা সহ একটি HTTP প্রতিক্রিয়া স্ট্যাটাস 503 পায়।
ত্রুটির বার্তা
ক্লায়েন্ট অ্যাপ্লিকেশনটি নিম্নলিখিত প্রতিক্রিয়া কোডটি পায়:
HTTP/1.1 503 Service Unavailable
এছাড়াও, আপনি নিম্নলিখিত ত্রুটি বার্তাটি দেখতে পারেন:
{
"fault": {
"faultstring": "The Service is temporarily unavailable",
"detail": {
"errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
}
}
}সম্ভাব্য কারণসমূহ
| কারণ | বর্ণনা | সমস্যা সমাধানের নির্দেশাবলী প্রযোজ্য |
|---|---|---|
| টার্গেট সার্ভার নির্ধারিত সময়ের আগেই সংযোগ বন্ধ করে দেয় | মেসেজ প্রসেসর যখন অনুরোধের পেলোড পাঠাতে থাকে, তখনই টার্গেট সার্ভারটি সময়ের আগেই সংযোগ বিচ্ছিন্ন করে দেয়। | এজ পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারীরা |
সাধারণ রোগ নির্ণয়ের পদক্ষেপ
ব্যর্থ অনুরোধটির মেসেজ আইডি নির্ধারণ করুন।
ট্রেস টুল
ট্রেস টুল ব্যবহার করে ব্যর্থ হওয়া অনুরোধের মেসেজ আইডি নির্ধারণ করতে:
- যদি সমস্যাটি এখনও সক্রিয় থাকে, তাহলে প্রভাবিত API-টির জন্য ট্রেস সেশনটি সক্রিয় করুন।
- এপিআই কলটি করুন এবং সমস্যাটি পুনরায় তৈরি করুন -
503 Service Unavailableএরর কোডmessaging.adaptors.http.flow.ServiceUnavailable. - ব্যর্থ হওয়া অনুরোধগুলোর মধ্যে একটি নির্বাচন করুন।
- AX ফেজে যান এবং নিচের চিত্রে দেখানো অনুযায়ী ফেজ ডিটেইলস (Pphase Details) বিভাগে স্ক্রল ডাউন করে অনুরোধটির মেসেজ আইডি (
X-Apigee.Message-ID) নির্ধারণ করুন।
NGINX অ্যাক্সেস লগ
NGINX অ্যাক্সেস লগ ব্যবহার করে ব্যর্থ অনুরোধটির মেসেজ আইডি নির্ধারণ করতে:
503 ত্রুটির মেসেজ আইডি নির্ধারণ করতে আপনি NGINX অ্যাক্সেস লগও দেখতে পারেন। এটি বিশেষভাবে কার্যকর যদি সমস্যাটি অতীতে ঘটে থাকে অথবা যদি সমস্যাটি মাঝে মাঝে হয় এবং আপনি UI-তে এর ট্রেস ক্যাপচার করতে না পারেন। NGINX অ্যাক্সেস লগ থেকে এই তথ্য নির্ধারণ করতে নিম্নলিখিত ধাপগুলো অনুসরণ করুন:
- NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন: (
/opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log) - অনুসন্ধান করে দেখুন যে একটি নির্দিষ্ট সময়কালে নির্দিষ্ট এপিআই প্রক্সির জন্য কোনো
503এরর ছিল কিনা (যদি সমস্যাটি অতীতে ঘটে থাকে) অথবা এখনও কোনো রিকোয়েস্ট503এর কারণে ব্যর্থ হচ্ছে কিনা। - যদি X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable সহ কোনো
503Error থাকে, তাহলে নিম্নলিখিত উদাহরণে দেখানো অনুযায়ী এক বা একাধিক অনুরোধের মেসেজ আইডি নোট করুন:503ত্রুটি প্রদর্শনকারী নমুনা এন্ট্রি
কারণ: টার্গেট সার্ভার সময়ের আগেই সংযোগ বন্ধ করে দেয়
রোগ নির্ণয়
- আপনি যদি পাবলিক ক্লাউড বা প্রাইভেট ক্লাউড ব্যবহারকারী হন:
- ট্রেস টুলটি ব্যবহার করুন (যেমনটি সাধারণ রোগ নির্ণয়ের ধাপগুলিতে ব্যাখ্যা করা হয়েছে) এবং যাচাই করুন যে অ্যানালিটিক্স ডেটা রেকর্ডেড প্যানে নিম্নলিখিত দুটিই সেট করা আছে:
- X-Apigee.fault-code:
messaging.adaptors.http.flow.ServiceUnavailable - X-Apigee.fault-source:
target

- X-Apigee.fault-code:
- ট্রেস টুলটি ব্যবহার করুন (যেমনটি সাধারণ ডায়াগনোসিস ধাপে ব্যাখ্যা করা হয়েছে) এবং যাচাই করুন যে
TARGET_REQ_FLOWস্টেট প্রপার্টির ঠিক পরেই এরর প্যানে নিম্নলিখিত দুটিই সেট করা আছে:- error.class:
com.apigee.errors.http.server.ServiceUnavailableException - ত্রুটি.কারণ:
Broken pipe

- error.class:
- আরও তদন্তের জন্য 'Using tcpdump' অংশে যান।
- ট্রেস টুলটি ব্যবহার করুন (যেমনটি সাধারণ রোগ নির্ণয়ের ধাপগুলিতে ব্যাখ্যা করা হয়েছে) এবং যাচাই করুন যে অ্যানালিটিক্স ডেটা রেকর্ডেড প্যানে নিম্নলিখিত দুটিই সেট করা আছে:
- আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন:
- ব্যর্থ হওয়া অনুরোধটির মেসেজ আইডি নির্ণয় করুন ।
- মেসেজ প্রসেসর লগে (
/opt/apigee/var/log/edge-message-processor/logs/system.log) মেসেজ আইডিটি অনুসন্ধান করুন। - আপনি নিম্নলিখিত ব্যতিক্রমগুলির মধ্যে একটি দেখতে পাবেন:
ব্যতিক্রম #১: java.io.IOException: ClientOutputChannel চ্যানেলে লেখার সময় ব্রোকেন পাইপ ঘটেছে।
2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy rev:1 messageid:myorg-opdk-test-1-30312-13747-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[Connected: Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1 bytesRead=0 bytesWritten=76295 age=2012ms lastIO=2ms isOpen=false)
অথবা
ব্যতিক্রম #২: onExceptionWrite ব্যতিক্রম: {}
java.io.IOException: Broken pipe2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() : ClientChannel[Connected: Remote:IP:PORT Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms lastIO=2 ms isOpen=false.onExceptionWrite exception: {} java.io.IOException: Broken pipe
- এই দুটি এক্সেপশনই নির্দেশ করে যে, মেসেজ প্রসেসর যখন ব্যাকএন্ড সার্ভারে রিকোয়েস্ট পেলোড লিখছিল, ঠিক সেই সময়ে ব্যাকএন্ড সার্ভার কর্তৃক কানেকশনটি সময়ের আগেই বন্ধ করে দেওয়া হয়। ফলে, মেসেজ প্রসেসর
java.io.IOException: Broken pipeএক্সেপশনটি থ্রো করে। -
Remote: IP : PORTদ্বারা নির্ধারিত ব্যাকএন্ড সার্ভারের আইপি অ্যাড্রেস এবং পোর্ট নম্বর বোঝানো হয়। - উপরের ত্রুটি বার্তায়
bytesWritten=76295অ্যাট্রিবিউটটি নির্দেশ করে যে, সংযোগটি নির্ধারিত সময়ের আগেই বন্ধ হয়ে যাওয়ার সময় মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে76295বাইটের একটি পেলোড পাঠিয়েছিল। -
bytesRead=0অ্যাট্রিবিউটটি নির্দেশ করে যে মেসেজ প্রসেসর ব্যাকএন্ড সার্ভার থেকে কোনো ডেটা (রেসপন্স) পায়নি। - এই সমস্যাটি আরও খতিয়ে দেখতে, ব্যাকএন্ড সার্ভার অথবা মেসেজ প্রসেসর থেকে একটি
tcpdumpসংগ্রহ করুন এবং নিচে বর্ণিত পদ্ধতি অনুযায়ী তা বিশ্লেষণ করুন।
tcpdump ব্যবহার করে
নিম্নলিখিত কমান্ডগুলো ব্যবহার করে ব্যাকএন্ড সার্ভার অথবা মেসেজ প্রসেসরে একটি
tcpdumpক্যাপচার করুন:ব্যাকএন্ড সার্ভারে
tcpdumpসংগ্রহ করার কমান্ড:tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
মেসেজ প্রসেসরে
tcpdumpসংগ্রহ করার কমান্ড:tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
- ক্যাপচার করা
tcpdumpবিশ্লেষণ করুন:tcpdump আউটপুটের নমুনা (মেসেজ প্রসেসরে সংগৃহীত):

উপরের
tcpdumpটিতে আপনি নিম্নলিখিত বিষয়গুলো দেখতে পাবেন:- প্যাকেট
4এ, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে একটিPOSTঅনুরোধ পাঠিয়েছে। - প্যাকেট
5,8,9,10ও11-তে মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে রিকোয়েস্ট পেলোড পাঠানো অব্যাহত রেখেছিল। - প্যাকেট
6এবং7এ, ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের কাছ থেকে প্রাপ্ত রিকোয়েস্ট পেলোডের একটি অংশের জন্যACKদিয়ে সাড়া দিয়েছে। - তবে,
12প্যাকেটে, প্রাপ্ত অ্যাপ্লিকেশন ডেটা প্যাকেটগুলোর জন্যACKপাঠিয়ে এবং পরবর্তীতে রেসপন্স পেলোড পাঠানোর পরিবর্তে, ব্যাকএন্ড সার্ভারটি একটিFIN ACKপাঠিয়ে সংযোগটি বন্ধ করার প্রক্রিয়া শুরু করে। - এতে পরিষ্কারভাবে দেখা যাচ্ছে যে, মেসেজ প্রসেসর যখন রিকোয়েস্ট পেলোড পাঠাচ্ছিল, ঠিক সেই সময়েই ব্যাকএন্ড সার্ভারটি সংযোগটি অসময়ে বন্ধ করে দিচ্ছে।
- এর ফলে মেসেজ প্রসেসর একটি
IOException: Broken Pipeত্রুটি রেকর্ড করে এবং ক্লায়েন্টকে একটি503ফেরত পাঠায়।
- প্যাকেট
সমাধান
- ব্যাকএন্ড সার্ভার সাইডে সময়ের আগে সংযোগ বিচ্ছিন্ন হওয়ার সমস্যাটি বিশ্লেষণ ও সমাধান করার জন্য আপনার অ্যাপ্লিকেশন এবং নেটওয়ার্কিং টিম অথবা উভয়ের সাথেই কাজ করুন।
- নিশ্চিত করুন যে সম্পূর্ণ অনুরোধ পেলোড গ্রহণ করার আগে ব্যাকএন্ড সার্ভার অ্যাপ্লিকেশনটি টাইম আউট হচ্ছে না বা সংযোগ রিসেট করছে না।
- Apigee এবং ব্যাকএন্ড সার্ভারের মধ্যে যদি কোনো মধ্যবর্তী নেটওয়ার্কিং ডিভাইস বা লেয়ার থাকে, তাহলে নিশ্চিত করুন যে সম্পূর্ণ রিকোয়েস্ট পেলোড গৃহীত হওয়ার আগেই সেগুলোর টাইম আউট হয়ে যাচ্ছে না।
যদি সমস্যাটি এখনও থেকে যায়, তাহলে 'অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন' অংশে যান।
রোগ নির্ণয়ের তথ্য অবশ্যই সংগ্রহ করতে হবে
উপরের নির্দেশাবলী অনুসরণ করার পরেও যদি সমস্যাটি থেকে যায়, তাহলে নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন এবং তারপর Apigee Edge Support-এর সাথে যোগাযোগ করুন:
আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্যগুলো প্রদান করুন:
- সংস্থার নাম
- পরিবেশের নাম
- এপিআই প্রক্সি নাম
-
503ত্রুটিটি পুনরুৎপাদন করার জন্য সম্পূর্ণcurlকমান্ডটি ব্যবহার করুন। -
503 Service Unavailableত্রুটিসহ অনুরোধটি ধারণকারী ট্রেস ফাইল - যদি বর্তমানে
503ত্রুটি না ঘটে থাকে, তবে অতীতে যখন503ত্রুটি ঘটেছিল সেই সময়কাল এবং টাইমজোনের তথ্য প্রদান করুন।
আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্যগুলো প্রদান করুন:
- ব্যর্থ অনুরোধগুলির জন্য সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে।
- যেসব সংস্থা, পরিবেশের নাম এবং এপিআই প্রক্সি নামের ক্ষেত্রে আপনি
503ত্রুটি দেখতে পাচ্ছেন - এপিআই প্রক্সি বান্ডেল
-
503 Service Unavailableত্রুটিসহ অনুরোধগুলো ধারণকারী ট্রেস ফাইল - NGINX অ্যাক্সেস লগ
/opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log - মেসেজ প্রসেসর লগ
/opt/apigee/var/log/edge-message-processor/logs/system.log - টাইমজোন তথ্যসহ সেই সময়কাল যখন
503ত্রুটিগুলো ঘটেছিল। - ত্রুটিটি ঘটার সময় মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভার থেকে
Tcpdumpsসংগ্রহ করা হয়েছিল।