502 খারাপ গেটওয়ে

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

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি API কলগুলির প্রতিক্রিয়া হিসাবে "খারাপ গেটওয়ে" বার্তা সহ 502 এর একটি HTTP স্ট্যাটাস কোড পায়।

এইচটিটিপি স্ট্যাটাস কোড 502 এর অর্থ হল ক্লায়েন্ট ব্যাকএন্ড সার্ভার থেকে একটি বৈধ প্রতিক্রিয়া পাচ্ছে না যা আসলে অনুরোধটি পূরণ করা উচিত।

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

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

HTTP/1.1 502 Bad Gateway

উপরন্তু, আপনি নিম্নলিখিত ত্রুটি বার্তা পর্যবেক্ষণ করতে পারেন:

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

যদি ব্যাকএন্ড সার্ভার থেকে ত্রুটি আসে, তাহলে আপনি এরকম কিছু দেখতে পারেন। ব্যাকএন্ড থেকে ত্রুটি বার্তা সম্পূর্ণরূপে এর বাস্তবায়নের উপর নির্ভর করে।

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

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

এখানে কয়েকটি সম্ভাব্য কারণ রয়েছে যা Apigee এজ দিয়ে যাওয়া APIগুলির জন্য 502 খারাপ গেটওয়ে ত্রুটির কারণ হতে পারে:

কারণ বর্ণনা এর জন্য প্রযোজ্য সমস্যা সমাধানের নির্দেশাবলী
পুলে কোনো সাংসদ পাওয়া যাচ্ছে না এই ত্রুটি পরিলক্ষিত হয় যদি পুলের সমস্ত এমপি অনুপলব্ধ থাকে, অর্থাৎ, তারা হয় নিচে বা ব্যস্ত থাকে এবং তাই সাড়া দিচ্ছে না। এজ প্রাইভেট ক্লাউড ব্যবহারকারীরা
রাউটার এবং এমপিদের মধ্যে ভুল SSL কনফিগারেশন এজ রাউটারের ট্রাস্টস্টোরে ক্লায়েন্টের CA স্বাক্ষরিত রুট শংসাপত্র অনুপস্থিত থাকলে এই ত্রুটিটি পরিলক্ষিত হয়। এজ প্রাইভেট ক্লাউড ব্যবহারকারীরা
ব্যাকএন্ড সার্ভার থেকে ত্রুটি ব্যাকএন্ড সার্ভার ব্যর্থ হলে এবং এই প্রতিক্রিয়াটি পাঠালে এই ত্রুটিটি পর্যবেক্ষণ করা হবে। এজ পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারীরা

কারণ: পুলে কোনো এমপি পাওয়া যাচ্ছে না

এই ত্রুটিটি ঘটবে যদি রাউটার দেখতে পায় যে একটি প্রদত্ত অঞ্চল/ডেটা সেন্টারের সমস্ত বার্তা প্রসেসর অনুপলব্ধ (উদাহরণস্বরূপ, যদি সেগুলি সব বন্ধ থাকে)।

Apigee Edge এমনভাবে কনফিগার করা হয়েছে যাতে একটি প্রদত্ত অঞ্চল/ডেটা সেন্টারে ইনকামিং API ট্র্যাফিক (অনুরোধ) সবসময় একই অঞ্চল/ডেটা সেন্টারের রাউটার থেকে মেসেজ প্রসেসরে (MPs) পাঠানো হয়। কিছু ক্ষেত্রে, Apigee Edge উপাদানগুলি শুধুমাত্র একটি অঞ্চল/ডেটা সেন্টারে সেটআপ করা হতে পারে এবং কিছু ক্ষেত্রে, সেগুলি একাধিক অঞ্চল/ডেটা সেন্টারে সেটআপ করা হতে পারে। প্রতিটি অঞ্চল/ডেটা সেন্টারে দুই বা ততোধিক রাউটার এবং মেসেজ প্রসেসর কনফিগার করা থাকবে।

রোগ নির্ণয়

  1. একাধিক অঞ্চল/ডেটা সেন্টার থাকলে যে অঞ্চল/ডেটা সেন্টার (গুলি) সেখানে API অনুরোধগুলি 502 খারাপ গেটওয়ে ত্রুটির সাথে ব্যর্থ হচ্ছে তা নির্ধারণ করুন। আপনি যে অঞ্চলে ব্যবহারকারীরা 502 ত্রুটি পর্যবেক্ষণ করছেন সেটি চিহ্নিত করে বা বিভিন্ন অঞ্চলের প্রতিটি রাউটারে /opt/apigee/var/log/edge-router/nginx/ ডিরেক্টরিতে NGINX অ্যাক্সেস লগ চেক করে আপনি এটি খুঁজে পেতে পারেন। .
  2. আপনি NGINX ত্রুটি লগগুলিতে নিম্নলিখিত ত্রুটিটি দেখতে পাবেন ( /opt/apigee/var/log/edge-router/nginx/ORG-Env. _error_log /opt/apigee/var/log/edge-router/nginx/ORG-Env. _error_log ) 
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

