503 الخدمة غير متوفرة - إغلاق مبكر من خادم الخلفية

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

المشكلة

يحصل تطبيق العميل على حالة استجابة HTTP 503 مع الرسالة. Service Unavailable بعد استدعاء خادم وكيل لواجهة برمجة التطبيقات.

رسالة الخطأ

يحصل تطبيق العميل على رمز الاستجابة التالي:

HTTP/1.1 503 Service Unavailable

بالإضافة إلى ذلك، قد تلاحظ رسالة الخطأ التالية:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

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

السبب الوصف إرشادات استكشاف الأخطاء وإصلاحها التي تنطبق على
الخادم المستهدف يغلق الاتصال قبل أوانه ينهي الخادم المستهدف الاتصال قبل أوانه بينما لا يزال معالج الرسائل لا يزال إرسال حمولة الطلب. مستخدمو Edge Public و Private Cloud

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

تحديد رقم تعريف الرسالة للطلب الذي تعذّر إكماله

أداة التتبُّع

لتحديد معرّف الرسالة للطلب الذي تعذّر إكماله باستخدام أداة التتبُّع:

  1. إذا كانت المشكلة لا تزال قائمة، ففعِّل جلسة التتبّع لواجهة برمجة التطبيقات المتأثرة.
  2. إجراء طلب بيانات من واجهة برمجة التطبيقات وإعادة إظهار المشكلة - 503 Service Unavailable مع رمز الخطأ messaging.adaptors.http.flow.ServiceUnavailable.
  3. اختَر أحد الطلبات التي تعذّر تنفيذها.
  4. انتقِل إلى مرحلة AX، وحدِّد رقم تعريف الرسالة. (X-Apigee.Message-ID) من الطلب من خلال التمرير لأسفل في قسم تفاصيل المرحلة كما هو موضح في الشكل التالي.

    رقم تعريف الرسالة في قسم "تفاصيل المرحلة"

سجلات وصول NGINX

لتحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه باستخدام سجلات الوصول إلى NGINX:

