502 مدخل غير متوقع (EOF) غير متوقَّع

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

المشكلة

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

يعني رمز حالة HTTP 502 أن العميل لا يتلقى استجابة صالحة من لخوادم الخلفية التي من المفترض أن تفي بالطلب فعلاً.

رسائل الخطأ

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

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

أحد الأسباب النموذجية وراء حدوث 502 Bad Gateway Error هو Unexpected EOF. من الخطأ، وقد يرجع ذلك إلى الأسباب التالية:

السبب	التفاصيل	الخطوات المقدمة لـ
ضبط الخادم الهدف بشكلٍ غير صحيح	لم يتم إعداد الخادم الهدف بشكلٍ صحيح لدعم اتصالات بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL).	مستخدمو Edge Public و Private Cloud
EOFException من خادم الخلفية	قد يرسل خادم الخلفية EOF بشكل مفاجئ.	مستخدمو Edge Private Cloud فقط
تم الضبط بشكل غير صحيح لمهلة البقاء حيًا	عليك إبقاء المهلات الصالحة التي تم ضبطها بشكل غير صحيح على Apigee وخادم الخلفية.	مستخدمو Edge Public و Private Cloud

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

لتشخيص الخطأ، يمكنك استخدام أي من الطرق التالية:

• مراقبة واجهة برمجة التطبيقات
• أداة التتبُّع
• سجلات وصول NGINX

السبب: الخادم الهدف الذي تم إعداده بشكل غير صحيح

لم يتم إعداد الخادم الهدف بشكلٍ صحيح لدعم اتصالات بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL).

التشخيص

1. استخدام مراقبة واجهة برمجة التطبيقات أو أداة التتبُّع سجلات وصول NGINX لتحديد رقم تعريف الرسالة، ورمز الخطأ ومصدر الخطأ للخطأ 502.
2. يمكنك تفعيل التتبُّع في واجهة المستخدم لواجهة برمجة التطبيقات المتأثرة.
3. إذا كان تتبُّع طلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه يظهر ما يلي:
   1. يظهر الخطأ 502 Bad Gateway فور بدء طلب المسار المستهدَف.
   2. تعرض error.class messaging.adaptors.http.UnexpectedEOF..

      إذًا، غالبًا ما تكون هذه المشكلة ناتجة عن خادم مستهدف غير صحيح. التكوين.

4. احصل على تعريف الخادم الهدف باستخدام طلب بيانات من واجهة برمجة التطبيقات لإدارة Edge:
   1. إذا كنت من مستخدمي Cloud Public، يمكنك استخدام واجهة برمجة التطبيقات هذه:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

   2. إذا كنت من مستخدمي Cloud Private، استخدِم واجهة برمجة التطبيقات هذه:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
      

      نموذج تعريف TargetServer خاطئ:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >
      

5. يعد تعريف TargetServer الموضح مثالاً لأحد التصنيفات النموذجية أخطاء في التهيئة، وهو موضح على النحو التالي:

   لنفترض أنه تم ضبط الخادم الهدف mocktarget.apigee.net. لقبول اتصالات آمنة (HTTPS) في المنفذ 443. ومع ذلك، إذا ألقيت نظرة على تعريف الخادم الهدف، فلا توجد سمات/علامات أخرى تشير إلى أنها لإنشاء اتصالات آمنة. ويؤدي هذا إلى تعامل Edge مع طلبات واجهة برمجة التطبيقات التي تنتقل إلى المحدد على الخادم المستهدف على هيئة طلبات HTTP (غير آمنة). إذًا، لن يستطيع Edge بدء عملية تأكيد اتصال طبقة المقابس الآمنة (SSL) مع هذا الخادم المستهدف.

   بما أنّ الخادم الهدف قد تم إعداده بحيث لا يقبل سوى طلبات HTTPS (طبقة المقابس الآمنة) على 443، سينفّذ الإجراء التالي: رفض الطلب من Edge أو إغلاق الاتصال. نتيجة لذلك، تحصل على خطأ واحد (UnexpectedEOFAtTarget) في معالج الرسائل. سيرسل معالج الرسائل 502 Bad Gateway كرد للعميل.

الدقة

تأكَّد دائمًا من ضبط الخادم الهدف بشكلٍ صحيح وفقًا لمتطلّباتك.

