خطای 502 Bad Gateway Timeout

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

علامت

برنامه‌ی کلاینت خطای ۵۰۲ Bad Gateway را دریافت می‌کند. پردازشگر پیام، این خطا را زمانی که برنامه‌ی کلاینت پاسخی از سرور backend دریافت نمی‌کند، به آن برمی‌گرداند.

پیام خطا

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

HTTP/1.1 502 Bad Gateway

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

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

علت احتمالی

علت احتمالی این مشکل در جدول زیر ذکر شده است:

علت توضیحات مراحل عیب‌یابی را می‌توان با انجام
مهلت زمانی دست‌دهی TLS/SSL در طول فرآیند TLS/SSL Handshake بین پردازنده پیام و سرور backend، یک وقفه زمانی رخ می‌دهد. کاربران Edge Private و Public Cloud

علت: زمان تأخیر در دست‌دهی TLS/SSL

در Apigee Edge، می‌توانید یک اتصال TLS/SSL به سرور backend تنظیم کنید تا ارتباط TLS بین پردازنده پیام Edge و یک سرور backend فعال شود.

یک handshake TLS/SSL شامل چندین مرحله است. این خطا معمولاً زمانی اتفاق می‌افتد که timeout مربوط به handshake TLS/SSL بین پردازنده پیام و سرور backend رخ دهد.

تشخیص

این بخش نحوه تشخیص صحیح وقفه زمانی دست‌دهی TLS/SSL را توضیح می‌دهد. دستورالعمل‌های مربوط به Edge Private Cloud و Public Cloud فهرست شده‌اند.

بررسی خروجی نشست Trace

مراحل زیر نحوه تشخیص اولیه مشکل با استفاده از ابزار Apigee Edge Trace را توضیح می‌دهد.

  1. در رابط کاربری Edge، یک جلسه ردیابی (Trace session) برای پروکسی API آسیب‌دیده فعال کنید.

  2. اگر رد درخواست API ناموفق موارد زیر را نشان دهد، احتمالاً خطای TLS/SSL handshake timeout رخ داده است. علت احتمالی خطا این است که فایروال سرور backend ترافیک Apigee را مسدود می‌کند.

    1. تعیین کنید که آیا خطای 502 Bad Gateway پس از 55 ثانیه رخ می‌دهد یا خیر، که این مدت زمان، مدت زمان پیش‌فرض تنظیم شده در پردازنده پیام است. اگر مشاهده کردید که خطا پس از 55 ثانیه رخ داده است، این به شما می‌گوید که احتمالاً یک مدت زمان مشخص علت مشکل بوده است.
    2. بررسی کنید که آیا خطا، خطا را نشان می‌دهد یا خیر: messaging.adaptors.http.BadGateway . باز هم، این خطا معمولاً نشان می‌دهد که یک timeout رخ داده است.

    3. اگر از Edge Private Cloud استفاده می‌کنید، مقدار فیلد X-Apigee.Message-ID را در خروجی ردیابی، همانطور که در زیر نشان داده شده است، یادداشت کنید. یک کاربر Private Cloud می‌تواند از این مقدار شناسه برای انجام عیب‌یابی بیشتر، همانطور که بعداً توضیح داده خواهد شد، استفاده کند.

      1. روی آیکون Analytics Data Recorded در مسیر ردیابی کلیک کنید:

      2. به پایین اسکرول کنید و مقدار فیلدی به نام X-Apigee.Message-ID را یادداشت کنید.

برای تأیید اینکه وقفه زمانی TLS/SSL Handshake علت خطا بوده است، بسته به اینکه در ابر عمومی هستید یا ابر خصوصی، مراحل بخش‌های زیر را دنبال کنید.

مراحل تشخیصی اضافی فقط برای کاربران Edge Private Cloud

