‫۵۰۲: دروازه نادرست

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

نشانه

برنامه مشتری کد وضعیت HTTP ۵۰۲ را با پیام «دروازه نادرست» به‌عنوان پاسخ برای تماس‌های API دریافت می‌کند.

کد وضعیت 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 Edge عبور می‌کنند آورده شده است:

دلیل: هیچ نماینده‌ای در استخر دردسترس نیست

این خطا زمانی رخ می‌دهد که «مسیریاب» متوجه شود همه «پردازشگرهای پیام» در یک منطقه/مرکز داده مشخص دردسترس نیستند (برای مثال، اگر همه آن‌ها ازکار افتاده باشند).

‫Apigee Edge به‌گونه‌ای پیکربندی شده است که ترافیک ورودی API (درخواست‌ها) در یک منطقه/مرکز داده معین همیشه از «مسیریاب‌ها» به «پردازشگرهای پیام» (MPs) در همان منطقه/مرکز داده هدایت می‌شود. در برخی موارد، ممکن است عناصر Apigee Edge فقط در یک منطقه/مرکز داده راه‌اندازی شوند و در برخی موارد، ممکن است در بیش‌از یک منطقه/مرکز داده راه‌اندازی شوند. در هر منطقه/مرکز داده، دو یا چند «مسیریاب» و «پردازشگر پیام» پیکربندی خواهد شد.

تشخیص

1. اگر بیش از یک منطقه/مرکز داده وجود دارد، منطقه/مرکز داده‌ای را که درخواست‌های «میانای برنامه‌سازی کاربردی» در آن با خطای «۵۰۲ دروازه نادرست» مواجه می‌شود تعیین کنید. می‌توانید این را با شناسایی منطقه‌ای که کاربران در آن خطاهای ۵۰۲ را مشاهده می‌کنند یا با بررسی گزارش‌های «دسترسی NGINX» در دایرکتوری /opt/apigee/var/log/edge-router/nginx/ در هریک از «مسیریاب‌های» متعلق به مناطق مختلف پیدا کنید.
2. خطای زیر را در گزارش‌های خطای NGINX (/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. بررسی کنید که آیا «پردازشگرهای پیام» در منطقه/مرکز داده خاص فعال و درحال اجرا هستند یا خیر.
2. اگر همه «پردازشگرهای پیام» غیرفعال هستند، آن‌ها را بازراه‌اندازی کنید.

وضوح

همه «پردازشگرهای پیام» را بااستفاده از فرمان زیر بازراه‌اندازی کنید:

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

سناریو ۲: همه «پردازشگرهای پیام» مشغول پردازش درخواست‌های جاری هستند

این خطا زمانی رخ می‌دهد که «مسیریاب‌ها» متوجه شوند همه «پردازشگرهای پیام» در یک منطقه/مرکز داده مشخص دردسترس نیستند زیرا همه آن‌ها مشغول پردازش درخواست‌های جاری هستند.

1. بررسی کنید که آیا «پردازشگرهای پیام» در منطقه/مرکز داده خاص فعال و درحال اجرا هستند یا خیر.
2. اگر همه «پردازشگرهای پیام» فعال و درحال کار هستند، بررسی کنید که آیا «پردازشگر(های) پیام» از واحد پردازش مرکزی زیاد استفاده می‌کند یا نه، سپس بااستفاده از دستور زیر، هر ۳۰ ثانیه سه تخلیه رشته‌ای تولید کنید:
   

   <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 تماس بگیرید و برای کمک به بررسی علت استفاده بالای CPU/حافظه، تخلیه رشته، تخلیه پشته، و گزارش‌های «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) را ارائه دهید.

دلیل: پیکربندی SSL نادرست بین «مسیریاب‌ها» و «شرکای مدیریت»

تشخیص

1. گزارش‌های «دسترسی NGINX» (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log) را بررسی کنید. پاسخ ۵۰۲ را همان‌طور که در زیر نشان داده شده است خواهید دید:
   

       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) را بررسی کنید. خطاهایی مانند این خواهید دید:
   

   	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. اگر در پیام خطا در مرحله ۱ و ۲ دقت کنید، شماره درگاه استفاده‌شده برای ارتباط با «پردازشگر پیام» ۸۹۹۸ است که درگاهی غیرایمن است اما پروتکل آن SSL (https) است. معمولاً شماره درگاه امن مورد استفاده ۸۴۴۳ است. ازآنجایی‌که از درگاه غیرامنی برای ارتباط امن استفاده می‌شود، این امر باعث می‌شود تبادل SSL ناموفق باشد.
5. معمولاً این اتفاق زمانی رخ می‌دهد که درحین پیکربندی «پروتکل امن لایه انتقال» بین «مسیریاب» و «پردازشگر پیام»، مرحله‌ای را ازدست داده باشید یا مقدار نادرستی را تنظیم کرده باشید. به مراحل ذکرشده در اینجا مراجعه کنید.
   برای مثال، این خطا می‌تواند در شرایط زیر رخ دهد
   
   1. شماره درگاه در /opt/apigee/customer/application/message-processor.properties as shown below
      به‌جای ۸۴۴۳ به‌عنوان ۸۹۹۸ مشخص شده است

              conf/message-processor-communication.properties+local.http.port=8998

   2. فایل‌های پیکربندی «مسیریاب» در دایرکتوری /opt/nginx/conf.d/* حذف نشده است و «مسیریاب» هنگام انجام پیکربندی SSL بازراه‌اندازی نشده است. در این سناریو، می‌توانید متوجه شوید که شماره درگاه «پردازشگرهای پیام» در فایل‌های پیکربندی ۸۹۹۸ باقی خواهد ماند.

وضوح

1. مطمئن شوید که همه مراحل ارائه‌شده در پیکربندی کردن «امنیت لایه انتقال» بین «مسیریاب» و «پردازشگر پیام» به‌درستی دنبال شده است.
2. اگر مشکل برطرف نشد، به جمع‌آوری اطلاعات تشخیص خرابی بروید.

دلیل: خطا از سرور زیرینه

تشخیص

1. اگر خطا هر بار رخ می‌دهد، می‌توانید ردیابی واسط کاربر را برای درخواست‌های ناموفق ضبط کنید. درخواستی را که ناموفق بوده است انتخاب کنید و در مراحل مختلف ردیابی پیمایش کنید. اگر متوجه شدید که خطای «502 Bad Gateway» را از خود سرور زیرینه دریافت می‌کنید، ممکن است مشکل از این باشد که سرور زیرینه با خرابی مواجه شده است.
   ردیابی نشان می‌دهد که خطای «۵۰۲ دروازه نادرست» از سرور پشتیبان می‌آید
   
2. اگر مشکل متناوب است و نمی‌توانید ردیابی را ضبط کنید،
   
   1. اگر کاربر «ابر عمومی» هستید، می‌توانید از پایش API استفاده کنید و جزئیات خطاهای ۵۰۲ را بررسی کنید.
      
      1. اگر مشاهده کردید «کد خطا» messaging.adaptors.http.flow.ErrorResponseCode و «منبع خطا» target است، خطا ناشی از سرور زیرینه است.
   2. اگر کاربر «ابر خصوصی» هستید، می‌توانید گزارش‌های «دسترسی NGINX» را تجزیه‌وتحلیل کنید
      /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._error_log).
2. گزارش‌های «پردازشگر پیام»
   (/opt/apigee/var/log/edge-message-processor/logs/system.log).