502 খারাপ গেটওয়ে টাইমআউট ত্রুটি৷

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

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি একটি 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 এজে, আপনি এজ মেসেজ প্রসেসর এবং একটি ব্যাকএন্ড সার্ভারের মধ্যে TLS যোগাযোগ সক্ষম করতে ব্যাকএন্ড সার্ভারে একটি TLS/SSL সংযোগ সেট আপ করতে পারেন।

একটি TLS/SSL হ্যান্ডশেক একাধিক ধাপ জড়িত। এই ত্রুটিটি সাধারণত ঘটে যখন বার্তা প্রসেসর এবং একটি ব্যাকএন্ড সার্ভারের মধ্যে TLS/SSL হ্যান্ডশেক সময় শেষ হয়ে যায়।

রোগ নির্ণয়

এই বিভাগটি ব্যাখ্যা করে কিভাবে সঠিকভাবে একটি TLS/SSL হ্যান্ডশেক টাইমআউট নির্ণয় করা যায়। এজ প্রাইভেট ক্লাউড এবং পাবলিক ক্লাউডের জন্য নির্দেশাবলী তালিকাভুক্ত করা হয়েছে।

ট্রেস সেশন আউটপুট তদন্ত

Apigee Edge Trace টুল ব্যবহার করে কিভাবে সমস্যার প্রাথমিক নির্ণয় করতে হয় তা নিম্নলিখিত ধাপগুলো ব্যাখ্যা করে।

  1. এজ UI-তে, প্রভাবিত API প্রক্সির জন্য একটি ট্রেস সেশন সক্রিয় করুন।

  2. যদি ব্যর্থ API অনুরোধের ট্রেস নিম্নলিখিতগুলি দেখায়, তাহলে সম্ভবত একটি TLS/SSL হ্যান্ডশেক টাইমআউট ত্রুটি ঘটেছে৷ ত্রুটির সম্ভাব্য কারণ হল ব্যাকএন্ড সার্ভার ফায়ারওয়াল Apigee থেকে ট্রাফিক ব্লক করছে।

    1. 502 খারাপ গেটওয়ে ত্রুটি 55 সেকেন্ডের পরে ঘটে কিনা তা নির্ধারণ করুন, যা বার্তা প্রসেসরে সেট করা ডিফল্ট সময়সীমা। আপনি যদি দেখেন যে ত্রুটিটি 55 সেকেন্ড পরে ঘটেছে, এটি আপনাকে বলে যে একটি টাইমআউট সমস্যার সম্ভাব্য কারণ ছিল।
    2. ত্রুটিটি ত্রুটি দেখায় কিনা তা নির্ধারণ করুন: messaging.adaptors.http.BadGateway । আবার, এই ত্রুটি সাধারণত একটি টাইমআউট ঘটেছে নির্দেশ করে।

    3. আপনি যদি এজ প্রাইভেট ক্লাউডে থাকেন তবে নিচের মতো ট্রেস আউটপুটে X-Apigee.Message-ID ক্ষেত্রের মান নোট করুন। একজন প্রাইভেট ক্লাউড ব্যবহারকারী এই আইডি মানটি আরও সমস্যা সমাধানের জন্য ব্যবহার করতে পারেন, যেমনটি পরে ব্যাখ্যা করা হয়েছে।

      1. ট্রেস পাথে Analytics ডেটা রেকর্ড করা আইকনে ক্লিক করুন:

      2. নিচে স্ক্রোল করুন এবং X-Apigee.Message-ID নামক ক্ষেত্রের মানটি নোট করুন।

TLS/SSL হ্যান্ডশেক টাইমআউট ত্রুটির কারণ ছিল তা নিশ্চিত করতে, আপনি পাবলিক ক্লাউড বা প্রাইভেট ক্লাউডে আছেন কিনা তার উপর নির্ভর করে নিম্নলিখিত বিভাগগুলির পদক্ষেপগুলি অনুসরণ করুন৷

শুধুমাত্র এজ প্রাইভেট ক্লাউড ব্যবহারকারীদের জন্য অতিরিক্ত ডায়গনিস্টিক পদক্ষেপ

