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 بسته است. این را می توان در گزارش ها جستجو کرد تا مشخص شود که چند بار اتفاق می افتد.

علت: تنظیم نادرست وقفه نگه داشتن زنده

تشخیص

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. در بسته 250288 ، مشتری یک درخواست POST ارسال می کند.
   2. در بسته 250371 سرور با 200 OK پاسخ می دهد.
   3. در بسته 250559 ، مشتری یک ACK.
   4. در بسته 250560 سرور پیغام Continuation را ارسال می کند.
   5. در بسته 250561 ، مشتری یک ACK.
   6. در بسته 262436 ، سرور یک FIN, ACK برای شروع بسته شدن اتصال به مشتری ارسال می کند. توجه داشته باشید که این تقریباً پنج ثانیه پس از بسته قبلی ( 250561 ) است.
   7. در بسته 262441 ، مشتری درخواست POST دیگری ارسال می کند. با این حال، این کار انجام نمی شود زیرا سرور قبلاً اتصال را بسته است. با یک RST در بسته 262441 پاسخ می دهد.

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

زمان‌های نگه‌داشتن زنده را مقایسه کنید

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

قطعنامه

اطمینان حاصل کنید که خاصیت timeout keep-alive در سیستم عاملی که Edge Microgateway در آن اجرا می شود در مقایسه با سرور باطن همیشه کمتر باشد.

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

بهترین تمرین

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

1. مهلت زمانی نگه داشتن زنده در برنامه مشتری یا متعادل کننده بار باید کمتر از مهلت زمانی نگه داشتن زنده 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 در حال ارسال درخواست به سرور باطن (هدف) بوده است. یعنی Edge Microgateway درخواست API را به سرور باطن ارسال کرد و منتظر پاسخ بود. با این حال، سرور باطن قبل از دریافت پاسخ Edge Microgateway به طور ناگهانی اتصال را قطع کرد.

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

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

5. tcpdump گرفته شده را تجزیه و تحلیل کنید:

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

   

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

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

   قطعنامه

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

   اگر مشکل همچنان ادامه دارد و برای عیب‌یابی 502 Bad Gateway Error نیاز به کمک دارید یا مشکوک هستید که این مشکل در Edge Microgateway است، به Must collect اطلاعات عیب‌یابی بروید.

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

   اگر حتی پس از پیروی از دستورالعمل‌های بالا، مشکل همچنان ادامه داشت، اطلاعات تشخیصی زیر را جمع‌آوری کنید و سپس با پشتیبانی 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 تحت تأثیر آپلود کنید.