في المثال الموضَّح أعلاه، إذا كنت تريد إرسال طلبات إلى هدف آمن (HTTPS/طبقة المقابس الآمنة). الخادم، يجب تضمين سمات SSLInfo مع مجموعة العلامات enabled إلى true. مع أنّه يُسمح بإضافة سمات SSLInfo للخادم الهدف في الهدف تعريف نقطة النهاية نفسه، ننصحك بإضافة سمات SSLInfo كجزء من الهدف تعريف الخادم لتجنب أي لبس.

1. إذا كانت خدمة الخلفية تتطلب اتصالًا أحادي الاتجاه باستخدام طبقة المقابس الآمنة (SSL)، يجب عندها:
   1. يجب تفعيل بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) في تعريف TargetServer من خلال تضمين SSLInfo حيث يتم ضبط العلامة enabled على "صحيح" كما هو موضح أدناه:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
      

   2. إذا كنت تريد التحقق من صحة شهادة الخادم الهدف في Edge، فإننا بحاجة أيضًا إلى تضمين Truststore (يحتوي على شهادة الخادم الهدف) كما هو موضَّح أدناه:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>
      

2. إذا كانت خدمة الخلفية تتطلب اتصالاً ثنائي الاتجاه باستخدام طبقة المقابس الآمنة، يجب عندها:
   1. يجب أن تكون لديك SSLInfo سمة مع ClientAuthEnabled، Keystore وKeyAlias و تم ضبط علامات Truststore بشكل مناسب، كما هو موضّح أدناه:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >
      

المراجع

موازنة الحمل في جميع خوادم الخلفية

السبب: EOFException من خادم الخلفية

قد يرسل خادم الخلفية EOF (نهاية الملف) بشكل مفاجئ.

التشخيص

1. استخدام مراقبة واجهة برمجة التطبيقات أو أداة التتبُّع سجلات وصول NGINX لتحديد رقم تعريف الرسالة، ورمز الخطأ ومصدر الخطأ للخطأ 502.
2. التحقق من سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log) والبحث لمعرفة ما إذا eof unexpected لواجهة برمجة التطبيقات المحددة أو إذا كان لديك messageid الفريد لواجهة برمجة التطبيقات المطلوبة، فيمكنك بعد ذلك البحث عنها.

   نموذج تتبُّع تسلسل استدعاء الدوال البرمجية في الاستثناءات من سجلّ معالج الرسائل

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
   

   في المثال أعلاه، يمكنك ملاحظة أنّ الخطأ java.io.EOFException: eof unexpected حدث أثناء محاولة معالج الرسائل قراءة ردّ من. خادم الخلفية. يشير هذا الاستثناء إلى نهاية الملف (EOF) أو نهاية البث بشكل غير متوقع.

   وهذا يعني أنّ معالج الرسائل أرسل طلب البيانات من واجهة برمجة التطبيقات إلى خادم الخلفية وكان ينتظر أو قراءة الرد. ومع ذلك، أنهى خادم الخلفية الاتصال بشكل مفاجئ قبل أن يحصل معالج الرسائل على الرد أو يمكنه قراءة الرد بالكامل.

3. تحقَّق من سجلات خادم الخلفية لمعرفة ما إذا كانت هناك أي أخطاء أو معلومات قد خادم الخلفية لإنهاء الاتصال فجأة. إذا عثرت على أي الأخطاء/المعلومات، ثم انتقل إلى الحل وإصلاح المشكلة بشكل مناسب في خادم الخلفية.
4. إذا لم تعثر على أي أخطاء أو معلومات في خادم الخلفية، اجمع مخرجات tcpdump في "معالجات الرسائل":
   1. إذا كان مضيف خادم الخلفية لديه عنوان IP واحد، استخدِم الأمر التالي:

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

   2. إذا كان مضيف خادم الخلفية له عناوين IP متعددة، استخدِم الأمر التالي:

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

      يحدث هذا الخطأ عادةً لأن خادم الخلفية يستجيب مرة أخرى باستخدام [FIN,ACK] بعد أن يرسل معالج الرسائل الطلب إلى خادم الخلفية.

5. اطّلِع على مثال tcpdump التالي.

   تم الحصول على نموذج tcpdump عند 502 Bad Gateway Error (UnexpectedEOFAtTarget) حدثت

   

