502 Bad Gateway - سوکت قطع شد

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

علامت

برنامه‌ی کلاینت، کد وضعیت HTTP 502 Bad Gateway را به همراه کد ECONNRESET به عنوان پاسخی برای فراخوانی‌های API در Edge Microgateway دریافت می‌کند.

پیام خطا

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

HTTP/1.1 502 Bad Gateway

پاسخ شامل پیام خطای زیر خواهد بود:

{"message":"socket hang up","code":"ECONNRESET"}

علل احتمالی

مراحل تشخیص مشترک

1. لاگ‌های Edge Microgateway را بررسی کنید:

   /var/tmp/edgemicro-`hostname`-*.log

2. جستجو کنید تا ببینید آیا در یک دوره زمانی خاص (اگر مشکل در گذشته رخ داده است) خطاهای 502 با کد ECONNRESET وجود دارد یا خیر، یا اینکه آیا درخواست‌هایی وجود دارد که هنوز با 502 با شکست مواجه می‌شوند.

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. اگر سطح ثبت وقایع را روی warn یا info تنظیم کرده باشید، یک پیام [warn] نیز شامل نام میزبان سرور هدف و پورت در عنصر دوم وجود خواهد داشت. در این مثال XXXX:8080 است و می‌توان بعداً از آن برای ضبط tcpdump استفاده کرد.

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. کد خطا [socket hang up][ECONNRESET] نشان می‌دهد که سرور هدف اتصال با Edge Microgateway را قطع کرده است. این کد را می‌توان در لاگ‌ها جستجو کرد تا مشخص شود که این اتفاق چند وقت یکبار رخ می‌دهد.

علت: زمان انقضای keep-alive به درستی پیکربندی نشده است

تشخیص

1. از مراحل موجود در مراحل تشخیص رایج استفاده کنید و بررسی کنید که آیا خطای [socket hang up][ECONNRESET] را دریافت کرده‌اید یا خیر.

2. اگر بله، با کمک tcpdump همانطور که در زیر توضیح داده شده است، بیشتر بررسی کنید:

استفاده از tcpdump

1. با دستور زیر، یک tcpdump بین Edge Microgateway و سرور backend در سیستم عامل میزبان Edge Microgateway ضبط کنید:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. tcpdump ضبط شده را تجزیه و تحلیل کنید:

   نمونه خروجی tcpdump: ( تصویر بزرگتر را ببینید )

   

   در نمونه tcpdump بالا، می‌توانید موارد زیر را مشاهده کنید:

   1. در بسته‌ی ۲۵۰۲۸۸ ، کلاینت یک درخواست POST ارسال می‌کند.
   2. در بسته‌ی ۲۵۰۳۷۱ ، سرور با 200 OK پاسخ می‌دهد.
   3. در بسته‌ی ۲۵۰۵۵۹ ، کلاینت یک ACK.
   4. در بسته‌ی ۲۵۰۵۶۰ ، سرور پیام Continuation را ارسال می‌کند.
   5. در بسته‌ی ۲۵۰۵۶۱ ، کلاینت یک ACK.
   6. در بسته‌ی ۲۶۲۴۳۶ ، سرور یک FIN, ACK به کلاینت ارسال می‌کند که باعث شروع بسته شدن اتصال می‌شود. توجه داشته باشید که این تقریباً پنج ثانیه پس از بسته‌ی قبلی ( ۲۵۰۵۶۱ ) است.
   7. در بسته‌ی ۲۶۲۴۴۱ ، کلاینت یک درخواست POST دیگر ارسال می‌کند. با این حال، این درخواست با شکست مواجه می‌شود زیرا سرور از قبل شروع به بستن اتصال کرده است. در بسته‌ی ۲۶۲۴۴۱ با یک RST پاسخ می‌دهد.

   در این مثال، همان اتصال حداقل یک بار با موفقیت دوباره استفاده شد، اما در درخواست نهایی، سرور پس از پنج ثانیه زمان بیکاری، که اتفاقاً همزمان با ارسال درخواست جدید توسط کلاینت است، اتصال را می‌بندد. این نشان می‌دهد که زمان انتظار keep-alive سرور backend به احتمال زیاد کوتاه‌تر یا مساوی با مقدار تعیین شده در کلاینت است. برای تأیید این موضوع، به مقایسه زمان انتظار keep-alive در Edge Microgateway و سرور backend مراجعه کنید.

