‫۵۰۴ اتمام مهلت دروازه از سرور زیرینه

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

نشانه

برنامه مشتری در پاسخ به فراخوانی‌های API، کد وضعیت HTTP ۵۰۴ را با پیام «مهلت درگاه ارتباطی به‌پایان رسید» دریافت می‌کند.

این پاسخ خطا نشان می‌دهد که کارخواه درطول اجرای فراخوانی API، پاسخی به‌موقع از Apigee Edge یا سرور پشتیبان دریافت نکرده است.

پیام خطا

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

HTTP/1.1 504 Gateway Timeout

این کد ممکن است با پیام خطایی مشابه پیام زیر همراه باشد:

<html>
<head><title>504 Gateway Timeout</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Timeout</h1></center>
</body>
</html>

چه چیزی باعث اتمام زمان درگاه می‌شود؟

مسیر معمول برای درخواست API که ازطریق Apigee Edge انجام می‌شود کارخواه -> مسیریاب -> پردازشگر پیام -> سرور زیرینه است، همان‌طور که در شکل زیر نشان داده شده است:

برنامه کارخواه، مسیریاب‌ها، و «پردازشگرهای پیام» با مقادیر درنگ مناسب پیکربندی شده‌اند. ‫Apigee Edge برای هر درخواست API در یک دوره زمانی براساس مقادیر مهلت زمانی انتظار پاسخ دارد. اگر پاسخ در بازه زمانی مشخص‌شده دریافت نشود، پاسخ «۵۰۴ Gateway Timeout» برگردانده می‌شود.

علل احتمالی

در Apigee Edge، دلیل معمول پاسخ «پایان مهلت زمانی دروازه ۵۰۴» از سرور زیرینه این است:

«سرور زیرینه» با «اتمام مهلت دروازه ۵۰۴» پاسخ می‌دهد

سرور زیرینه ممکن است با کد پاسخ HTTP 504 Gateway Timeout (مهلت درگاه ارتباطی تمام شد) پاسخ دهد.

تشخیص

این بخش توضیح می‌دهد که چگونه خطای «۵۰۴ پایان مهلت زمانی دروازه» را به‌درستی تشخیص دهید. روش‌های کاربران «ابر خصوصی» و «ابر عمومی» فهرست شده است.

رویه شماره ۱: استفاده از Trace (کاربران Cloud خصوصی و عمومی)

1. ردیابی را در «واسط کاربر Apigee» برای میانای برنامه‌سازی کاربردی تحت‌تأثیر قرارگرفته فعال کنید.
2. درخواستی به سرور زیرینه ارسال کنید.
3. اگر درخواست ناموفق API پاسخ ۵۰۴ از سرور زیرینه در «ردیابی» نشان می‌دهد، دلیل «اتمام مهلت دروازه ۵۰۴» سرور زیرینه است.
4. برای تعیین زمان پاسخ، روی مرحله پاسخ دریافتی از سرور هدف در «پیگیری» کلیک کنید. در مثال نشان‌داده‌شده، زمان سپری‌شده ۶۰۰۰۴ میلی‌ثانیه است:

   

   بخش «جزئیات فاز» اطلاعات بیشتری ارائه می‌دهد:

   • پاسخ 504 Gateway Timeout دریافتی از سرور زیرینه را برجسته می‌کند.
   • بخش محتوای پاسخ بدنه کامل پاسخ از سرور پشتیبان را نمایش می‌دهد. همان‌طور که قبلاً اشاره شد، قالب و محتوای بار پاسخ ممکن است براساس پیاده‌سازی سرور پشتیبان متفاوت باشد.
   • بخش سرصفحه پاسخ > سرور ممکن است نشان دهد پاسخ از کجا آمده است.