6. من ناتج TCPDump، ستلاحظ التسلسل التالي للأحداث:
   1. في الحزمة 985، يرسل "معالج الرسائل" طلب واجهة برمجة التطبيقات إلى خادم الخلفية.
   2. في الحزمة 986، يستجيب خادم الخلفية فورًا باستخدام [FIN,ACK].
   3. في الحزمة 987، يستجيب معالج الرسائل باستخدام الرمز [FIN,ACK] إلى الخلفية الخادم.
   4. وفي النهاية، يتم إغلاق الاتصالات من خلال [ACK] و[RST] من كلا الجانبين.
   5. بما أنّ خادم الخلفية يرسل [FIN,ACK]، ستحصل على استثناء. استثناء واحد (java.io.EOFException: eof unexpected) في الرسالة المعالج.
7. وقد يحدث هذا في حال وجود مشكلة في الشبكة على خادم الخلفية. التفاعل مع شبكتك الفريق للتحقيق في هذه المشكلة بشكل أكبر.

الدقة

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

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

السبب: تم ضبط الإعداد بشكل غير صحيح لإبقاء مهلة عدم النشاط

قبل تشخيص ما إذا كان هذا هو سبب أخطاء 502، يُرجى القراءة المفاهيم التالية.

الروابط الدائمة في Apigee

تستخدم Apigee بشكل تلقائي (وفي المتابعة باستخدام معيار HTTP/1.1) اتصالات دائمة. عند الاتصال بخادم الخلفية الهدف. يمكن أن تؤدي عمليات الربط المستمرة إلى تحسين الأداء عن طريق السماح بإعادة استخدام بروتوكول TCP الذي تم إنشاؤه بالفعل و (إن أمكن) اتصال TLS/SSL، والتي وتقليل النفقات العامة لوقت الاستجابة. يتم التحكم في المدة التي يجب أن يستمر الاتصال خلالها من خلال موقع الحفاظ على مهلة البقاء (keepalive.timeout.millis).

يستخدم كل من خادم الخلفية وApigee Message Processor (معالج الرسائل في Apigee) المهلات النهائية التي يمكن الاحتفاظ بها. الاتصالات المفتوحة مع بعضها البعض. عندما لا يتم استلام أي بيانات خلال مهلة البقاء على قيد الحياة يمكن لخادم الخلفية أو معالج الرسائل إغلاق الاتصال مع الآخر.

يتم بشكل تلقائي ضبط مهلة بقاء البرامج الوكيلة لواجهة برمجة التطبيقات التي تم نشرها في معالج الرسائل في Apigee على 60s ما لم يتم تجاوزها. عند عدم تلقّي أي بيانات بشأن 60s، ستنفّذ Apigee الاتصال بخادم الخلفية. سيحافظ خادم الخلفية أيضًا على مهلة البقاء على قيد الحياة، وبعد انتهاء الصلاحية هذا، سيُغلق خادم الخلفية الاتصال بمعالج الرسائل.

تأثير عملية ضبط غير صحيحة لمهلة الاحتفاظ بالحدث

في حال ضبط إما Apigee أو خادم الخلفية على فترات زمنية غير صحيحة للاحتفاظ بسرية، ينتج عن ذلك شرط سباق يتسبب في إرسال خادم الخلفية لطلب End Of File (FIN) غير متوقع ردًا على طلب الحصول على مورد.

على سبيل المثال، إذا تمت تهيئة مهلة إبقاء البقاء حيًا داخل خادم وكيل واجهة برمجة التطبيقات أو الرسالة معالج ذو قيمة أكبر من أو تساوي المهلة المحددة لخادم الخلفية الرئيسي، ثم يمكن أن يحدث شرط السباق التالي. بمعنى أنه إذا لم يتلقَ معالج الرسائل أي من البيانات حتى تقترب من حد خادم الخلفية للغاية، ومن ثم يطلب ويتم إرساله إلى خادم الخلفية باستخدام الاتصال الحالي. وهذا يمكن أن يؤدي إلى 502 Bad Gateway بسبب خطأ غير متوقع في EOF كما هو موضح أدناه:

1. لنفترض أن مهلة الاحتفاظ بالبيانات تم تعيينها على كل من معالج الرسائل وخادم الخلفية. 60 ثانية وما من محتوى جديد الطلب إلا بعد مرور 59 ثانية من تقديم الطلب السابق بواسطة معالج الرسائل.
2. سيتابع معالج الرسائل الطلب الذي جاء في الثانية 59 استخدام الاتصال الحالي (حيث لم تنتهِ مهلة البقاء على قيد الحياة بعد) وإرسال إلى خادم الخلفية.
3. ومع ذلك، قبل وصول الطلب إلى خادم الخلفية، تنتهي مهلة البقاء حي تم تجاوزه على خادم الخلفية.
4. طلب معالج الرسائل للحصول على مورد قيد التنفيذ، ولكن خادم الخلفية محاولة إغلاق الاتصال عن طريق إرسال حزمة FIN إلى الرسالة المعالج.
5. وأثناء انتظار معالج الرسائل لاستلام البيانات، فإنه يتلقى FIN غير المتوقعة، ويتم إنهاء الاتصال.
6. وينتج عن ذلك Unexpected EOF، وبالتالي تكون 502 الذي تم إرجاعه إلى العميل بواسطة معالج الرسائل.

في هذه الحالة، لاحظنا حدوث الخطأ 502 بسبب حدوث الخطأ نفسه في مهلة البقاء. تم ضبط القيمة 60 ثانية على كل من معالج الرسائل وخادم الخلفية. وبالمثل، يمكن أن تحدث هذه المشكلة أيضًا إذا تم ضبط قيمة أعلى للحفاظ على مهلة البقاء في رسالة إلى معالج البيانات مقارنة على خادم الخلفية.

التشخيص

1. إذا كنت مستخدمًا على Cloud Public:
   1. استخدام أداة المراقبة أو التعقب (API) (كما هو موضح في خطوات التشخيص الشائعة) والتحقق من اتباع ما يلي: الإعدادات:
      • رمز الخطأ: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • مصدر الخطأ: target
   2. انتقِل إلى استخدام tcpdump لمزيد من التحقيق.
2. إذا كنت مستخدمًا خاصًا على Cloud:
   1. استخدام أداة التتبُّع سجلات وصول NGINX إلى تحديد معرّف الرسالة، ورمز الخطأ ومصدر الخطأ للخطأ 502
   2. البحث عن معرِّف الرسالة في سجل معالج الرسائل
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. ستظهر لك java.io.EOFEXception: eof unexpected كما هو موضّح أدناه:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
      

   4. يشير الخطأ java.io.EOFException: eof unexpected إلى أن تلقّى معالج الرسائل EOF أثناء انتظاره لقراءة رسالة. الاستجابة من خادم الخلفية.
   5. تشير السمة useCount=7 في رسالة الخطأ أعلاه إلى أن أعاد معالج الرسائل استخدام هذا الاتصال حوالي سبع مرات وتم استخدام السمة يشير bytesWritten=159 إلى أنّ معالج الرسائل قد أرسل الطلب حمولة 159 بايت إلى خادم الخلفية. ومع ذلك، لم يتلقَّ أي بايت. عندما حدث EOF غير المتوقع.

   6. وهذا يدل على أن معالج الرسائل قد أعاد استخدام نفس الاتصال عدة مرات، وفي هذه المناسبة، أرسل الفريق بيانات، ولكن بعد ذلك بفترة وجيزة تلقّى EOF قبل تلقي أي بيانات. وهذا يعني أن هناك احتمالاً كبيرًا أن تحدث واجهة أن تكون مهلة بقاء الخادم على قيد الحياة أقصر أو تساوي المدة المحددة في الخادم الوكيل لواجهة برمجة التطبيقات.

      يمكنك إجراء مزيد من التحقيق بمساعدة tcpdump كما هو موضّح أدناه.

استخدام tcpdump

1. احصل على tcpdump على خادم الخلفية باستخدام الأمر التالي:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name
   