مقایسه زمان‌های انتظار Keep-alive

1. Edge Microgateway ویژگی زمان‌بندی خاصی برای keep-alive ندارد. این زمان‌بندی توسط سیستم‌عاملی که روی آن اجرا می‌شود تعیین می‌شود. نمونه‌های رایج آن ویندوز، لینوکس و کانتینرهای داکر هستند.
2. ممکن است این مورد در سیستم عامل سفارشی‌سازی شده باشد. با مدیر سیستم خود مشورت کنید. به طور پیش‌فرض، سیستم عامل‌های لینوکس دارای یک زمان انقضای دو ساعته هستند.
3. در مرحله بعد، ویژگی keep-alive timeout که در سرور backend شما پیکربندی شده است را بررسی کنید. فرض کنید سرور backend شما با مقدار 10 ثانیه پیکربندی شده است.
4. اگر مانند مثال بالا تشخیص دهید که مقدار زمان انتظار keep-alive در سیستم عامل بیشتر از مقدار ویژگی keep-alive timeout در سرور backend است، در این صورت دلیل خطای 502 همین است.

وضوح تصویر

اطمینان حاصل کنید که ویژگی زمان‌بندی keep-alive همیشه در سیستم عاملی که Edge Microgateway در آن اجرا می‌شود، در مقایسه با سرور backend، کمتر باشد.

1. مقدار تعیین‌شده برای زمان انتظار keep-alive در سرور backend را تعیین کنید.
2. با استفاده از مراحلی که برای سیستم عامل شما قابل اجرا است، مقدار مناسبی را برای ویژگی زمان انتظار keep-alive در سیستم عامل پیکربندی کنید، به طوری که ویژگی زمان انتظار keep-alive کمتر از مقدار تعیین شده در سرور backend باشد.

بهترین روش

اکیداً توصیه می‌شود که اجزای پایین‌دستی همیشه آستانه‌ی زمان انتظار برای زنده ماندن (keep-alive timeout) کمتری نسبت به سرورهای بالادستی داشته باشند تا از این نوع شرایط رقابتی و خطاهای 502 جلوگیری شود. هر گام پایین‌دستی باید کمتر از هر گام بالادستی باشد. در Edge Microgateway، استفاده از دستورالعمل‌های زیر روش خوبی است:

1. زمان انتظار برای زنده ماندن (keep-alive timeout) در برنامه کلاینت یا متعادل‌کننده بار (load balancer) باید کمتر از زمان انتظار برای زنده ماندن (keep-alive timeout) در Edge Microgateway باشد.

   برای پیکربندی زمان انتظار keep-alive در Edge Microgateway، مقدار keep_alive_timeout را به فایل ~/.edgemicro/org-env-config.yaml خود اضافه کنید.

   edgemicro:
     keep_alive_timeout: 65000

2. زمان انتظار برای زنده ماندن سیستم عامل Edge Microgateway باید کمتر از زمان انتظار برای زنده ماندن سرور هدف باشد.
3. اگر هر هاپ دیگری در جلو یا پشت Edge Microgateway دارید، همین قانون باید اعمال شود. شما همیشه باید مسئولیت بستن اتصال با بالادست را به کلاینت پایین‌دست واگذار کنید.

علت: سرور هدف اتصال را قبل از موعد مقرر قطع می‌کند

تشخیص

