502 খারাপ গেটওয়ে - সকেট হ্যাং আপ

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি এজ মাইক্রোগেটওয়েতে এপিআই কলের প্রতিক্রিয়া হিসাবে ECONNRESET কোড সহ 502 Bad Gateway HTTP স্ট্যাটাস কোডটি পায়।

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

ক্লায়েন্ট নিম্নলিখিত প্রতিক্রিয়া কোডটি দেখতে পাবে:

HTTP/1.1 502 Bad Gateway

প্রতিক্রিয়ায় নিম্নলিখিত ত্রুটি বার্তাটি অন্তর্ভুক্ত থাকবে:

{"message":"socket hang up","code":"ECONNRESET"}

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

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

1. Edge Microgateway লগগুলি পরীক্ষা করুন:

   /var/tmp/edgemicro-`hostname`-*.log

2. একটি নির্দিষ্ট সময়কালের মধ্যে ECONNRESET কোড সহ কোনো 502 ত্রুটি আছে কিনা (যদি সমস্যাটি অতীতে ঘটে থাকে) অথবা এখনও কোনো অনুরোধ 502 ত্রুটির কারণে ব্যর্থ হচ্ছে কিনা তা অনুসন্ধান করে দেখুন।

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. যদি আপনার লগিং লেভেল warn বা info তে সেট করা থাকে, তাহলে একটি [warn] মেসেজও থাকবে, যার দ্বিতীয় অংশে টার্গেট সার্ভারের হোস্টনেম এবং পোর্ট উল্লেখ থাকবে। এই উদাহরণে, এটি হলো XXXX:8080 , এবং এটি পরবর্তীতে একটি tcpdump ক্যাপচার করার জন্য ব্যবহার করা যেতে পারে।

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. [socket hang up][ECONNRESET] এরর কোডটি নির্দেশ করে যে টার্গেট সার্ভারটি Edge Microgateway-এর সাথে সংযোগ বন্ধ করে দিয়েছে। এটি কত ঘন ঘন ঘটছে তা নির্ধারণ করতে লগগুলিতে এটি অনুসন্ধান করা যেতে পারে।

কারণ: ভুলভাবে কনফিগার করা কিপ-অ্যালাইভ টাইমআউট

রোগ নির্ণয়

1. সাধারণ রোগ নির্ণয়ের ধাপগুলো অনুসরণ করুন এবং যাচাই করে দেখুন আপনি [socket hang up][ECONNRESET] ত্রুটিটি পেয়েছেন কিনা।

2. যদি হ্যাঁ হয়, তাহলে নিচে ব্যাখ্যা করা অনুযায়ী tcpdump এর সাহায্যে আরও তদন্ত করুন:

tcpdump ব্যবহার করে

1. নিম্নলিখিত কমান্ড ব্যবহার করে Edge Microgateway হোস্ট অপারেটিং সিস্টেমে Edge Microgateway এবং ব্যাকএন্ড সার্ভারের মধ্যে একটি tcpdump ক্যাপচার করুন:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. ক্যাপচার করা tcpdump বিশ্লেষণ করুন:

   tcpdump আউটপুটের নমুনা: ( বড় ছবি দেখুন )

   

   উপরের নমুনা tcpdump টিতে আপনি নিম্নলিখিত বিষয়গুলো দেখতে পাবেন:

   1. প্যাকেট ২৫০২৮৮- এ ক্লায়েন্ট একটি POST অনুরোধ পাঠায়।
   2. প্যাকেট ২৫০৩৭১- এ, সার্ভারটি 200 OK দিয়ে সাড়া দেয়।
   3. প্যাকেট 250559- এ, ক্লায়েন্ট একটি ACK.
   4. প্যাকেট 250560- এ, সার্ভারটি Continuation মেসেজ পাঠায়।
   5. প্যাকেট 250561- এ, ক্লায়েন্ট একটি ACK.
   6. প্যাকেট ২৬২৪৩৬- এ, সার্ভার ক্লায়েন্টকে একটি FIN, ACK পাঠিয়ে সংযোগটি বন্ধ করার প্রক্রিয়া শুরু করে। উল্লেখ্য যে, এটি পূর্ববর্তী প্যাকেটের ( ২৫০৫৬১ ) প্রায় পাঁচ সেকেন্ড পরে পাঠানো হয়েছে।
   7. প্যাকেট ২৬২৪৪১- এ, ক্লায়েন্ট আরেকটি POST অনুরোধ পাঠায়। তবে, এটি ব্যর্থ হয় কারণ সার্ভার ইতিমধ্যেই সংযোগটি বন্ধ করার প্রক্রিয়া শুরু করে দিয়েছে। এটি প্যাকেট ২৬২৪৪১- এ একটি RST এর মাধ্যমে সাড়া দেয়।

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

কিপ-অ্যালাইভ টাইমআউটগুলির তুলনা করুন

