আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।
লক্ষণ
ক্লায়েন্ট অ্যাপ্লিকেশনটি একটি 502 ব্যাড গেটওয়ে ত্রুটি পায়। যখন মেসেজ প্রসেসর কোনো ব্যাকএন্ড সার্ভার থেকে সাড়া পায় না, তখন এটি ক্লায়েন্ট অ্যাপ্লিকেশনকে এই ত্রুটিটি ফেরত পাঠায়।
ত্রুটি বার্তা
ক্লায়েন্ট অ্যাপ্লিকেশনটি নিম্নলিখিত প্রতিক্রিয়া কোডটি গ্রহণ করে:
HTTP/1.1 502 Bad Gateway
এছাড়াও, আপনি নিম্নলিখিত ত্রুটি বার্তাটি দেখতে পারেন:
{
"fault": {
"faultstring":"Bad Gateway",
"detail":{
"errorcode":"messaging.adaptors.http.flow.BadGateway"
}
}
}
সম্ভাব্য কারণ
এই সমস্যার সম্ভাব্য কারণগুলো নিম্নলিখিত সারণিতে তালিকাভুক্ত করা হলো:
| কারণ | বর্ণনা | সমস্যা সমাধানের পদক্ষেপগুলি সম্পাদন করা যেতে পারে |
| TLS/SSL হ্যান্ডশেক টাইমআউট | মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভারের মধ্যে TLS/SSL হ্যান্ডশেক চলাকালীন একটি টাইমআউট ঘটে। | এজ প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারীরা |
কারণ: TLS/SSL হ্যান্ডশেক টাইমআউট
Apigee Edge-এ, আপনি Edge Message Processor এবং ব্যাকএন্ড সার্ভারের মধ্যে TLS কমিউনিকেশন চালু করার জন্য ব্যাকএন্ড সার্ভারের সাথে একটি TLS/SSL কানেকশন সেট আপ করতে পারেন।
একটি TLS/SSL হ্যান্ডশেকে একাধিক ধাপ জড়িত থাকে। এই ত্রুটিটি সাধারণত তখন ঘটে যখন মেসেজ প্রসেসর এবং একটি ব্যাকএন্ড সার্ভারের মধ্যে TLS/SSL হ্যান্ডশেকটি টাইম আউট হয়ে যায়।
রোগ নির্ণয়
এই বিভাগে TLS/SSL হ্যান্ডশেক টাইমআউট সঠিকভাবে নির্ণয় করার পদ্ধতি ব্যাখ্যা করা হয়েছে। এজ প্রাইভেট ক্লাউড এবং পাবলিক ক্লাউডের জন্য নির্দেশাবলী তালিকাভুক্ত করা হয়েছে।
ট্রেস সেশন আউটপুট তদন্ত করুন
নিম্নলিখিত ধাপগুলিতে Apigee Edge Trace টুল ব্যবহার করে সমস্যাটির প্রাথমিক নির্ণয় করার পদ্ধতি ব্যাখ্যা করা হয়েছে।
- Edge UI-তে, প্রভাবিত API প্রক্সির জন্য একটি ট্রেস সেশন সক্রিয় করুন।
যদি ব্যর্থ হওয়া এপিআই অনুরোধের ট্রেসে নিম্নলিখিতটি দেখা যায়, তাহলে সম্ভবত একটি TLS/SSL হ্যান্ডশেক টাইমআউট ত্রুটি ঘটেছে। এই ত্রুটির সম্ভাব্য কারণ হলো, ব্যাকএন্ড সার্ভারের ফায়ারওয়াল Apigee থেকে আসা ট্র্যাফিককে ব্লক করছে।
- মেসেজ প্রসেসরে সেট করা ডিফল্ট টাইমআউট পিরিয়ড ৫৫ সেকেন্ড পরে ৫০২ ব্যাড গেটওয়ে এররটি দেখা দেয় কিনা তা নির্ণয় করুন। যদি দেখেন যে এররটি ৫৫ সেকেন্ড পরে ঘটেছে, তবে এটি আপনাকে বলে দেবে যে টাইমআউটই সম্ভবত সমস্যাটির কারণ ছিল।
- ত্রুটিটি messaging.adaptors.http.BadGateway এই ফল্টটি দেখাচ্ছে কিনা তা নির্ণয় করুন। আবারও বলছি, এই ত্রুটিটি সাধারণত একটি টাইমআউট ঘটার ইঙ্গিত দেয়।
আপনি যদি এজ প্রাইভেট ক্লাউড ব্যবহার করেন, তাহলে নিচে দেখানো ট্রেস আউটপুটে থাকা X-Apigee.Message-ID ফিল্ডের মানটি নোট করুন। একজন প্রাইভেট ক্লাউড ব্যবহারকারী এই আইডি মানটি ব্যবহার করে পরবর্তী ট্রাবলশুটিং করতে পারেন, যা পরে ব্যাখ্যা করা হয়েছে।
ট্রেস পাথে থাকা অ্যানালিটিক্স ডেটা রেকর্ডেড আইকনটিতে ক্লিক করুন:

