خطای 502 Bad Gateway Timeout

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

علامت

برنامه مشتری یک خطای 502 Bad Gateway دریافت می کند. پردازشگر پیام زمانی که پاسخی از یک سرور باطن دریافت نمی کند، این خطا را به برنامه مشتری برمی گرداند.

پیغام خطا

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

HTTP/1.1 502 Bad Gateway

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

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

علت احتمالی

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

علت توضیحات مراحل عیب یابی را می توان توسط
پایان زمان دست دادن TLS/SSL در طول دست دادن TLS/SSL بین پردازشگر پیام و سرور باطن یک مهلت زمانی رخ می دهد. کاربران Edge Private و Public Cloud

علت: پایان زمان دست دادن TLS/SSL

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

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

تشخیص

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

خروجی جلسه Trace را بررسی کنید

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

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

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

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

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

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

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

برای تأیید اینکه مهلت زمانی TLS/SSL Handshake دلیل این خطا بوده است، بسته به اینکه در Public Cloud یا Private Cloud هستید، مراحل زیر را دنبال کنید.

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

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

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

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

      telnet BackendServer-IPaddress 443

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

      telnet BackendServer-HostName 443

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

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

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

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

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

    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 بروید.

اگر پیام دست دادن را در فایل گزارش مشاهده نکردید، به قسمت Must Gather Diagnostic Information بروید

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

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

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

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

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

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

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

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

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

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

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

  7. از آنجایی که هیچ تاییدی از سوی سرور باطن وجود ندارد، پردازشگر پیام پیام "سلام مشتری" را چندین بار در بسته های 5، 6 و 7 پس از انتظار برای یک بازه زمانی از پیش تعریف شده، دوباره ارسال می کند.

  8. هنگامی که پردازشگر پیام پس از 3 تلاش مجدد هیچ تاییدیه ای دریافت نمی کند، پیام FIN، ACK را به سرور پشتیبان ارسال می کند تا نشان دهد که در حال بستن اتصال است.

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

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

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

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

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

قطعنامه

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

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

اگر هیچ محدودیتی برای فایروال وجود ندارد و/یا مشکل همچنان پابرجاست، به Must Gather Diagnostic Information بروید.

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

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

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