1. Edge Microgateway-এর কোনো নির্দিষ্ট keep-alive timeout প্রপার্টি নেই। এটি যে অপারেটিং সিস্টেমে চলছে, তার দ্বারাই নির্ধারিত হয়। এর সাধারণ উদাহরণ হলো Windows, Linux, এবং Docker কন্টেইনার।
2. এমন হতে পারে যে এটি অপারেটিং সিস্টেমে কাস্টমাইজ করা আছে। আপনার সিস্টেম অ্যাডমিনিস্ট্রেটরের সাথে কথা বলে নিশ্চিত হন। ডিফল্টরূপে, লিনাক্স অপারেটিং সিস্টেমগুলিতে দুই ঘণ্টার একটি ডিফল্ট কিপ-অ্যালাইভ টাইমআউট থাকে।
3. এরপর, আপনার ব্যাকএন্ড সার্ভারে কনফিগার করা 'keep-alive timeout' প্রপার্টিটি পরীক্ষা করুন। ধরা যাক, আপনার ব্যাকএন্ড সার্ভারটি ১০ সেকেন্ডের একটি মান দিয়ে কনফিগার করা আছে।
4. যদি আপনি দেখেন যে উপরের উদাহরণের মতো অপারেটিং সিস্টেমের keep-alive timeout-এর মান ব্যাকএন্ড সার্ভারের keep-alive timeout প্রপার্টির মানের চেয়ে বেশি, তাহলে সেটাই 502 এররের কারণ।

সমাধান

নিশ্চিত করুন যে, যে অপারেটিং সিস্টেমে এজ মাইক্রোগেটওয়ে চলছে, সেখানকার কিপ-অ্যালাইভ টাইমআউট প্রপার্টিটি ব্যাকএন্ড সার্ভারের তুলনায় সর্বদা কম থাকে।

1. ব্যাকএন্ড সার্ভারে কিপ-অ্যালাইভ টাইমআউটের জন্য নির্ধারিত মান নির্ণয় করুন।
2. আপনার অপারেটিং সিস্টেমের জন্য প্রযোজ্য ধাপগুলো অনুসরণ করে, অপারেটিং সিস্টেমে keep-alive timeout প্রপার্টির জন্য একটি উপযুক্ত মান কনফিগার করুন, যাতে এই মানটি ব্যাকএন্ড সার্ভারে সেট করা মানের চেয়ে কম হয়।

সর্বোত্তম অনুশীলন

এই ধরনের রেস কন্ডিশন এবং 502 এরর এড়ানোর জন্য, ডাউনস্ট্রিম কম্পোনেন্টগুলোতে আপস্ট্রিম সার্ভারগুলোতে কনফিগার করা কিপ-অ্যালাইভ টাইমআউট থ্রেশহোল্ডের চেয়ে সর্বদা কম রাখার জন্য দৃঢ়ভাবে পরামর্শ দেওয়া হয়। প্রতিটি ডাউনস্ট্রিম হপ প্রতিটি আপস্ট্রিম হপের চেয়ে কম হওয়া উচিত। এজ মাইক্রোগেটওয়েতে, নিম্নলিখিত নির্দেশিকাগুলো ব্যবহার করা একটি ভালো অভ্যাস:

1. ক্লায়েন্ট অ্যাপ্লিকেশন বা লোড ব্যালান্সারের কিপ-অ্যালাইভ টাইমআউট এজ মাইক্রোগেটওয়ের কিপ-অ্যালাইভ টাইমআউটের চেয়ে কম হওয়া উচিত।

   Edge Microgateway-তে keep-alive timeout কনফিগার করতে, আপনার ~/.edgemicro/org-env-config.yaml ফাইলে keep_alive_timeout ভ্যালুটি যোগ করুন।

   edgemicro:
     keep_alive_timeout: 65000

2. Edge Microgateway অপারেটিং সিস্টেমের keep-alive timeout অবশ্যই টার্গেট সার্ভারের keep-alive timeout-এর চেয়ে কম হওয়া উচিত।
3. এজ মাইক্রোগেটওয়ের সামনে বা পিছনে যদি অন্য কোনো হপ থাকে, তাহলেও একই নিয়ম প্রযোজ্য হবে। আপস্ট্রিমের সাথে সংযোগ বিচ্ছিন্ন করার দায়িত্ব সবসময় ডাউনস্ট্রিম ক্লায়েন্টের উপরই ছেড়ে দেওয়া উচিত।

কারণ: টার্গেট সার্ভার সময়ের আগেই সংযোগ বন্ধ করে দেয়

রোগ নির্ণয়

1. সাধারণ রোগ নির্ণয়ের ধাপগুলিতে বর্ণিত পদক্ষেপগুলি ব্যবহার করুন এবং যাচাই করুন যে আপনি [socket hang up][ECONNRESET] ত্রুটিটি পেয়েছেন কিনা।
2. যদি হ্যাঁ হয়, তাহলে নিচে ব্যাখ্যা করা অনুযায়ী tcpdump এর সাহায্যে আরও তদন্ত করুন।

   উপরের উদাহরণে [targetRequest error][GET][] [socket hang up][ECONNRESET] ত্রুটি বার্তাটি নির্দেশ করে যে, Edge Microgateway যখন ব্যাকএন্ড (টার্গেট) সার্ভারে অনুরোধ পাঠাচ্ছিল, তখন এই ত্রুটিটি ঘটেছে। অর্থাৎ, Edge Microgateway ব্যাকএন্ড সার্ভারে API অনুরোধ পাঠিয়েছিল এবং প্রতিক্রিয়ার জন্য অপেক্ষা করছিল। কিন্তু, Edge Microgateway প্রতিক্রিয়া পাওয়ার আগেই ব্যাকএন্ড সার্ভার হঠাৎ করে সংযোগটি বিচ্ছিন্ন করে দেয়।

