دروازه بد 502

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

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 502 را به همراه پیام "Bad Gateway" به عنوان پاسخی برای فراخوانی‌های API دریافت می‌کند.

کد وضعیت HTTP 502 به این معنی است که کلاینت پاسخ معتبری از سرورهای backend که باید درخواست را انجام دهند، دریافت نمی‌کند.

پیام‌های خطا

برنامه‌ی کلاینت کد پاسخ زیر را دریافت می‌کند:

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>

اگر خطا از سرور backend باشد، ممکن است چیزی شبیه به این را ببینید. پیام خطای backend کاملاً به پیاده‌سازی آن بستگی دارد.

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

علل احتمالی

در اینجا چند دلیل احتمالی که می‌تواند منجر به خطای 502 Bad Gateway برای APIهایی که از Apigee Edge عبور می‌کنند، شود، آورده شده است:

علت توضیحات دستورالعمل‌های عیب‌یابی قابل اجرا برای
هیچ نماینده‌ای در مجمع عمومی حاضر نیست این خطا زمانی مشاهده می‌شود که همه MPهای موجود در Pool در دسترس نباشند، یعنی یا از کار افتاده باشند یا مشغول باشند و از این رو پاسخ ندهند. کاربران فضای ابری خصوصی اج
پیکربندی نادرست SSL بین روترها و نمایندگان مجلس این خطا زمانی مشاهده می‌شود که گواهی ریشه امضا شده توسط CA کلاینت در truststore روتر Edge وجود نداشته باشد. کاربران فضای ابری خصوصی اج
خطا از سرور backend اگر سرور backend از کار بیفتد و این پاسخ را ارسال کند، این خطا مشاهده خواهد شد. کاربران فضای ابری عمومی و خصوصی Edge

علت: هیچ نماینده‌ای در مجمع عمومی موجود نیست

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

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

تشخیص

  1. اگر بیش از یک منطقه/مرکز داده وجود دارد، منطقه/مرکز داده‌ای را که درخواست‌های API در آن با خطای ۵۰۲ Bad Gateway مواجه می‌شوند، تعیین کنید. می‌توانید این را با شناسایی منطقه‌ای که کاربران در آن خطاهای ۵۰۲ را مشاهده می‌کنند یا با بررسی لاگ‌های NGINX Access در دایرکتوری /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. اگر همه پردازنده‌های پیام فعال و روشن هستند، بررسی کنید که آیا پردازنده(های) پیام از CPU استفاده بالایی دارند یا خیر، سپس با استفاده از دستور زیر هر 30 ثانیه سه نسخه پشتیبان از نخ ایجاد کنید: 
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. اگر پردازنده(های) پیام، مصرف حافظه بالایی را تجربه می‌کنند، با استفاده از دستور زیر، یک heap dump ایجاد کنید: 
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. با استفاده از دستور زیر، پردازشگر پیام را مجدداً راه‌اندازی کنید. این کار باید CPU و حافظه را از کار بیندازد: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. فراخوانی‌های API را زیر نظر بگیرید تا مطمئن شوید که مشکل هنوز وجود دارد یا خیر.
  6. با پشتیبانی Apigee تماس بگیرید و گزارش‌های مربوط به thread dumps، heap dumps و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) را ارائه دهید تا به شما در بررسی علت استفاده زیاد از CPU/memory کمک شود.

علت: پیکربندی نادرست 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 داده شده است، پاسخ ۵۰۲ را مشاهده خواهید کرد: 
        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 handshake می‌شود.
  5. معمولاً این اتفاق زمانی می‌افتد که هنگام پیکربندی SSL بین روتر و پردازنده پیام، هر مرحله‌ای را از قلم انداخته باشید یا مقادیر نادرستی تنظیم کرده باشید. به مراحل ذکر شده در اینجا مراجعه کنید.
    برای مثال، این خطا می‌تواند رخ دهد اگر
    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. اطمینان حاصل کنید که تمام مراحل ارائه شده در پیکربندی TLS بین روتر و پردازنده پیام به درستی دنبال شده است.
  2. اگر مشکل همچنان ادامه داشت، به بخش جمع‌آوری اطلاعات تشخیصی (Graphic Information) بروید.

علت: خطا از سرور backend

تشخیص

  1. اگر این خطا هر بار رخ می‌دهد، می‌توانید رد رابط کاربری را برای درخواست‌های ناموفق ثبت کنید. یک درخواست ناموفق را انتخاب کنید و مراحل مختلف آن را در ردگیری دنبال کنید. اگر متوجه شدید که خطای "502 Bad Gateway" از خود سرور backend دریافت می‌کنید، مشکل می‌تواند به این دلیل باشد که ممکن است در سرور backend خطایی رخ داده باشد.
    ردیابی که خطای ۵۰۲ Bad Gateway را از سرور backend نشان می‌دهد
  2. اگر مشکل متناوب است و شما قادر به ثبت ردپا نیستید،
    1. اگر شما یک کاربر فضای ابری عمومی هستید، می‌توانید از API Monitoring استفاده کنید و جزئیات مربوط به خطاهای ۵۰۲ را بررسی کنید.
      1. اگر مشاهده کردید که کد خطا messaging.adaptors.http.flow.ErrorResponseCode و منبع خطا target است، پس خطا توسط سرور backend ایجاد شده است.
    2. اگر شما یک کاربر Private Cloud هستید، می‌توانید لاگ‌های NGINX Access را تجزیه و تحلیل کنید.
      /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 است، پس خطا توسط سرور backend ایجاد شده است.

وضوح تصویر

  1. برای رفع این مشکل در قسمت backend با تیم سرور backend خود همکاری کنید.

جمع‌آوری اطلاعات تشخیصی

  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 ).