1. از مراحل توضیح داده شده در مراحل عیب‌یابی رایج استفاده کنید و بررسی کنید که آیا خطای [socket hang up][ECONNRESET] را دریافت کرده‌اید یا خیر.
2. اگر بله، پس با کمک tcpdump همانطور که در زیر توضیح داده شده است، بیشتر بررسی کنید.

   پیام خطای [targetRequest error][GET][] [socket hang up][ECONNRESET] در مثال بالا نشان می‌دهد که این خطا هنگام ارسال درخواست توسط Edge Microgateway به سرور backend (هدف) رخ داده است. یعنی، Edge Microgateway درخواست API را به سرور backend ارسال کرده و منتظر پاسخ بوده است. با این حال، سرور backend قبل از اینکه Edge Microgateway پاسخی دریافت کند، اتصال را به طور ناگهانی قطع کرده است.

3. لاگ‌های سرور بک‌اند خود را بررسی کنید و ببینید آیا خطا یا اطلاعاتی وجود دارد که بتواند باعث شود سرور بک‌اند اتصال را به طور ناگهانی قطع کند. اگر هرگونه خطا یا اطلاعاتی پیدا کردید، به بخش حل مشکل بروید و مشکل را به طور مناسب در سرور بک‌اند خود برطرف کنید.
4. اگر هیچ خطا یا اطلاعاتی در سرور backend خود پیدا نکردید، خروجی tcpdump را در سرور Edge Microgateway جمع‌آوری کنید:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. tcpdump ضبط شده را تجزیه و تحلیل کنید:

   نمونه خروجی tcpdump: ( تصویر بزرگتر را ببینید )

   

   در نمونه tcpdump بالا، می‌توانید موارد زیر را مشاهده کنید:

   1. در بسته شماره ۴ ، Edge Microgateway یک درخواست GET به سرور هدف ارسال کرد.
   2. در بسته ۵ ، سرور هدف با ACK به منظور تأیید درخواست پاسخ داد.
   3. با این حال، در بسته ۶ ، به جای پاسخ دادن با یک payload پاسخ، سرور هدف یک FIN, ACK ارسال می‌کند که باعث بسته شدن اتصال می‌شود.
   4. در بسته‌های ۷ به بعد، اتصال به صورت متقابل بسته می‌شود. از آنجایی که اتصال قبل از ارسال پاسخ بسته شده است، Edge Microgateway خطای HTTP 502 را به کلاینت برمی‌گرداند.
   5. توجه داشته باشید که مهر زمانی بسته ۸ ، 2021-06-23T03:52:24.110Z ، با مهر زمانی که خطا در لاگ‌های Edge Microgateway ثبت شده است، مطابقت دارد. مهرهای زمانی موجود در فایل‌های لاگ و در tcpdump اغلب می‌توانند برای مرتبط کردن خطاها با بسته‌های واقعی استفاده شوند.

   وضوح تصویر

   مشکل را در سرور backend به طور مناسب برطرف کنید.

   اگر مشکل همچنان ادامه داشت و برای عیب‌یابی 502 Bad Gateway Error به کمک نیاز داشتید یا گمان می‌کنید که مشکل از Edge Microgateway است، به «باید اطلاعات تشخیصی را جمع‌آوری کنید» بروید.

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

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

   • فایل‌های لاگ : پوشه پیش‌فرض /var/tmp است، اما ممکن است در فایل اصلی config.yaml ( logging > dir parameter ) بازنویسی شود. توصیه می‌شود قبل از ارائه فایل‌های لاگ به پشتیبانی Apigee، log > level را به info تغییر دهید.
   • فایل پیکربندی : پیکربندی اصلی Edge Microgateway در فایل YAML در پوشه پیش‌فرض Edge Microgateway، $HOME/.edgemicro ، قرار دارد. یک فایل پیکربندی پیش‌فرض به نام default.yaml و سپس یکی برای هر محیط ORG - ENV -config.yaml وجود دارد. لطفاً این فایل را به طور کامل برای org و env آسیب‌دیده بارگذاری کنید.