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

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP 502 Bad Gateway مع الرمز ECONNRESET كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات في Edge Microgateway.

رسالة الخطأ

سيرى العميل رمز الاستجابة التالي: 

HTTP/1.1 502 Bad Gateway

سيتضمّن الرد رسالة الخطأ التالية: 

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

الأسباب المحتملة

السبب الوصف إرشادات استكشاف الأخطاء وإصلاحها التي تنطبق على
تم ضبط مهلة الاحتفاظ بالبيانات بشكل غير صحيح تم ضبط مهلات Keep-alive على نحو غير صحيح بين بوابة Edge Microgateway والخادم الهدف. مستخدمو Edge Public و Private Cloud
الخادم المستهدف يغلق الاتصال قبل أوانه يغلق الخادم الهدف الاتصال مبكرًا أثناء إرسال بوابة Edge Microgateway حمولة الطلب. مستخدمو Edge Public و Private Cloud

خطوات التشخيص الشائعة

  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. إذا حددت أن قيمة مهلة المحافظة على الاتصال في نظام التشغيل هي قيمة أعلى من قيمة خاصية Keep-alive المهلة على خادم الخلفية كما في المثال أعلاه، فإن ذلك هو سبب حدوث أخطاء 502.

الدقة

تأكد من أن خاصية مهلة الاحتفاظ بالآخرين تكون دومًا أدنى من نظام التشغيل حيث تستخدم شبكة Edge يتم تشغيل Microgateway مقارنةً بذلك على خادم الخلفية.

  1. حدِّد القيمة التي تم ضبطها لمهلة التحقّق من الاتصال على خادم الخلفية.
  2. ضبط قيمة مناسبة لخاصية مهلة الاحتفاظ بالآخر في التشغيل بحيث تكون خاصية مهلة الاحتفاظ بالآخر أقل من القيمة المعيّنة في الخلفية الخادم، باستخدام الخطوات التي تنطبق على نظام التشغيل الذي تستخدمه.

أفضل الممارسات

ننصح بشدة بأن يتم دائمًا تحديد مهلة أقل لمكوّنات عملية النقل. عن الذي تم تكوينه في الخوادم الرئيسية لتجنب هذه الأنواع من شروط السباق 502 خطأً. يجب أن تكون كل قفزة في مرحلة ما بعد بيع التطبيق أقل من كل قفزة رئيسية. في Edge مدخل قصير، يفضَّل استخدام الإرشادات التالية:

  1. يجب أن تكون مهلة الاحتفاظ بالرسالة في تطبيق العميل أو جهاز موازنة الحمل أقل من مهلة إبقاء بوابة الاتصال القصير على Edge

    لضبط مهلة البقاء على قيد الحياة على بوابة 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 كان يرسل الطلب إلى خادم الخلفية (target). أي أن بوابة 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 عرض HTTP 502 الخطأ مرة أخرى إلى العميل.
    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 Support.
    • ملف التهيئة: تكمن التهيئة الرئيسية لـ Edge Microgateway في YAML في مجلد Edge Microgateway التلقائي، $HOME/.edgemicro. تتوفر ملف إعداد تلقائي باسم default.yaml ثم ملف إعداد واحد لكل بيئة ORG-ENV-config.yaml يُرجى تحميل هذا الملف. المؤسسة والبيئة المتأثّرة