আপনি যদি Apigee Edge প্রাইভেট ক্লাউডে থাকেন, তাহলে হ্যান্ডশেক ত্রুটির কারণ যাচাই করতে আপনি নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করতে পারেন৷ এই ধাপে, আপনি প্রাসঙ্গিক তথ্যের জন্য বার্তা প্রসেসর লগ ফাইল পরিদর্শন করুন। আপনি যদি এজ পাবলিক ক্লাউডে থাকেন তবে আপনি এই বিভাগটি এড়িয়ে যেতে পারেন এবং প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারীদের জন্য আরও ডায়াগনস্টিক ধাপে যেতে পারেন।

  1. আপনি telnet কমান্ড ব্যবহার করে প্রতিটি মেসেজ প্রসেসর থেকে সরাসরি নির্দিষ্ট ব্যাকএন্ড সার্ভারের সাথে সংযোগ করতে পারেন কিনা তা পরীক্ষা করুন:

    1. যদি ব্যাকএন্ড সার্ভার একটি একক আইপি ঠিকানার সমাধান করে, তাহলে এই কমান্ডটি ব্যবহার করুন:

      telnet BackendServer-IPaddress 443

    2. যদি ব্যাকএন্ড সার্ভার একাধিক আইপি অ্যাড্রেসের সমাধান করে, তাহলে টেলনেট কমান্ডে ব্যাকএন্ড সার্ভারের হোস্টনামটি নীচে দেখানো হিসাবে ব্যবহার করুন:

      telnet BackendServer-HostName 443

    আপনি যদি কোনো ত্রুটি ছাড়াই ব্যাকএন্ড সার্ভারের সাথে সংযোগ করতে সক্ষম হন, তাহলে পরবর্তী ধাপে যান।

    telnet কমান্ড ব্যর্থ হলে, বার্তা প্রসেসর এবং ব্যাকএন্ড সার্ভারের মধ্যে সংযোগ পরীক্ষা করতে আপনাকে আপনার নেটওয়ার্ক দলের সাথে কাজ করতে হবে।

  2. হ্যান্ডশেক ব্যর্থতার প্রমাণের জন্য বার্তা প্রসেসর লগ ফাইলটি পরীক্ষা করুন। ফাইল খুলুন:

    /opt/apigee/var/log/edge-message-processor/system.log

    এবং অনন্য বার্তা আইডি ( X-Apigee.Message-ID এর মান যা আপনি ট্রেস ফাইলে খুঁজে পেয়েছেন) অনুসন্ধান করুন। নীচে দেখানো হিসাবে আপনি বার্তা 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

আপনি যদি বার্তা প্রসেসরের লগ ফাইলে এই ত্রুটিটি দেখতে পান তবে আরও তদন্ত চালিয়ে যান। এজ প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারীদের জন্য আরও ডায়াগনস্টিক ধাপে যান।

আপনি যদি লগ ফাইলে হ্যান্ডশেক বার্তাটি দেখতে না পান, তাহলে অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন- এ যান৷

এজ প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারীদের জন্য আরও ডায়াগনস্টিক পদক্ষেপ