اگر از Apigee Edge Private Cloud استفاده می‌کنید، می‌توانید مراحل زیر را برای کمک به تأیید علت خطای handshake انجام دهید. در این مرحله، فایل گزارش پردازنده پیام را برای اطلاعات مرتبط بررسی می‌کنید. اگر از Edge Public Cloud استفاده می‌کنید، می‌توانید از این بخش صرف نظر کنید و به «مراحل تشخیصی بیشتر برای کاربران ابر خصوصی و عمومی» بروید.

  1. بررسی کنید که آیا می‌توانید با استفاده از دستور telnet مستقیماً از هر یک از پردازنده‌های پیام به سرور backend خاص متصل شوید:

    1. اگر سرور backend به یک آدرس IP واحد متصل می‌شود، از این دستور استفاده کنید:

      telnet BackendServer-IPaddress 443

    2. اگر سرور backend به چندین آدرس IP متصل است، از نام میزبان سرور backend در دستور telnet مانند تصویر زیر استفاده کنید:

      telnet BackendServer-HostName 443

    اگر توانستید بدون هیچ خطایی به سرور backend متصل شوید، به مرحله بعدی بروید.

    اگر دستور telnet با شکست مواجه شد، باید با تیم شبکه خود همکاری کنید تا اتصال بین پردازنده پیام و سرور backend را بررسی کنید.

  2. فایل گزارش پردازشگر پیام را برای یافتن شواهدی از خطای handshake بررسی کنید. فایل را باز کنید:

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

    و شناسه منحصر به فرد پیام (مقدار X-Apigee.Message-ID که در فایل ردیابی پیدا کردید) را جستجو کنید. همانطور که در زیر نشان داده شده است، مشخص کنید که آیا پیام خطای handshake مرتبط با شناسه پیام را مشاهده می‌کنید یا خیر:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

اگر این خطا را در فایل گزارش پردازنده پیام مشاهده کردید، به بررسی بیشتر ادامه دهید. به مراحل تشخیصی بیشتر برای کاربران Edge Private و Public Cloud بروید.

اگر پیام handshake را در فایل لاگ مشاهده نمی‌کنید، به Must Gather Diagnostic Information بروید.

مراحل تشخیصی بیشتر برای کاربران Edge Private و Public Cloud

برای مشخص کردن دقیق‌تر مشکل، می‌توانید از ابزار tcpdump برای تجزیه و تحلیل بسته‌های TCP/IP استفاده کنید تا تأیید کنید که آیا در طول فرآیند TLS/SSL handshake، وقفه زمانی رخ داده است یا خیر.

  1. اگر شما یک کاربر ابر خصوصی هستید، می‌توانید بسته‌های TCP/IP را روی سرور backend یا پردازشگر پیام ضبط کنید. ترجیحاً، آنها را روی سرور backend ضبط کنید، زیرا بسته‌ها در سرور backend رمزگشایی می‌شوند.
  2. اگر شما یک کاربر ابر عمومی هستید، به پردازشگر پیام دسترسی ندارید؛ با این حال، ضبط بسته‌های TCP/IP در سرور backend ممکن است به شناسایی مشکل کمک کند.

  3. پس از تصمیم گیری در مورد محل ضبط بسته های TCP/IP، از دستور tcpdump زیر برای ضبط بسته های TCP/IP استفاده کنید.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • اگر بسته‌های TCP/IP را روی سرور backend دریافت می‌کنید، از آدرس IP عمومی پردازنده پیام در دستور tcpdump استفاده کنید. برای کمک در استفاده از دستور برای بررسی ترافیک سرور backend، به tcpdump مراجعه کنید.

    • اگر بسته‌های TCP/IP را در پردازنده پیام دریافت می‌کنید، از آدرس IP عمومی سرور backend در دستور tcpdump استفاده کنید. برای کمک در استفاده از دستور برای بررسی ترافیک پردازنده پیام، به tcpdump مراجعه کنید.

    • اگر چندین آدرس IP برای سرور backend/پردازنده پیام وجود دارد، باید از دستور tcpdump دیگری استفاده کنید. برای اطلاعات بیشتر در مورد این ابزار و سایر انواع این دستور به tcpdump مراجعه کنید.

  4. بسته‌های TCP/IP را با استفاده از ابزار Wireshark یا ابزاری مشابه تجزیه و تحلیل کنید. تصویر زیر بسته‌های TCP/IP را در Wireshark نشان می‌دهد.

  5. به خروجی Wireshark توجه کنید که دست‌دهی سه‌طرفه TCP در ۳ بسته اول با موفقیت انجام می‌شود.

  6. سپس پردازشگر پیام، پیام "سلام به کلاینت" را در بسته شماره ۴ ارسال می‌کند.

  7. از آنجا که هیچ تأییدی از سرور backend وجود ندارد، پردازنده پیام پس از انتظار برای یک بازه زمانی از پیش تعریف شده، پیام "سلام مشتری" را چندین بار در بسته‌های ۵، ۶ و ۷ ارسال می‌کند.

  8. وقتی پردازشگر پیام پس از ۳ بار تلاش مجدد هیچ تأییدی دریافت نکند، پیام FIN, ACK را به سرور پشتیبان ارسال می‌کند تا اعلام کند که اتصال را می‌بندد.

  9. همانطور که در مثال Wireshark نشان دادید، اتصال به backend موفقیت‌آمیز است (مرحله ۱)، با این حال، زمان برقراری ارتباط SSL به پایان رسیده است زیرا سرور backend هرگز پاسخی نداده است.

