دروازه بد 502

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

علامت

برنامه مشتری کد وضعیت HTTP 502 را با پیام "Bad Gateway" به عنوان پاسخی برای تماس های 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>

علل احتمالی

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

علت توضیحات دستورالعمل های عیب یابی قابل اجرا برای
هیچ نماینده ای در استخر موجود نیست این خطا در صورتی مشاهده می شود که تمام نمایندگان مجلس در استخر در دسترس نباشند، یعنی یا در حال کار هستند یا مشغول هستند و بنابراین پاسخ نمی دهند. کاربران Edge Private Cloud
پیکربندی نادرست SSL بین روترها و MPs این خطا در صورتی مشاهده می شود که گواهی ریشه امضا شده CA مشتری در Truststore Router Edge وجود نداشته باشد. کاربران Edge Private Cloud
خطا از سرور باطن در صورتی که سرور باطن از کار بیفتد و این پاسخ را ارسال کند، این خطا مشاهده می شود. کاربران Edge Public و Private Cloud

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

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

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

تشخیص

  1. اگر بیش از یک منطقه/مرکز داده وجود داشته باشد، منطقه/مرکز داده‌ای را که درخواست‌های API در آن با خطای 502 Bad Gateway ناموفق هستند، تعیین کنید. شما می توانید با شناسایی منطقه ای که کاربران در آن خطاهای 502 را مشاهده می کنند یا با بررسی گزارش های دسترسی NGINX در فهرست /opt/apigee/var/log/edge-router/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. اگر پردازشگر(های) پیام از حافظه بالایی استفاده می کند، با استفاده از دستور زیر یک 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 dump، heap dump و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) را برای کمک به بررسی علت استفاده بالای CPU/حافظه ارائه دهید. .

علت: پیکربندی نادرست SSL بین روترها و MPs

تشخیص

  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 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، روتر راه‌اندازی مجدد نشده است. در این سناریو، می توانید متوجه شوید که پورت # پردازنده های پیام 8998 در فایل های پیکربندی باقی می ماند.

قطعنامه

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

علت: خطا از سرور باطن

تشخیص

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