504 Gateway Timeout از سرور Backend

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

علامت

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

این پاسخ خطا نشان می دهد که کلاینت در طول اجرای یک تماس 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 انجام می شود ، Client -> Router -> Message Processor -> Backend Server است که در شکل زیر نشان داده شده است:

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

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

علل احتمالی

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

علت توضیحات دستورالعمل عیب یابی برای
سرور Backend با وقفه زمانی دروازه 504 پاسخ می دهد سرور باطن پایان می یابد و یک پاسخ 504 Gateway Timeout را به پردازشگر پیام برمی گرداند. کاربران ابر خصوصی و عمومی Edge

سرور Backend با وقفه زمانی دروازه 504 پاسخ می دهد

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

تشخیص

این بخش نحوه تشخیص صحیح وقفه زمانی دروازه 504 را توضیح می دهد. رویه‌ها برای کاربران خصوصی و عمومی Cloud فهرست شده‌اند.

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

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

    جزئیات فاز از UI

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

    • این پاسخ 504 Gateway Timeout دریافت شده از سرور باطن را برجسته می کند.
    • بخش Response Content کل پاسخ را از سرور باطن نمایش می دهد. همانطور که قبلا ذکر شد، قالب و محتوای بار پاسخ ممکن است بر اساس اجرای سرور باطن متفاوت باشد.
    • بخش Response Header > Server ممکن است نشان دهد که پاسخ از کجا شروع شده است.
  5. برای مشاهده داده های آنالیتیکس و تایید تشخیص، مطابق شکل زیر، روی مرحله ثبت داده های آنالیتیکس در Trace کلیک کنید:

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

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

    جزئیات مرحله تجزیه و تحلیل از UI

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

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

روش شماره 2: API سرور باطن را مستقیماً فراخوانی کنید (کاربران عمومی و خصوصی Cloud)

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

  1. اطمینان حاصل کنید که تمام هدرها، پارامترهای پرس و جو و اعتبار مورد نیاز برای ارسال به سرور باطن به عنوان بخشی از درخواست را دارید.
  2. اگر سرویس Backend برای عموم قابل دسترسی است، می توانید از دستور curl ، Postman یا هر REST Client دیگری استفاده کنید و مستقیماً API سرور باطن را فراخوانی کنید.
  3. اگر سرور Backend فقط از طریق Message Processors قابل دسترسی است، از دستور curl ، Postman یا هر REST Client دیگری برای فراخوانی API سرور backend مستقیماً از Message Processor استفاده کنید.
  4. اگر سرویس Backend a را برگرداند 504 Gateway Timeout پاسخ، به Resolution بروید.

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

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

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

    4. شکل زیر نمونه ای از یک ورودی گزارش NGINX است که پاسخ خطای 504 ناشی از سرور هدف را نشان می دهد:

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

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

    سرصفحه های پاسخ ارزش
    X-Apigee-fault-source هدف
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  4. پروکسی API آسیب دیده را برای بررسی زنجیره پراکسی بررسی کنید، به عنوان مثال، سرور باطن/نقطه پایانی هدف در حال فراخوانی پروکسی دیگری در Apigee است. اگر پروکسی API از زنجیره پراکسی استفاده می کند، مراحل بالا را برای هر پروکسی زنجیره ای تکرار کنید تا علت پاسخ خطای 504 Gateway Timeout را تشخیص دهید. وقفه های 504 Gateway که در پروکسی های زنجیره ای در مراحل دیگر رخ می دهد را می توان با استفاده از این کتاب بازی تشخیص داد.
  5. اگر زنجیره پروکسی وجود ندارد و پاسخ خطای 504 از سرور باطن منشا می گیرد، به Resolution بروید.

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

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

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

قطعنامه

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

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

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

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

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

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

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