اگر مراحل عیب‌یابی موجود در این راهنما را انجام داده‌اید و تشخیص داده‌اید که یک وقفه زمانی باعث خطای TLS/SSL handshake شده است، به بخش Resolution بروید.

استفاده از مانیتورینگ API برای شناسایی مشکل

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

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

وضوح تصویر

معمولاً وقفه‌های زمانی SSL handshake به دلیل محدودیت‌های فایروال روی سرور backend رخ می‌دهد که ترافیک Apigee Edge را مسدود می‌کند. اگر مراحل تشخیصی را دنبال کردید و تشخیص دادید که علت خطای handshake، وقفه زمانی است، باید تیم شبکه خود را برای شناسایی علت و رفع محدودیت‌های فایروال درگیر کنید.

توجه داشته باشید که محدودیت‌های فایروال می‌تواند در لایه‌های مختلف شبکه اعمال شود. مهم است که مطمئن شوید محدودیت‌های مربوط به IPهای پردازنده پیام در تمام لایه‌های شبکه حذف شده‌اند تا جریان ترافیک روان بین Apigee Edge و سرور backend تضمین شود.

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

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

اگر مشکل حتی پس از دنبال کردن دستورالعمل‌های بالا ادامه داشت، لطفاً اطلاعات تشخیصی زیر را جمع‌آوری کنید. با پشتیبانی Apigee Edge تماس بگیرید و آنها را به اشتراک بگذارید:

  1. اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:
    1. نام سازمان
    2. نام محیط
    3. نام پروکسی API
    4. دستور curl را برای بازتولید خطا کامل کنید
    5. فایل ردیابی که خطا را نشان می‌دهد
    6. بسته‌های TCP/IP که در سرور backend ضبط می‌شوند
  2. اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:
    1. پیام خطای کامل مشاهده شد
    2. بسته پروکسی API
    3. فایل ردیابی که خطا را نشان می‌دهد
    4. گزارش‌های پردازشگر پیام /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. بسته‌های TCP/IP که در سرور backend یا پردازنده پیام ضبط می‌شوند.
  3. جزئیات مربوط به بخش‌هایی از این دفترچه راهنما که شما امتحان کرده‌اید و هرگونه اطلاعات دیگری که به ما در تسریع حل این مشکل کمک می‌کند.