নিচে স্ক্রল করুন এবং X-Apigee.Message-ID নামক ফিল্ডটির মান লক্ষ্য করুন।
TLS/SSL হ্যান্ডশেক টাইমআউটই ত্রুটির কারণ ছিল কিনা তা নিশ্চিত করতে, আপনি পাবলিক ক্লাউড নাকি প্রাইভেট ক্লাউডে আছেন তার উপর নির্ভর করে নিম্নলিখিত বিভাগগুলির ধাপগুলি অনুসরণ করুন।
শুধুমাত্র এজ প্রাইভেট ক্লাউড ব্যবহারকারীদের জন্য অতিরিক্ত ডায়াগনস্টিক পদক্ষেপ
আপনি যদি Apigee Edge Private Cloud ব্যবহার করেন, তাহলে হ্যান্ডশেক ত্রুটির কারণ যাচাই করতে নিম্নলিখিত ধাপগুলো অনুসরণ করতে পারেন। এই ধাপে, প্রাসঙ্গিক তথ্যের জন্য আপনি Message Processor লগ ফাইলটি পরীক্ষা করবেন। আপনি যদি Edge Public Cloud ব্যবহার করেন, তাহলে এই অংশটি বাদ দিয়ে Private এবং Public Cloud ব্যবহারকারীদের জন্য আরও ডায়াগনস্টিক পদক্ষেপ অংশে যেতে পারেন।
প্রতিটি মেসেজ প্রসেসর থেকে
telnetকমান্ড ব্যবহার করে সরাসরি নির্দিষ্ট ব্যাকএন্ড সার্ভারে সংযোগ করা যায় কিনা তা পরীক্ষা করুন:যদি ব্যাকএন্ড সার্ভারটি একটিমাত্র আইপি অ্যাড্রেসে রিজলভ হয়, তাহলে এই কমান্ডটি ব্যবহার করুন:
telnet BackendServer-IPaddress 443
যদি ব্যাকএন্ড সার্ভারটি একাধিক আইপি অ্যাড্রেসে রিজলভ হয়, তাহলে নিচে দেখানো অনুযায়ী টেলনেট কমান্ডে ব্যাকএন্ড সার্ভারের হোস্টনেম ব্যবহার করুন:
telnet BackendServer-HostName 443
যদি আপনি কোনো ত্রুটি ছাড়াই ব্যাকএন্ড সার্ভারে সংযোগ করতে পারেন, তাহলে পরবর্তী ধাপে যান।
যদি
telnetকমান্ড ব্যর্থ হয়, তাহলে মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভারের মধ্যে সংযোগ পরীক্ষা করার জন্য আপনাকে আপনার নেটওয়ার্ক টিমের সাথে কাজ করতে হবে।হ্যান্ডশেক ব্যর্থতার প্রমাণের জন্য মেসেজ প্রসেসর লগ ফাইলটি পরীক্ষা করুন। ফাইলটি খুলুন:
/opt/apigee/var/log/edge-message-processor/system.logএবং অনন্য মেসেজ আইডিটি (ট্রেস ফাইলে পাওয়া X-Apigee.Message-ID- এর মান) অনুসন্ধান করুন। নিচে দেখানো অনুযায়ী, মেসেজ আইডিটির সাথে সম্পর্কিত কোনো হ্যান্ডশেক ত্রুটির বার্তা দেখতে পাচ্ছেন কিনা তা নির্ধারণ করুন:
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443 Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms isOpen=true handshake timeout
মেসেজ প্রসেসরের লগ ফাইলে এই ত্রুটিটি দেখতে পেলে, আরও তদন্ত চালিয়ে যান। Edge Private এবং Public Cloud ব্যবহারকারীদের জন্য পরবর্তী ডায়াগনস্টিক পদক্ষেপ- এ যান।
যদি আপনি লগ ফাইলে হ্যান্ডশেক বার্তাটি দেখতে না পান, তাহলে অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন (Must Gather Diagnostic Information) -এ যান।
এজ প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারীদের জন্য আরও ডায়াগনস্টিক পদক্ষেপ
সমস্যাটি আরও সুনির্দিষ্টভাবে চিহ্নিত করার জন্য, আপনি tcpdump টুল ব্যবহার করে TCP/IP প্যাকেট বিশ্লেষণ করে নিশ্চিত হতে পারেন যে TLS/SSL হ্যান্ডশেকের সময় কোনো টাইমআউট ঘটেছে কিনা।
- আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে আপনি ব্যাকএন্ড সার্ভার বা মেসেজ প্রসেসরে TCP/IP প্যাকেটগুলো ক্যাপচার করতে পারেন। তবে ব্যাকএন্ড সার্ভারেই প্যাকেটগুলো ক্যাপচার করা শ্রেয়, কারণ সেখানেই প্যাকেটগুলো ডিক্রিপ্ট করা হয়।
- আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনার মেসেজ প্রসেসরে অ্যাক্সেস নেই; তবে, ব্যাকএন্ড সার্ভারে TCP/IP প্যাকেট ক্যাপচার করলে সমস্যাটি চিহ্নিত করতে সাহায্য হতে পারে।
কোথায় TCP/IP প্যাকেট ক্যাপচার করবেন তা ঠিক করার পর, TCP/IP প্যাকেট ক্যাপচার করতে নিম্নলিখিত tcpdump কমান্ডটি ব্যবহার করুন।
tcpdump -i any -s 0 host <IP address> -w <File name>আপনি যদি ব্যাকএন্ড সার্ভারে TCP/IP প্যাকেট গ্রহণ করেন, তাহলে
tcpdumpকমান্ডে মেসেজ প্রসেসরের পাবলিক আইপি অ্যাড্রেস ব্যবহার করুন। ব্যাকএন্ড সার্ভারের ট্র্যাফিক পরীক্ষা করার জন্য কমান্ডটি ব্যবহারের বিষয়ে সাহায্যের জন্য, tcpdump দেখুন।আপনি যদি মেসেজ প্রসেসরে TCP/IP প্যাকেট গ্রহণ করেন, তাহলে
tcpdumpকমান্ডে ব্যাকএন্ড সার্ভারের পাবলিক আইপি অ্যাড্রেস ব্যবহার করুন। মেসেজ প্রসেসরের ট্র্যাফিক পরীক্ষা করার জন্য কমান্ডটি ব্যবহারের বিষয়ে সাহায্যের জন্য, tcpdump দেখুন।যদি ব্যাকএন্ড সার্ভার/মেসেজ প্রসেসরের একাধিক আইপি অ্যাড্রেস থাকে, তাহলে আপনাকে অন্যভাবে
tcpdumpকমান্ড ব্যবহার করে দেখতে হবে। এই টুলটি এবং এর অন্যান্য সংস্করণ সম্পর্কে আরও তথ্যের জন্য tcpdump দেখুন।
Wireshark টুল বা অনুরূপ কোনো টুল ব্যবহার করে TCP/IP প্যাকেটগুলো বিশ্লেষণ করুন। নিচের স্ক্রিনশটটিতে Wireshark-এ TCP/IP প্যাকেটগুলো দেখানো হয়েছে।