2. تحليل tcpdump التي تم التقاطها:

   في ما يلي نموذج لناتج tcpdump:

   

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

   1. في الحزمة 5992,، تلقّى خادم الخلفية طلب GET.
   2. في حزمة 6064، تستجيب باستخدام 200 OK.
   3. في الحزمة 6084، تلقّى خادم الخلفية طلب "GET" آخر.
   4. في حزمة 6154، تستجيب باستخدام 200 OK.
   5. في الحزمة 6228، تلقّى خادم الخلفية طلب GET ثالثًا.
   6. هذه المرة، يعرض خادم الخلفية FIN, ACK إلى معالج الرسائل. (حزمة 6285) يتم بدء إغلاق الاتصال.

   وقد تمت إعادة استخدام الاتصال ذاته مرتين بنجاح في هذا المثال، ولكن في الطلب الثالث، يبدأ خادم الخلفية إغلاق الاتصال، بينما معالج الرسائل في انتظار البيانات من خادم الخلفية. وهذا يشير إلى احتفاظ خادم الخلفية ومن المرجح أن تكون مهلة الحياة أقصر أو مساوية للقيمة المحددة في الخادم الوكيل لواجهة برمجة التطبيقات. للتحقق من صحة يمكنك مراجعة المقالة حول مقارنة فترة السماح مدى الحياة على Apigee وخادم الخلفية.

مقارنة مهلة البقاء حيًا في Apigee وخادم الخلفية

1. بشكل تلقائي، تستخدم Apigee قيمة 60 ثانية للخاصية "الحفاظ على مهلة الاستجابة".

2. ومع ذلك، من المحتمل أنّك قد تجاوزت القيمة التلقائية في الخادم الوكيل لواجهة برمجة التطبيقات. يمكنك التحقّق من ذلك من خلال الاطّلاع على تعريف TargetEndpoint المحدَّد في تعذّر الخادم الوكيل لواجهة برمجة التطبيقات الذي يعرض 502 من الأخطاء.

   نموذج ضبط نقطة النهاية المستهدفة:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>
   

   في المثال أعلاه، يتم إلغاء خاصية مهلة إبقاء البقاء حيًا بقيمة 30 ثانية (30000 مللي ثانية).

3. بعد ذلك، تحقق من خاصية "الحفاظ على مهلة التخزين" التي تم ضبطها على خادم الخلفية. لنفترض تم إعداد خادم الخلفية بقيمة 25 seconds.
4. إذا حددت أنّ قيمة خاصية "إبقاء مهلة الحياة" في Apigee أعلى من قيمة خاصية Keep alive channel على خادم الخلفية كما في الوارد أعلاه المثال، فإن ذلك هو سبب أخطاء 502.

الدقة

تأكَّد من أنّ خاصية "الحفاظ على مهلة البقاء" تكون دائمًا أقل في Apigee (في خادم وكيل واجهة برمجة التطبيقات "معالج الرسائل" مقارنةً بذلك على خادم الخلفية.

1. حدد القيمة المعينة لمهلة البقاء حيًا على خادم الخلفية.
2. اضبط قيمة مناسبة لخاصية استمرارية انتهاء المهلة في خادم وكيل واجهة برمجة التطبيقات أو معالج الرسائل، بحيث تكون خاصية استمرار انتهاء مهلة أقل من القيمة المحددة في خادم الخلفية، باستخدام الخطوات الموضحة في ضبط معالِجات الرسائل تبقى غير قابلة للتعديل في معالجات الرسائل.

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

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

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

1. يجب أن تكون مهلة بقاء الجهاز حيًا أقل من قيمة مهلة بقاء جهاز توجيه Edge.
2. يجب أن تكون مهلة بقاء جهاز توجيه Edge أقل من المهلة المحددة لمعالج الرسائل.
3. يجب أن تكون مهلة بقاء معالج الرسائل أقل من المهلة التي يظل فيها الخادم الهدف حيًا.
4. إذا كانت لديك أيّ قفزات أخرى أمام Apigee أو خلفه، يجب تطبيق القاعدة نفسها. عليك دائمًا أن تتركها على عاتق العميل المسؤول عن إغلاق صلة برأس المال.

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

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

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

• اسم المؤسسة
• اسم البيئة
• اسم الخادم الوكيل لواجهة برمجة التطبيقات
• إكمال الأمر curl لإعادة إظهار الخطأ 502
• ملف التتبُّع الذي يحتوي على الطلبات التي تتضمّن خطأ واحد (502 Bad Gateway - Unexpected EOF)
• إذا لم تظهر أخطاء 502 في الوقت الحالي، قدِّم الفترة الزمنية معلومات المنطقة الزمنية عند حدوث 502 خطأ في الماضي.

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

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