সমস্যাটি আরও চিহ্নিত করার জন্য, আপনি টিসিপি/আইপি প্যাকেট বিশ্লেষণ করতে tcpdump টুল ব্যবহার করতে পারেন যাতে TLS/SSL হ্যান্ডশেকের সময় একটি টাইমআউট হয়েছে কিনা তা নিশ্চিত করতে।

  1. আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন, আপনি ব্যাকএন্ড সার্ভার বা বার্তা প্রসেসরে TCP/IP প্যাকেটগুলি ক্যাপচার করতে পারেন। বিশেষভাবে, ব্যাকএন্ড সার্ভারে তাদের ক্যাপচার করুন, কারণ প্যাকেটগুলি ব্যাকএন্ড সার্ভারে ডিক্রিপ্ট করা হয়।
  2. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, আপনার বার্তা প্রসেসরে অ্যাক্সেস নেই; যাইহোক, ব্যাকএন্ড সার্ভারে TCP/IP প্যাকেটগুলি ক্যাপচার করা একটি সমস্যা চিহ্নিত করতে সাহায্য করতে পারে।

  3. TCP/IP প্যাকেটগুলি কোথায় ক্যাপচার করতে হবে তা স্থির করার পরে, TCP/IP প্যাকেটগুলি ক্যাপচার করতে নিম্নলিখিত tcpdump কমান্ডটি ব্যবহার করুন।

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • আপনি যদি ব্যাকএন্ড সার্ভারে TCP/IP প্যাকেটগুলি নিচ্ছেন, তাহলে tcpdump কমান্ডে মেসেজ প্রসেসরের সর্বজনীন IP ঠিকানাটি ব্যবহার করুন। ব্যাকএন্ড সার্ভার ট্রাফিক পরীক্ষা করার জন্য কমান্ড ব্যবহার করে সাহায্যের জন্য, tcpdump দেখুন।

    • আপনি যদি বার্তা প্রসেসরে TCP/IP প্যাকেটগুলি নিচ্ছেন, তাহলে tcpdump কমান্ডে ব্যাকএন্ড সার্ভারের সর্বজনীন IP ঠিকানা ব্যবহার করুন। বার্তা প্রসেসর ট্রাফিক পরীক্ষা করার জন্য কমান্ড ব্যবহার করে সাহায্যের জন্য, tcpdump দেখুন।

    • যদি ব্যাকএন্ড সার্ভার/মেসেজ প্রসেসরের জন্য একাধিক আইপি ঠিকানা থাকে, তাহলে আপনাকে অন্য tcpdump কমান্ড ব্যবহার করে দেখতে হবে। এই টুল সম্পর্কে আরও তথ্যের জন্য এবং এই কমান্ডের অন্যান্য রূপের জন্য tcpdump পড়ুন।

  4. Wireshark টুল বা অনুরূপ টুল ব্যবহার করে TCP/IP প্যাকেট বিশ্লেষণ করুন। নিম্নলিখিত স্ক্রিনশটটি ওয়্যারশার্ক-এ TCP/IP প্যাকেটগুলি দেখায়।

  5. Wireshark আউটপুটে লক্ষ্য করুন, প্রথম 3টি প্যাকেটে ত্রিমুখী TCP হ্যান্ডশেক সফলভাবে সম্পন্ন হয়।

  6. মেসেজ প্রসেসর তারপর প্যাকেট #4 এ "ক্লায়েন্ট হ্যালো" বার্তা পাঠায়।

  7. ব্যাকএন্ড সার্ভার থেকে কোনো স্বীকৃতি না থাকায়, মেসেজ প্রসেসর পূর্বনির্ধারিত ব্যবধানের জন্য অপেক্ষা করার পর 5, 6 এবং 7 প্যাকেটে একাধিকবার "ক্লায়েন্ট হ্যালো" বার্তাটি পুনরায় প্রেরণ করে।

  8. যখন মেসেজ প্রসেসর 3 বার চেষ্টা করার পরেও কোনো স্বীকৃতি পায় না, তখন এটি সংযোগটি বন্ধ করছে তা নির্দেশ করার জন্য এটি ব্যাকএন্ড সার্ভারে FIN, ACK বার্তা পাঠায়।

  9. আপনি যেমন Wireshark সেশনের উদাহরণে দেখিয়েছেন, ব্যাকএন্ডের সাথে সংযোগ সফল হয়েছে (ধাপ #1), তবে, SSL হ্যান্ডশেকের সময় শেষ হয়েছে কারণ ব্যাকএন্ড সার্ভার কখনই সাড়া দেয়নি।

আপনি যদি এই প্লেবুকে সমস্যা সমাধানের পদক্ষেপগুলি সম্পাদন করেন এবং নির্ধারণ করেন যে একটি টাইমআউটের কারণে TLS/SSL হ্যান্ডশেক ত্রুটি হয়েছে, তাহলে রেজোলিউশন বিভাগে যান৷

একটি সমস্যা সনাক্ত করতে API মনিটরিং ব্যবহার করে

API মনিটরিং আপনাকে ত্রুটি, কর্মক্ষমতা, এবং লেটেন্সি সমস্যা এবং তাদের উৎস যেমন ডেভেলপার অ্যাপস, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম নির্ণয় করতে সমস্যা এলাকাগুলিকে দ্রুত বিচ্ছিন্ন করতে সক্ষম করে।

এপিআই মনিটরিং ব্যবহার করে আপনার এপিআইগুলির সাথে 5xx সমস্যাগুলি কীভাবে সমাধান করা যায় তা প্রদর্শন করে এমন একটি নমুনা দৃশ্যের মধ্য দিয়ে যান । উদাহরণস্বরূপ, আপনি একটি সতর্কতা সেট আপ করতে চাইতে পারেন যখন messaging.adaptors.http.BadGateway ফল্টের সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করে তখন বিজ্ঞপ্তি পাওয়ার জন্য।

রেজোলিউশন

ব্যাকএন্ড সার্ভারে ফায়ারওয়াল বিধিনিষেধের কারণে সাধারণত SSL হ্যান্ডশেক টাইমআউট ঘটে যা Apigee Edge থেকে ট্র্যাফিক ব্লক করে। আপনি যদি ডায়গনিস্টিক পদক্ষেপগুলি অনুসরণ করেন এবং নির্ধারণ করেন যে হ্যান্ডশেক ত্রুটির কারণটি একটি সময়সীমা, তাহলে আপনাকে কারণ সনাক্ত করতে এবং ফায়ারওয়াল বিধিনিষেধ ঠিক করতে আপনার নেটওয়ার্ক টিমকে নিযুক্ত করতে হবে৷

নোট করুন যে ফায়ারওয়াল সীমাবদ্ধতা বিভিন্ন নেটওয়ার্ক স্তরে আরোপ করা যেতে পারে। Apigee Edge এবং ব্যাকএন্ড সার্ভারের মধ্যে মসৃণ ট্র্যাফিক প্রবাহ নিশ্চিত করতে বার্তা প্রসেসর আইপি সম্পর্কিত সমস্ত নেটওয়ার্ক স্তরের সীমাবদ্ধতাগুলি সরানো হয়েছে তা নিশ্চিত করা গুরুত্বপূর্ণ।

যদি কোনো ফায়ারওয়াল বিধিনিষেধ না থাকে এবং/অথবা সমস্যাটি এখনও থেকে যায়, তাহলে Must Gather Diagnostic Information এ যান।

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

উপরের নির্দেশাবলী অনুসরণ করার পরেও যদি সমস্যাটি থেকে যায়, অনুগ্রহ করে নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন। এপিজি এজ সাপোর্টে যোগাযোগ করুন এবং শেয়ার করুন:

  1. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
    1. প্রতিষ্ঠানের নাম
    2. পরিবেশের নাম
    3. API প্রক্সি নাম
    4. ত্রুটিটি পুনরুত্পাদন করতে কার্ল কমান্ডটি সম্পূর্ণ করুন
    5. ট্রেস ফাইল ত্রুটি দেখাচ্ছে
    6. TCP/IP প্যাকেট ব্যাকএন্ড সার্ভারে ক্যাপচার করা হয়েছে
  2. আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন তবে নিম্নলিখিত তথ্য প্রদান করুন:
    1. সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত
    2. API প্রক্সি বান্ডেল
    3. ট্রেস ফাইল ত্রুটি দেখাচ্ছে
    4. বার্তা প্রসেসর লগ /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. TCP/IP প্যাকেটগুলি ব্যাকএন্ড সার্ভার বা মেসেজ প্রসেসরে ক্যাপচার করা হয়েছে।
  3. আপনি এই প্লেবুকের কোন বিভাগগুলি চেষ্টা করেছেন এবং অন্য কোন অন্তর্দৃষ্টি যা আমাদের এই সমস্যার দ্রুত সমাধান করতে সাহায্য করবে সে সম্পর্কে বিশদ বিবরণ।