দৃশ্যকল্প 1: সমস্ত বার্তা প্রসেসর বন্ধ

  1. নির্দিষ্ট অঞ্চল/ডেটা সেন্টারের মেসেজ প্রসেসরগুলি আপ এবং চলমান কিনা তা পরীক্ষা করুন।
  2. যদি সমস্ত বার্তা প্রসেসর ডাউন থাকে তবে সেগুলি পুনরায় চালু করুন।

রেজোলিউশন

নিম্নলিখিত কমান্ডটি ব্যবহার করে সমস্ত বার্তা প্রসেসর পুনরায় চালু করুন:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

দৃশ্যকল্প 2: সমস্ত বার্তা প্রসেসর চলমান অনুরোধ প্রক্রিয়াকরণে ব্যস্ত

এই ত্রুটিটি ঘটবে যদি রাউটাররা দেখতে পায় যে একটি প্রদত্ত অঞ্চল/ডাটা কেন্দ্রের সমস্ত বার্তা প্রসেসর অনুপলব্ধ কারণ তারা সকলেই চলমান অনুরোধ প্রক্রিয়াকরণে ব্যস্ত।

  1. নির্দিষ্ট অঞ্চল/ডেটা সেন্টারের মেসেজ প্রসেসরগুলি আপ এবং চলমান কিনা তা পরীক্ষা করুন।
  2. যদি সমস্ত মেসেজ প্রসেসর চালু থাকে এবং সক্রিয় থাকে, তাহলে বার্তা প্রসেসর (গুলি) উচ্চ CPU ব্যবহার করছে কিনা তা পরীক্ষা করুন, তারপর নিম্নলিখিত কমান্ডটি ব্যবহার করে প্রতি 30 সেকেন্ডে তিনটি থ্রেড ডাম্প তৈরি করুন: 
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. যদি মেসেজ প্রসেসর (গুলি) উচ্চ মেমরি ব্যবহারের সম্মুখীন হয় তবে নিম্নলিখিত কমান্ডটি ব্যবহার করে একটি হিপ ডাম্প তৈরি করুন: 
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. নীচের কমান্ডটি ব্যবহার করে বার্তা প্রসেসর পুনরায় চালু করুন। এটি সিপিইউ এবং মেমরি নামিয়ে আনতে হবে: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. সমস্যাটি এখনও বিদ্যমান কিনা তা নিশ্চিত করতে API কলগুলি পর্যবেক্ষণ করুন৷
  6. Apigee সাপোর্টের সাথে যোগাযোগ করুন এবং থ্রেড ডাম্প, হিপ ডাম্প এবং মেসেজ প্রসেসর লগ প্রদান করুন ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) উচ্চ CPU/মেমরি ব্যবহারের কারণ অনুসন্ধানে সহায়তা করতে .

কারণ: রাউটার এবং এমপিদের মধ্যে ভুল SSL কনফিগারেশন