Wireshark আউটপুটে লক্ষ্য করুন যে, ত্রিমুখী TCP হ্যান্ডশেকটি প্রথম ৩টি প্যাকেটের মধ্যেই সফলভাবে সম্পন্ন হয়।
এরপর মেসেজ প্রসেসর ৪ নং প্যাকেটে "ক্লায়েন্ট হ্যালো" বার্তাটি পাঠায়।
ব্যাকএন্ড সার্ভার থেকে কোনো স্বীকৃতি বার্তা না পাওয়ায়, মেসেজ প্রসেসর একটি পূর্বনির্ধারিত সময় অপেক্ষা করার পর ৫, ৬ এবং ৭ নম্বর প্যাকেটে "ক্লায়েন্ট হ্যালো" বার্তাটি একাধিকবার পুনঃপ্রেরণ করে।
মেসেজ প্রসেসর ৩ বার চেষ্টা করার পরেও কোনো স্বীকৃতি বার্তা না পেলে, সংযোগটি বন্ধ করার ইঙ্গিত দিতে এটি ব্যাকএন্ড সার্ভারে FIN, ACK বার্তা পাঠায়।
আপনি উদাহরণ ওয়্যারশার্ক সেশনে যেমন দেখিয়েছেন, ব্যাকএন্ডের সাথে সংযোগ সফল হয়েছে (ধাপ #১), তবে SSL হ্যান্ডশেকটি টাইম আউট হয়ে গেছে কারণ ব্যাকএন্ড সার্ভারটি কখনও সাড়া দেয়নি।
আপনি যদি এই প্লেবুকের সমস্যা সমাধানের ধাপগুলো অনুসরণ করে থাকেন এবং নির্ধারণ করে থাকেন যে টাইমআউটের কারণে TLS/SSL হ্যান্ডশেক ত্রুটিটি ঘটেছে, তাহলে সমাধান (Resolution) বিভাগে যান।
একটি সমস্যা শনাক্ত করতে এপিআই মনিটরিং ব্যবহার করা
এপিআই মনিটরিং আপনাকে ত্রুটি, পারফরম্যান্স, এবং লেটেন্সি সমস্যা ও সেগুলোর উৎস—যেমন ডেভেলপার অ্যাপ, এপিআই প্রক্সি, ব্যাকএন্ড টার্গেট বা এপিআই প্ল্যাটফর্ম—দ্রুত শনাক্ত করে সমস্যাযুক্ত এলাকাগুলো চিহ্নিত করতে সক্ষম করে।
এপিআই মনিটরিং ব্যবহার করে আপনার এপিআই-এর 5xx সমস্যাগুলো কীভাবে সমাধান করবেন, তা দেখানোর জন্য একটি নমুনা পরিস্থিতি ধাপে ধাপে অনুসরণ করুন । উদাহরণস্বরূপ, আপনি হয়তো একটি অ্যালার্ট সেট আপ করতে চাইতে পারেন, যাতে messaging.adaptors.http.BadGateway ফল্টের সংখ্যা একটি নির্দিষ্ট সীমা অতিক্রম করলে আপনাকে জানানো হয়।
সমাধান
সাধারণত ব্যাকএন্ড সার্ভারের ফায়ারওয়াল সীমাবদ্ধতার কারণে SSL হ্যান্ডশেক টাইমআউট ঘটে, যা Apigee Edge থেকে আসা ট্র্যাফিককে ব্লক করে। যদি আপনি ডায়াগনস্টিক ধাপগুলো অনুসরণ করে নির্ধারণ করেন যে হ্যান্ডশেক ত্রুটির কারণ একটি টাইমআউট, তবে কারণটি শনাক্ত করতে এবং ফায়ারওয়ালের সীমাবদ্ধতাগুলো ঠিক করার জন্য আপনাকে আপনার নেটওয়ার্ক টিমের সাথে যোগাযোগ করতে হবে।
মনে রাখবেন যে ফায়ারওয়ালের বিধিনিষেধ বিভিন্ন নেটওয়ার্ক লেয়ারে আরোপ করা হতে পারে। Apigee Edge এবং ব্যাকএন্ড সার্ভারের মধ্যে নির্বিঘ্ন ট্র্যাফিক প্রবাহ নিশ্চিত করার জন্য, মেসেজ প্রসেসর আইপি-গুলোর ক্ষেত্রে সমস্ত নেটওয়ার্ক লেয়ারের বিধিনিষেধ অপসারণ করা হয়েছে কিনা তা নিশ্চিত করা গুরুত্বপূর্ণ।
যদি কোনো ফায়ারওয়াল বিধিনিষেধ না থাকে এবং/অথবা সমস্যাটি তারপরেও থেকে যায়, তাহলে 'অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন' (Must Gather Diagnostic Information) অংশে যান।
রোগ নির্ণয়ের তথ্য অবশ্যই সংগ্রহ করতে হবে
উপরের নির্দেশাবলী অনুসরণ করার পরেও যদি সমস্যাটি থেকে যায়, তাহলে অনুগ্রহ করে নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন। Apigee Edge Support-এর সাথে যোগাযোগ করুন এবং সেগুলি তাদের সাথে শেয়ার করুন:
- আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্যগুলো প্রদান করুন:
- সংস্থার নাম
- পরিবেশের নাম
- এপিআই প্রক্সি নাম
- ত্রুটিটি পুনরুৎপাদন করতে সম্পূর্ণ কার্ল (curl) কমান্ডটি ব্যবহার করুন।
- ত্রুটি দেখানো ট্রেস ফাইল
- ব্যাকএন্ড সার্ভারে ক্যাপচার করা TCP/IP প্যাকেট
- আপনি যদি প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
- সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে
- এপিআই প্রক্সি বান্ডেল
- ত্রুটি দেখানো ট্রেস ফাইল
- মেসেজ প্রসেসর লগ /opt/apigee/var/log/edge-message-processor/logs/system.log
- ব্যাকএন্ড সার্ভার বা মেসেজ প্রসেসরে ক্যাপচার করা TCP/IP প্যাকেট।
- এই প্লেবুকের কোন কোন অংশ আপনি চেষ্টা করেছেন সে সম্পর্কিত বিবরণ এবং অন্য কোনো তথ্য যা আমাদের এই সমস্যার সমাধান দ্রুত করতে সাহায্য করবে, তা প্রদান করুন।