5. برای مشاهده داده‌های Analytics و تأیید تشخیص خرابی، روی مرحله داده‌های Analytics ضبط‌شده در «ردیابی» کلیک کنید، همان‌طور که در شکل زیر نشان داده شده است:

   

   بخش سرایندهای پاسخ «جزئیات فاز» مقادیر X-Apigee-fault-code و X-Apigee-fault-source را، همان‌گونه که در شکل زیر نشان داده شده است، نمایش می‌دهد:

   

   اگر این فیلدها حاوی مقادیر نشان‌داده‌شده در جدول زیر باشد، پاسخ خطای ۵۰۴ از سرور کارساز منشأ می‌گیرد:

   سرایندهای پاسخ	مقدار
   X-Apigee-fault-source	هدف
   X-Apigee-fault-code	messaging.adaptors.http.flow.ErrorResponseCode

6. زنجیره پراکسی را بررسی کنید. برای تعیین اینکه آیا سرور پشتیبان پراکسی دیگری را در Apigee فرا می‌خواند یا نه، این مراحل را دنبال کنید:
   1. به مرحله درخواست به سرور هدف ارسال شد برگردید و روی دکمه نمایش Curl کلیک کنید تا نام مستعار میزبان سرور زیرینه را ببینید.
   2. اگر نام مستعار میزبان سرور پشتیبان به نام مستعار میزبان مجازی اشاره کند، زنجیره پروکسی در جای خود قرار دارد. مراحل بالا را برای هر پراکسی زنجیره‌ای تکرار کنید تا علت پاسخ خطای «۵۰۴ پایان مهلت زمانی دروازه» را تشخیص دهید. پایان مهلت زمانی دروازه ۵۰۴ که در پراکسی‌های زنجیره‌ای در مراحل دیگر چرخه درخواست/پاسخ رخ می‌دهد را می‌توان بااستفاده از این کتابچه نمایشی تشخیص داد.
   3. اگر نام مستعار میزبان سرور زیرینه به سرور زیرینه اشاره می‌کند، به وضوح بروید.

رویه شماره ۲: فراخوانی مستقیم API سرور زیرینه (کاربران «ابر عمومی» و «ابر خصوصی»)

برای تأیید رفتار پاسخ «خطای مهلت درگاه ۵۰۴» که هنگام ارسال درخواست ازطریق Apigee Edge با آن مواجه می‌شوید، مستقیماً با سرور زیرینه تماس بگیرید.

1. مطمئن شوید که همه سرایندهای موردنیاز، پارامترهای پُرسمان، و اطلاعات اعتباری لازم را برای ارسال به سرور زیرینه به‌عنوان بخشی از درخواست دارید.
2. اگر سرویس زیرینه به‌صورت عمومی دردسترس باشد، می‌توانید از فرمان curl، Postman، یا هر «کارخواه REST» دیگری استفاده کنید و API سرور زیرینه را مستقیماً فراخوانی کنید.
3. اگر سرور زیرینه فقط از «پردازشگرهای پیام» دردسترس است، از فرمان curl ،‏ Postman، یا هر «کارخواه REST» دیگری برای فراخوانی مستقیم API سرور زیرینه از «پردازشگر پیام» استفاده کنید.
4. اگر سرویس زیرینه پاسخ «۵۰۴ اتمام مهلت دروازه» برگرداند، به Resolution (حل‌وفصل) بروید.

رویه شماره ۳: بررسی گزارش‌های دسترسی NGINX (فقط کاربران «ابر خصوصی»)

گزارش‌های دسترسی NGINX می‌تواند به تعیین اینکه آیا پاسخ خطای ۵۰۴ توسط سرور زیرینه ارسال شده است یا نه کمک کند. این ویژگی به‌ویژه زمانی مفید است که مشکل در گذشته رخ داده باشد، متناوب باشد، یا نتواند در «ردیابی» ثبت شود. برای بررسی گزارش‌های دسترسی NGINX، از این مراحل استفاده کنید:

1. گزارش‌های دسترسی NGINX را بااستفاده از این فرمان مشاهده کنید:

   /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log 

2. پاسخ‌های خطای ۵۰۴ را برای پراکسی API تحت‌تأثیر قرارگرفته بررسی کنید. می‌توانید دوره زمانی خاصی را بررسی کنید، اگر مشکل در گذشته رخ داده است، یا تعیین کنید که آیا درخواست‌ها همچنان با پاسخ خطای ۵۰۴ ناموفق هستند یا خیر.
3. اگر پاسخ خطای ۵۰۴ وجود دارد، تعیین کنید که آیا پاسخ خطا از سرور پشتیبان منشأ می‌گیرد یا خیر.

