‫۵۰۲ دروازه نادرست - سوکت قطع شد

درحال مشاهده اسناد 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] شامل نام میزبان و درگاه سرور هدف نیز در عنصر دوم وجود خواهد داشت. در این مثال، مقدار آن X.X.X.X: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 و سرور پشتیبان را در سیستم‌عامل میزبان 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 در بسته ۲۶۲۴۴۱ پاسخ می‌دهد.

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

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

1. ‫Edge Microgateway ویژگی زمان اتمام مشخصی برای زنده نگه داشتن ندارد. این مقدار توسط سیستم‌عاملی که برنامه در آن اجرا می‌شود تعیین می‌شود. نمونه‌های رایج عبارت‌اند از Windows، Linux، و محتوی‌های Docker.
2. ممکن است این مورد در سیستم‌عامل سفارشی‌سازی شده باشد. با سرپرست سیستم خود تماس بگیرید. به‌طور پیش‌فرض، سیستم‌عامل‌های Linux دارای مهلت زمانی پیش‌فرض دو ساعته برای زنده نگه داشتن هستند.
3. سپس، ویژگی مهلت زمانی فعال نگه داشتن پیکربندی‌شده در سرور نهایی را بررسی کنید. فرض کنیم سرور زیرینه شما با مقدار ۱۰ ثانیه پیکربندی شده است.
4. اگر متوجه شدید که مقدار مهلت زمانی فعال نگه داشتن در سیستم‌عامل بیشتر از مقدار دارایی مهلت زمانی فعال نگه داشتن در سرور زیرینه است، همان‌طور که در مثال بالا نشان داده شده است، این دلیل خطاهای 502 است.

وضوح

مطمئن شوید که ویژگی مهلت زمانی فعال نگه داشتن در سیستم‌عاملی که Edge Microgateway در آن اجرا می‌شود همیشه کمتر از ویژگی مهلت زمانی فعال نگه داشتن در سرور زیرینه باشد.

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

روال مطلوب

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

1. مهلت زمانی فعال نگه داشتن در برنامه مشتری یا ترازکننده بار باید کمتر از مهلت زمانی فعال نگه داشتن Edge Microgateway باشد.

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

   وضوح

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

   اگر مشکل ادامه داشت و برای عیب‌یابی 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 وجود دارد. لطفاً این فایل را به‌طور کامل برای سازمان و محیط تحت‌تأثیر قرارگرفته بارگذاری کنید.