504 Gateway Timeout از سرور Backend

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

علامت

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

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

پیام خطا

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

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

مسیر درخواست API

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

علل احتمالی

در Apigee Edge، علت معمول پاسخ 504 Gateway Timeout از سرور backend موارد زیر است:

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

سرور بک‌اند با خطای ۵۰۴ Gateway Timeout پاسخ می‌دهد.

سرور backend ممکن است با کد پاسخ HTTP 504 Gateway Timeout پاسخ دهد.

تشخیص

این بخش نحوه تشخیص صحیح خطای ۵۰۴ Gateway Timeout را توضیح می‌دهد. رویه‌های مربوط به کاربران ابر خصوصی و عمومی فهرست شده‌اند.

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

  1. قابلیت Trace را در رابط کاربری Apigee برای API آسیب‌دیده فعال کنید.
  2. ارسال درخواست به سرور backend.
  3. اگر درخواست API ناموفق، پاسخ ۵۰۴ از سرور backend در Trace نشان دهد، پس علت خطای ۵۰۴ Gateway Timeout، سرور backend است.
  4. برای تعیین زمان پاسخ، روی مرحله پاسخ دریافتی از سرور هدف در Trace کلیک کنید. در مثال نشان داده شده، زمان سپری شده 60004 میلی ثانیه است:

    جزئیات فاز از رابط کاربری

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

    • این، پاسخ ۵۰۴ Gateway Timeout دریافتی از سرور backend را هایلایت می‌کند.
    • بخش محتوای پاسخ ، بدنه کامل پاسخ از سرور backend را نمایش می‌دهد. همانطور که قبلاً اشاره شد، قالب و محتوای payload پاسخ ممکن است بر اساس پیاده‌سازی سرور backend متفاوت باشد.
    • بخش Response Header > Server ممکن است نشان دهد که پاسخ از کجا آمده است.
  5. برای مشاهده داده‌های تحلیلی و تأیید تشخیص، مطابق شکل زیر، روی مرحله ثبت داده‌های تحلیلی در Trace کلیک کنید:

    جزئیات تجزیه و تحلیل از ردیابی

    بخش Response Headers از Phase Details مقادیر X-Apigee-fault-code و X-Apigee-fault-source را همانطور که در شکل زیر نشان داده شده است، نمایش می‌دهد:

    جزئیات فاز تجزیه و تحلیل از رابط کاربری

    اگر این فیلدها حاوی مقادیر نشان داده شده در جدول زیر باشند، پاسخ خطای 504 از سرور backend سرچشمه می‌گیرد:

    هدرهای پاسخ ارزش
    منبع گسل X-Apigee هدف
    کد خطای X-Apigee کد پاسخ خطا در جریان پیام‌رسانی http
  6. بررسی زنجیره پروکسی . برای تعیین اینکه آیا سرور backend در Apigee پروکسی دیگری را فراخوانی می‌کند یا خیر، این مراحل را دنبال کنید:
    1. به مرحله درخواست ارسال شده به سرور هدف برگردید و روی دکمه نمایش حلقه کلیک کنید تا نام مستعار میزبان سرور پشتیبان را مشاهده کنید.
    2. اگر نام مستعار میزبان سرور backend به یک نام مستعار میزبان مجازی اشاره کند، آنگاه زنجیره‌سازی پروکسی برقرار است. مراحل بالا را برای هر پروکسی زنجیره‌ای تکرار کنید تا علت پاسخ خطای 504 Gateway Timeout تشخیص داده شود. وقفه‌های 504 Gateway که در پروکسی‌های زنجیره‌ای در مراحل دیگر چرخه درخواست/پاسخ رخ می‌دهند، می‌توانند با استفاده از این راهنما تشخیص داده شوند.
    3. اگر نام مستعار میزبان سرور backend به سرور backend اشاره می‌کند، به Resolution بروید.

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

مستقیماً با سرور backend تماس بگیرید تا همان رفتار پاسخ 504 Gateway Timeout را که هنگام ارسال درخواست از طریق Apigee Edge مشاهده می‌شود، تأیید کنید.

  1. مطمئن شوید که تمام هدرها، پارامترهای کوئری و اعتبارنامه‌های مورد نیاز برای ارسال به سرور بک‌اند به عنوان بخشی از درخواست را دارید.
  2. اگر سرویس backend به صورت عمومی قابل دسترسی باشد، می‌توانید از دستور curl ، Postman یا هر REST Client دیگری استفاده کنید و API سرور backend را مستقیماً فراخوانی کنید.
  3. اگر سرور backend فقط از طریق پردازنده‌های پیام قابل دسترسی است، از دستور curl ، Postman یا هر کلاینت REST دیگری برای فراخوانی API سرور backend مستقیماً از پردازنده پیام استفاده کنید.
  4. اگر سرویس backend مقدار a را برگرداند پاسخ خطای ۵۰۴ Gateway Timeout، به بخش حل مشکل بروید.

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

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

  1. با استفاده از این دستور، گزارش‌های دسترسی NGINX را مشاهده کنید:
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  2. پاسخ‌های خطای ۵۰۴ را برای پروکسی API آسیب‌دیده بررسی کنید. می‌توانید یک دوره زمانی خاص را بررسی کنید، اگر مشکل در گذشته رخ داده باشد، یا با پاسخ خطای ۵۰۴ مشخص کنید که آیا درخواست‌ها هنوز با شکست مواجه می‌شوند یا خیر.
  3. اگر پاسخ خطای ۵۰۴ وجود دارد، مشخص کنید که آیا پاسخ خطا از سرور backend سرچشمه می‌گیرد یا خیر.

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

    نمونه لاگ‌های nginx

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

    هدرهای پاسخ ارزش
    منبع گسل X-Apigee هدف
    کد خطای X-Apigee کد پاسخ خطا در جریان پیام‌رسانی http
  4. پروکسی API آسیب‌دیده را بررسی کنید تا زنجیره‌سازی پروکسی را بررسی کنید، یعنی سرور backend/target endpoint در حال فراخوانی پروکسی دیگری در Apigee است. اگر پروکسی API از زنجیره‌سازی پروکسی استفاده می‌کند، مراحل بالا را برای هر پروکسی زنجیره‌ای تکرار کنید تا علت پاسخ خطای 504 Gateway Timeout را تشخیص دهید. وقفه‌های 504 Gateway که در پروکسی‌های زنجیره‌ای در مراحل دیگر رخ می‌دهند، می‌توانند با استفاده از این playbook تشخیص داده شوند.
  5. اگر هیچ زنجیره پروکسی وجود ندارد و پاسخ خطای 504 از سرور backend سرچشمه می‌گیرد، به بخش Resolution بروید.

روش شماره ۴: استفاده از مانیتورینگ API (فقط کاربران ابر عمومی)

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

یک سناریوی نمونه را که نحوه عیب‌یابی مشکلات 5xx با APIهای شما را با استفاده از مانیتورینگ API نشان می‌دهد، قدم به قدم بررسی کنید . به عنوان مثال، یک هشدار تنظیم کنید تا وقتی تعداد کدهای وضعیت 504 از یک آستانه خاص فراتر رفت، به مدیران اطلاع داده شود.

وضوح تصویر

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

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

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

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

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

اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:

  • پیام خطای کامل مشاهده شده برای درخواست‌های ناموفق
  • نام محیط
  • بسته پروکسی API
  • فایل ردیابی با درخواست‌های API که پاسخ خطای ۵۰۴ 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