شکل زیر نمونه‌ای از ورودی گزارش NGINX است که پاسخ خطای ۵۰۴ ناشی از سرور مقصد را نشان می‌دهد:



اگر فیلدهای X-Apigee-fault-source و X-Apigee-fault-code حاوی مقادیر نشان‌داده‌شده در جدول زیر باشد، پاسخ ۵۰۴ از سرور زیرینه منشأ می‌گیرد:

سرایندهای پاسخ	مقدار
X-Apigee-fault-source	هدف
X-Apigee-fault-code	messaging.adaptors.http.flow.ErrorResponseCode

4. کارگزاری پراکسی API تحت‌تأثیر قرارگرفته را بررسی کنید تا زنجیره کارگزاری را بررسی کنید یعنی سرور پشتیبان/نقطه پایانی هدف درحال فراخوانی پراکسی دیگری در Apigee است. اگر کارگزار میانای برنامه کاربردی از زنجیره کارگزار استفاده می‌کند، مراحل بالا را برای هر کارگزار زنجیره‌ای تکرار کنید تا علت پاسخ خطای «مهلت زمانی درگاه ۵۰۴» را تشخیص دهید. پایان مهلت زمانی دروازه ۵۰۴ که در پراکسی‌های زنجیره‌ای در مراحل دیگر رخ می‌دهد را می‌توان بااستفاده از این کتابچه نمایشی تشخیص داد.
5. اگر زنجیره کردن پراکسی وجود ندارد و پاسخ خطای ۵۰۴ از سرور پشتیبان منشأ می‌گیرد، به حل‌وفصل بروید.

رویه شماره ۴: استفاده از «پایش میانای برنامه‌سازی کاربردی» (فقط کاربران «ابر عمومی»)

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

گام‌به‌گام ازطریق یک سناریو نمونه که نشان می‌دهد چگونه بااستفاده از «پایش API» مشکلات 5xx را در APIهای خود عیب‌یابی کنید. برای مثال، هشداری راه‌اندازی کنید تا وقتی تعداد کدهای وضعیت ۵۰۴ از آستانه خاصی فراتر رفت، به سرپرستان اطلاع دهد.

وضوح

بااستفاده از روش‌های تشخیص خرابی که در بالا ذکر شد، می‌توانید با تیم سرور زیرینه همکاری کنید تا مشکل سرور زیرینه را برطرف کنید. این ممکن است شامل تنظیم زمان‌های اتمام در سرورهای پشتیبان یا زمان‌های اتمام در هر ترازکننده بار در مقابل سرورهای هدف باشد.

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

اگر مشکل برطرف نشد، اطلاعات تشخیصی زیر را با پشتیبانی Apigee هم‌رسانی کنید.

اگر کاربر «ابر عمومی» هستید، اطلاعات زیر را ارائه دهید:

• Organization Name
• نام محیط
• نام پراکسی میانای برنامه‌سازی کاربردی
• فرمان curl که برای بازتولید پاسخ خطای ۵۰۴ استفاده شده است را تکمیل کنید
• فایل ردیابی با درخواست‌های API که پاسخ خطای «۵۰۴ پایان مهلت زمانی دروازه» دریافت می‌کند

اگر کاربر «ابر خصوصی» هستید، اطلاعات زیر را ارائه دهید:

• پیام خطای کامل مشاهده‌شده برای درخواست‌های ناموفق
• نام محیط
• بسته پراکسی میانای برنامه‌سازی کاربردی
• فایل ردیابی با درخواست‌های API که پاسخ خطای 504 Gateway Timeout (اتمام مهلت دروازه) دریافت می‌کنند
• گزارش‌های دسترسی NGINX

  /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log 

• گزارش‌های «پردازشگر پیام»

  /opt/apigee/var/log/edge-message-processor/logs/system.log