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)/طبقة المقابس الآمنة.	مستخدمو Edge العام والخاص على السحابة الإلكترونية
EOFException من خادم الخلفية	قد يرسل خادم الخلفية EOF بشكل مفاجئ.	مستخدمو Edge Private Cloud فقط
مهلة البقاء على قيد الحياة التي تم ضبطها بشكل غير صحيح	الاحتفاظ بالمهلات النشطة التي تم ضبطها بشكل غير صحيح على Apigee وخادم الخلفية.	مستخدمو Edge العام والخاص على السحابة الإلكترونية

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

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

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

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

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

التشخيص

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

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

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

1. إذا كانت الخدمة الخلفية تتطلب اتصالاً أحادي الاتجاه باستخدام طبقة المقابس الآمنة، سيحدث ما يلي:
   1. يجب تفعيل بروتوكول أمان طبقة النقل أو طبقة المقابس الآمنة في تعريف 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.

السبب: مهلة الحفاظ على قيد الحياة التي تم ضبطها بشكلٍ غير صحيح

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

الروابط المستمرة في Apigee

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

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

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

دلالات على الإعدادات غير الصحيحة لمهلة البقاء على قيد الحياة

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

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

1. لنفترض أن مهلة الاحتفاظ بالبيانات مُفعَّلة على كل من معالج الرسائل وخادم الخلفية تبلغ 60 ثانية ولم يصلنا أي طلب جديد إلا بعد مرور 59 ثانية من عرض الطلب السابق بواسطة معالج الرسائل المحدد.
2. يتولّى معالج الرسائل معالجة الطلب الذي وصل في الثانية والخمسين من خلال استخدام الاتصال الحالي (لأنّه لم تنتهِ مهلة الاحتفاظ بالبيانات حتى الآن) ويرسل الطلب إلى الخادم الخلفي.
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 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 أعلى من قيمة خاصية مهلة "إبقاء الحالة" على خادم الخلفية، كما في المثال الوارد أعلاه، يكون هذا هو سبب أخطاء 502.

درجة الدقّة

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

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

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

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

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

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

ضرورة جمع معلومات التشخيص

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

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

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

إذا كنت مستخدم 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 في معالجات الرسائل أو خادم الخلفية، أو كليهما عند حدوث الخطأ