রোগ নির্ণয়

  1. NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন ( /opt/apigee/var/log/edge-router/nginx/ORG-Env. _access_log /opt/apigee/var/log/edge-router/nginx/ORG-Env. _access_log )। আপনি নীচে দেখানো হিসাবে 502 প্রতিক্রিয়া দেখতে পাবেন: 
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. NGINX ত্রুটি লগগুলি পরীক্ষা করুন ( /opt/apigee/var/log/edge-router/nginx/ORG-Env. _error_log /opt/apigee/var/log/edge-router/nginx/ORG-Env. _error_log )। আপনি এই মত ত্রুটি দেখতে পাবেন: 
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. এটি রাউটার এবং মেসেজ প্রসেসরের মধ্যে SSL হ্যান্ডশেক ব্যর্থতা দেখায়।
  4. আপনি যদি ধাপ # 1 এবং # 2 এ ত্রুটি বার্তাটি সাবধানে লক্ষ্য করেন, তাহলে বার্তা প্রসেসরের সাথে যোগাযোগের জন্য পোর্ট # 8998 ব্যবহৃত হয় যা একটি নিরাপদ পোর্ট নয় কিন্তু প্রোটোকলটি হল SSL (https)। সাধারণত নিরাপদ পোর্ট # ব্যবহার করা হয় 8443। যেহেতু নিরাপদ যোগাযোগের জন্য একটি অ-সুরক্ষিত পোর্ট ব্যবহার করা হয়, এটি SSL হ্যান্ডশেক ব্যর্থতার কারণ হয়।
  5. সাধারণত এটি ঘটতে পারে যদি আপনি রাউটার এবং মেসেজ প্রসেসরের মধ্যে SSL কনফিগার করার সময় কোনো পদক্ষেপ মিস করেন বা কোনো ভুল মান সেট করেন। এখানে বর্ণিত পদক্ষেপগুলি পড়ুন।
    উদাহরণস্বরূপ, এই ত্রুটি ঘটতে পারে যদি
    1. /opt/apigee/customer/application/message-processor.properties as shown below এ 8443-এর পরিবর্তে পোর্ট #টি 8998 হিসাবে নির্দিষ্ট করা হয়েছে 
              conf/message-processor-communication.properties+local.http.port=8998
    2. /opt/nginx/conf.d/* ডিরেক্টরির অধীনে রাউটার কনফিগারেশন ফাইলগুলি মুছে ফেলা হয় না এবং SSL কনফিগারেশন করার সময় রাউটার পুনরায় চালু করা হয় নি। এই পরিস্থিতিতে, আপনি লক্ষ্য করতে পারেন যে কনফিগার ফাইলগুলিতে বার্তা প্রসেসরের পোর্ট# 8998 থাকবে।

রেজোলিউশন

  1. একটি রাউটার এবং একটি বার্তা প্রসেসরের মধ্যে TLS কনফিগার করার জন্য প্রদত্ত সমস্ত পদক্ষেপগুলি সঠিকভাবে অনুসরণ করা হয়েছে তা নিশ্চিত করুন৷
  2. যদি সমস্যাটি থেকে যায়, ডায়াগনস্টিক তথ্য সংগ্রহ করুন এ যান।

কারণ: ব্যাকএন্ড সার্ভার থেকে ত্রুটি

রোগ নির্ণয়

  1. যদি প্রতিবার ত্রুটি ঘটে, তাহলে আপনি ব্যর্থ অনুরোধগুলির জন্য UI ট্রেস ক্যাপচার করতে পারেন। একটি ব্যর্থ অনুরোধ নির্বাচন করুন এবং ট্রেসের বিভিন্ন পর্যায়ে নেভিগেট করুন। আপনি যদি লক্ষ্য করেন যে আপনি ব্যাকএন্ড সার্ভার থেকে "502 খারাপ গেটওয়ে" পেয়েছেন, তাহলে সমস্যাটি হতে পারে কারণ ব্যাকএন্ড সার্ভারে কিছু ব্যর্থতা ঘটতে পারে।
    ব্যাকএন্ড সার্ভার থেকে আসা 502 খারাপ গেটওয়ে দেখানো ট্রেস
  2. যদি সমস্যাটি মাঝে মাঝে হয় এবং আপনি ট্রেস ক্যাপচার করতে অক্ষম হন,
    1. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি API মনিটরিং ব্যবহার করতে পারেন এবং 502 ত্রুটি সম্পর্কে বিশদ পরীক্ষা করতে পারেন।
      1. আপনি যদি লক্ষ্য করেন যে ফল্ট কোডটি হল messaging.adaptors.http.flow.ErrorResponseCode এবং ফল্ট উত্সটি target , তাহলে ত্রুটিটি ব্যাকএন্ড সার্ভারের কারণে হয়৷
    2. আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন, তাহলে আপনি NGINX অ্যাক্সেস লগগুলি বিশ্লেষণ করতে পারেন
      /opt/apigee/var/log/edge-router/nginx/ORG-Env. _access_log. /opt/apigee/var/log/edge-router/nginx/ORG-Env. _access_log.
      আপনি নিম্নরূপ ব্যর্থ অনুরোধের জন্য এন্ট্রি দেখতে পাবেন: 
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. আপনি যদি লক্ষ্য করেন যে ফল্ট কোডটি হল messaging.adaptors.http.flow.ErrorResponseCode এবং ফল্ট উত্সটি target , তাহলে ত্রুটিটি ব্যাকএন্ড সার্ভারের কারণে হয়৷

রেজোলিউশন

  1. ব্যাকএন্ডে এই সমস্যাটি সমাধান করতে আপনার ব্যাকএন্ড সার্ভার টিমের সাথে কাজ করুন৷

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

  1. NGINX অ্যাক্সেস লগ
    ( /opt/apigee/var/log/edge-router/nginx/ORG-Env. _access_log /opt/apigee/var/log/edge-router/nginx/ORG-Env. _access_log )
    এবং ত্রুটি লগ
    ( /opt/apigee/var/log/edge-router/nginx/ORG-Env. _error_log /opt/apigee/var/log/edge-router/nginx/ORG-Env. _error_log )।
  2. বার্তা প্রসেসর লগ
    ( /opt/apigee/var/log/edge-message-processor/logs/system.log )।