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

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

المشكلة

يتلقّى تطبيق العميل رمز حالة 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، الذي قد يحدث للأسباب التالية:

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

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

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

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

لم يتم إعداد الخادم المستهدف بشكل صحيح للسماح باتصالات TLS/SSL.

التشخيص

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

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

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

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

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

      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/SSL)، عليك تضمين السمتَين SSLInfo مع ضبط العلامة enabled على true. مع أنّه يُسمح بإضافة سمات SSLInfo لخادم مستهدَف في تعريف نقطة النهاية المستهدَفة نفسها، ننصحك بإضافة سمات SSLInfo كجزء من تعريف الخادم المستهدَف لتجنُّب أي التباس.

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

      <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. راجِع سجلّات Message Processor (/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.

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

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

الاتصالات الدائمة في Apigee

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

يستخدم كل من خادم الخلفية و"معالج الرسائل" في Apigee مهلات البقاء على قيد الحياة لإبقاء الاتصالات مفتوحة مع بعضها البعض. عند عدم تلقّي أي بيانات خلال مدة المهلة المحدّدة لعملية إبقاء الاتصال نشطًا، يمكن لخادم الخلفية أو "معالج الرسائل" إغلاق الاتصال مع الآخر.

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

تأثير إعداد مهلة غير صحيح لإبقاء الاتصال نشطًا

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

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

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

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

التشخيص

1. إذا كنت مستخدمًا للسحابة الإلكترونية العامة:
   1. استخدِم أداة "مراقبة واجهة برمجة التطبيقات" أو أداة "التتبُّع" (كما هو موضّح في خطوات التشخيص الشائعة) وتأكَّد من توفُّر الإعدادَين التاليَين:
      • رمز الخطأ: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • مصدر الخطأ: target
   2. انتقِل إلى استخدام الأداة tcpdump لإجراء المزيد من التحقيق.
2. إذا كنت مستخدمًا في السحابة الإلكترونية الخاصة:
   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:

   <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. إذا تبيّن لك أنّ قيمة السمة keep alive timeout على Apigee أعلى من قيمة السمة keep alive timeout على خادم الخلفية كما هو موضّح في المثال أعلاه، سيكون ذلك هو سبب حدوث أخطاء 502.

الدقة

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

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

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

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

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

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

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

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

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

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

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

• رسالة الخطأ الكاملة التي تم رصدها للطلبات التي تعذّر تنفيذها
• اسم المؤسسة واسم البيئة واسم خادم وكيل واجهة برمجة التطبيقات الذي تلاحظ فيه أخطاء 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 التي تم جمعها على "معالجات الرسائل" أو خادم الخلفية أو كليهما عند حدوث الخطأ