يمكنك أيضًا الرجوع إلى سجلّات NGINX Access لتحديد معرِّف الرسالة لأخطاء 503. يفيد ذلك بشكل خاص إذا حدثت المشكلة في الماضي أو إذا كانت المشكلة متكررة. ولا يمكنك تسجيل آثار الأنشطة في واجهة المستخدم. اتّبِع الخطوات التالية لتحديد هذه المعلومات من سجلات وصول NGINX:

  1. تحقَّق من سجلات وصول NGINX: (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  2. ابحث لمعرفة ما إذا كانت هناك أي أخطاء 503 للخادم الوكيل المحدّد لواجهة برمجة التطبيقات خلال مدة محدّدة. (إذا حدثت المشكلة في الماضي) أو إذا كانت هناك أي طلبات لا تزال يتعذّر تنفيذها مع 503.
  3. إذا كان هناك أي أخطاء 503 في X-Apigee-Error-code message.adaptors.http.flow.ServiceUnavailable، دوِّن معرّف الرسالة لطلب واحد أو أكثر من هذه الطلبات كما هو موضّح في المثال التالي:

    نموذج إدخال يعرض الخطأ 503

    نموذج إدخال يعرض رمز الحالة ومعرّف الرسالة ومصدر الخطأ ورمز الخطأ

السبب: الخادم المستهدف يغلق الاتصال قبل أوانه

التشخيص

  1. إذا كنت مستخدمًا في السحابة الإلكترونية العامة أو السحابة الإلكترونية الخاصة:
    1. استخدام أداة التتبُّع (كما هو موضّح في خطوات التشخيص الشائعة) وتأكّد من أنّ لديك كلا الخيارين التاليين في جزء البيانات المسجَّلة في "إحصاءات Google":
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      alt_text

    2. استخدام أداة التتبُّع (كما هو موضّح في خطوات التشخيص الشائعة) وتحقَّق من أنّ لديك المجموعتَين التاليتَين في جزء الخطأ مباشرةً بعد السمة الولاية TARGET_REQ_FLOW:
      • error.class: com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      alt_text

    3. انتقِل إلى استخدام tcpdump لمزيد من التحقيق.
  2. إذا كنت أحد مستخدمي السحابة الإلكترونية الخاصة:
    • حدِّد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه.
    • البحث عن معرِّف الرسالة في سجل معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    • سيظهر لك أحد الاستثناءات التالية:

      الاستثناء 1: java.io.IOException: حدث عطل في القناة أثناء الكتابة في القناة ClientOutputChannel

      2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
      rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
      INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
      Exception java.io.IOException: Broken pipe occurred while writing to channel
      ClientOutputChannel(ClientChannel[Connected:
      Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
      bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)
      

      أو

      الاستثناء 2: onExceptionWrite استثناء: {}
      java.io.IOException: ممر معطّل

      2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
      rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
      ClientChannel[Connected: Remote:IP:PORT
      Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
      ms  isOpen=false.onExceptionWrite exception: {}
      java.io.IOException: Broken pipe
      
    • يشير كلا هذين الاستثناءين إلى أنه بينما كان معالج الرسائل لا يزال يكتب لطلب حمولة البيانات إلى خادم الخلفية، تم إغلاق الاتصال قبل أوانه من قبل خادم الخلفية. وبالتالي، يطرح معالج الرسائل الاستثناء java.io.IOException: Broken pipe.
    • تشير العلامة Remote:IP:PORT إلى خادم الخلفية الذي تم التعامل معه. عنوان IP ورقم المنفذ.
    • تشير السمة bytesWritten=76295 في رسالة الخطأ أعلاه إلى أن معالج الرسائل أرسل حمولة بيانات تبلغ 76295 بايت إلى الخلفية الخادم عندما تم إغلاق الاتصال قبل أوانه.
    • تشير السمة bytesRead=0 إلى أنّ معالج الرسائل لم تلقى أي بيانات (استجابة) من خادم الخلفية.
    • للتحقيق أكثر في هذه المشكلة، يُرجى جمع tcpdump إما في الخلفية. أو معالج الرسائل وتحليلها كما هو موضح أدناه.

استخدام tcpdump

  1. يمكنك التقاط صورة tcpdump إما على خادم الخلفية أو على معالج الرسائل باستخدام الأوامر التالية:

    أمر لجمع tcpdump على خادم الخلفية:

    tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
    

    أمر لجمع tcpdump على "معالج الرسائل":

    tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
    
  2. تحليل tcpdump التي تم التقاطها:

    نموذج لمخرجات tcpdump (التي تم جمعها في معالج الرسائل):

    alt_text

    في tcpdump أعلاه، يمكنك الاطّلاع على ما يلي:

    1. في الحزمة 4، أرسل معالج الرسائل طلب POST إلى خادم الخلفية.
    2. الحزمة 5 و8 و 9 و10 11، واصل معالج الرسائل إرسال حمولة الطلب إلى خادم الخلفية.
    3. في الحزمة 6 و7، استجاب خادم الخلفية بـ ACK لجزء من حمولة الطلب التي تم استلامها من "معالج الرسائل"
    4. ومع ذلك، في الحزمة 12، بدلاً من الاستجابة باستخدام ACK لحزم بيانات التطبيق التي تم استلامها وبالتالي الاستجابة المستخدم، يستجيب خادم الخلفية بدلاً من ذلك بعلامة FIN ACK التي تبدأ بإغلاق الاتصال.
    5. يشير ذلك بوضوح إلى أنّ خادم الخلفية يغلق الاتصال قبل أوانه بينما كان معالج الرسائل لا يزال يرسل حمولة الطلب.
    6. يؤدي هذا إلى تسجيل معالج الرسائل لـ IOException: Broken Pipe وإرجاع 503 إلى العميل

الدقة

  1. تعاوَن مع فريقَي التطبيق والشبكات لديك أو كليهما لتحليل الأخطاء مشكلة انقطاع الاتصال المبكر على جانب خادم الخلفية.
  2. التأكد من عدم انتهاء مهلة تطبيق خادم الخلفية أو إعادة تعيين الاتصال قبل استلام حمولة الطلب بالكامل.
  3. إذا كان لديك أي جهاز شبكة وسيط أو طبقة بين Apigee وخادم الخلفية، ومن ثم التأكد من عدم انتهاء المهلة قبل استلام حمولة الطلب بالكامل.

في حال استمرار المشكلة، انتقِل إلى المقالة ضرورة جمع معلومات التشخيص.

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

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

إذا كنت من مستخدمي Cloud Public، يُرجى تقديم المعلومات التالية:

  • اسم المؤسسة
  • اسم البيئة
  • اسم الخادم الوكيل لواجهة برمجة التطبيقات
  • إكمال الأمر curl لإعادة إظهار الخطأ 503
  • ملف التتبُّع الذي يحتوي على الطلب مع الخطأ 503 Service Unavailable
  • إذا لم تظهر أخطاء 503 في الوقت الحالي، قدِّم الفترة الزمنية معلومات المنطقة الزمنية عند حدوث 503 خطأ في الماضي.

إذا كنت مستخدمًا للسحابة الإلكترونية الخاصة، قدِّم المعلومات التالية:

  • ظهور رسالة خطأ كاملة للطلبات التي تعذّر تنفيذها
  • اسم المؤسسة والبيئة واسم الخادم الوكيل لواجهة برمجة التطبيقات التي تراقبها خطآن (503)
  • حزمة الخادم الوكيل لواجهة برمجة التطبيقات
  • ملف التتبُّع الذي يحتوي على الطلبات التي تتضمّن خطأ واحد (503 Service Unavailable)
  • سجلّات وصول NGINX
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  • سجلات معالج الرسائل
    /opt/apigee/var/log/edge-message-processor/logs/system.log
  • الفترة الزمنية التي تتضمن معلومات المنطقة الزمنية وقت حدوث أخطاء 503
  • تم جمع Tcpdumps على معالِجات معالجة الرسائل وخادم الخلفية عند حدث خطأ