3. আপনার ব্যাকএন্ড সার্ভারের লগ পরীক্ষা করে দেখুন, সেখানে এমন কোনো ত্রুটি বা তথ্য আছে কি না, যার কারণে ব্যাকএন্ড সার্ভারটি হঠাৎ করে সংযোগ বিচ্ছিন্ন করে দিয়েছে। যদি কোনো ত্রুটি বা তথ্য খুঁজে পান, তাহলে 'রেজোলিউশন' (Resolution) অংশে গিয়ে আপনার ব্যাকএন্ড সার্ভারে সমস্যাটি যথাযথভাবে সমাধান করুন।
4. আপনার ব্যাকএন্ড সার্ভারে কোনো ত্রুটি বা তথ্য খুঁজে না পেলে, এজ মাইক্রোগেটওয়ে সার্ভার থেকে tcpdump আউটপুট সংগ্রহ করুন:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. ক্যাপচার করা tcpdump বিশ্লেষণ করুন:

   tcpdump আউটপুটের নমুনা: ( বড় ছবি দেখুন )

   

   উপরের নমুনা tcpdump টিতে আপনি নিম্নলিখিত বিষয়গুলো দেখতে পাবেন:

   1. প্যাকেট ৪- এ, এজ মাইক্রোগেটওয়ে টার্গেট সার্ভারে একটি GET রিকোয়েস্ট পাঠিয়েছে।
   2. প্যাকেট ৫- এ, টার্গেট সার্ভার অনুরোধটি স্বীকার করে ACK পাঠিয়ে সাড়া দিয়েছে।
   3. তবে, ৬ নং প্যাকেটে, রেসপন্স পেলোড পাঠানোর পরিবর্তে, টার্গেট সার্ভারটি একটি FIN, ACK পাঠিয়ে সংযোগটি বন্ধ করার প্রক্রিয়া শুরু করে।
   4. ৭ নম্বর প্যাকেট থেকে সংযোগটি পারস্পরিকভাবে বন্ধ করে দেওয়া হয়। যেহেতু প্রতিক্রিয়া পাঠানোর আগেই সংযোগটি বন্ধ করা হয়েছিল, এজ মাইক্রোগেটওয়ে ক্লায়েন্টকে HTTP 502 ত্রুটি ফেরত পাঠাবে।
   5. উল্লেখ্য যে, প্যাকেট ৮ -এর টাইমস্ট্যাম্প, 2021-06-23T03:52:24.110Z এজ মাইক্রোগেটওয়ে লগ-এ ত্রুটি নথিভুক্ত হওয়ার টাইমস্ট্যাম্পের সাথে মিলে যায়। লগ ফাইল এবং tcpdump এর টাইমস্ট্যাম্পগুলো প্রায়শই ত্রুটিগুলোকে প্রকৃত প্যাকেটের সাথে মিলিয়ে দেখতে ব্যবহার করা যায়।

   সমাধান

   ব্যাকএন্ড সার্ভারে সমস্যাটি যথাযথভাবে সমাধান করুন।

   যদি সমস্যাটি অব্যাহত থাকে এবং 502 Bad Gateway Error ট্রাবলশুটিং-এর জন্য আপনার সাহায্যের প্রয়োজন হয় অথবা আপনার সন্দেহ হয় যে এটি Edge Microgateway-এর অভ্যন্তরীণ কোনো সমস্যা, তাহলে Must gather diagnostic information- এ যান।

   রোগ নির্ণয়ের তথ্য অবশ্যই সংগ্রহ করতে হবে

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

   • লগ ফাইল : ডিফল্ট ফোল্ডার হলো /var/tmp , কিন্তু এটি মূল config.yaml ফাইলে ( logging > dir parameter ) পরিবর্তন করা যেতে পারে। Apigee সাপোর্টে লগ ফাইলগুলো দেওয়ার আগে log > level পরিবর্তন করে info করার পরামর্শ দেওয়া হচ্ছে।
   • কনফিগারেশন ফাইল : Edge Microgateway-এর মূল কনফিগারেশনটি ডিফল্ট Edge Microgateway ফোল্ডার, $HOME/.edgemicro এর YAML ফাইলে থাকে। এখানে default.yaml নামে একটি ডিফল্ট কনফিগারেশন ফাইল এবং প্রতিটি এনভায়রনমেন্টের জন্য ORG - ENV -config.yaml নামে একটি করে ফাইল রয়েছে। অনুগ্রহ করে সংশ্লিষ্ট অর্গ এবং এনভায়রনমেন্টের জন্য এই ফাইলটি সম্পূর্ণভাবে আপলোড করুন।