502 مدخل غير صالح - إنهاء الاتصال

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP 502 Bad Gateway مع الرمز ECONNRESET كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات في 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. في الحزمة 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 خاصية مهلة محدّدة لإبقاء الاتصال نشطًا. ويتم تحديدها من خلال نظام التشغيل الذي يتم تشغيلها عليه. وتشمل الأمثلة الشائعة أنظمة التشغيل Windows وLinux وحاويات Docker.
2. من المحتمل أن يتم تخصيص هذا الإعداد في نظام التشغيل. يُرجى التواصل مع مشرف النظام. تتضمّن أنظمة التشغيل Linux تلقائيًا مهلة تلقائية لإبقاء الاتصال نشطًا تبلغ ساعتين.
3. بعد ذلك، تحقَّق من خاصية المهلة المحدّدة لعملية إبقاء الاتصال نشطًا التي تم ضبطها على خادم الخلفية. لنفترض أنّ خادم الخلفية مضبوط على قيمة 10 ثوانٍ.
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 أرسل طلب البيانات من واجهة برمجة التطبيقات إلى خادم الخلفية وكان ينتظر الردّ. ومع ذلك، أنهى خادم الخلفية الاتصال فجأة قبل أن يتلقّى Edge Microgateway استجابة.

3. راجِع سجلّات خادم الخلفية لمعرفة ما إذا كانت هناك أي أخطاء أو معلومات قد تكون أدّت إلى إنهاء الخادم للاتصال بشكل مفاجئ. إذا عثرت على أي أخطاء أو معلومات، انتقِل إلى الحلّ وأصلِح المشكلة بشكل مناسب في خادم الخلفية.
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 الخطأ 502 HTTP للعميل.
   5. يُرجى العِلم أنّ الطابع الزمني للحزمة 8، 2021-06-23T03:52:24.110Z يتوافق مع الطابع الزمني الذي تم فيه تسجيل الخطأ في سجلّات Edge Microgateway. يمكن غالبًا استخدام الطوابع الزمنية في ملفات السجلّ وفي tcpdump لربط الأخطاء بالحِزم الفعلية.

   الدقة

   أصلِح المشكلة على خادم الخلفية بشكلٍ مناسب.

   إذا استمرت المشكلة وكنت بحاجة إلى مساعدة في تحديد المشاكل وحلّها في 502 Bad Gateway Error أو إذا كنت تعتقد أنّ المشكلة في Edge Microgateway، انتقِل إلى المعلومات التشخيصية التي يجب جمعها.

   يجب جمع معلومات التشخيص

   إذا استمرت المشكلة حتى بعد اتّباع التعليمات أعلاه، اجمع معلومات التشخيص التالية ثم تواصَل مع فريق دعم Apigee Edge:

   • ملفات السجلّ: المجلد التلقائي هو /var/tmp، ولكن يمكن إلغاء هذا الإعداد في ملف config.yaml الرئيسي (logging > dir parameter). يُنصح بتغيير log > level إلى info قبل تقديم ملفات السجلّ إلى فريق الدعم في Apigee.
   • ملف الإعداد: تقع الإعدادات الرئيسية لـ Edge Microgateway في ملف YAML في مجلد Edge Microgateway التلقائي، $HOME/.edgemicro. هناك ملف إعداد تلقائي باسم default.yaml، ثم ملف لكل بيئة ORG-ENV-config.yaml. يُرجى تحميل هذا الملف بالكامل للمؤسسة والبيئة المتأثرتين.