خطأ في الخادم الداخلي 500 - البث مفعّل

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

المشكلة

يتلقى تطبيق العميل رمز حالة استجابة HTTP 500 مع ستظهر رسالة خطأ داخلي في الخادم لاستدعاءات واجهة برمجة التطبيقات.

رسائل الخطأ

قد تتلقى تطبيقات العميل استجابة الخطأ كما هو موضح أدناه:

HTTP/1.1 500 Internal Server Error

وقد تكون متبوعة برسالة خطأ مثل هذه:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

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

يمكن أن يحدث خطأ الخادم الداخلي 500 نتيجة لعدد من الأسباب المختلفة. هذا الدليل الإرشادي على "خطأ الخادم الداخلي 500" الذي حدث بسبب الوصول إلى الطلب/الاستجابة الحمولة عند البث

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

السبب: الوصول إلى الحمولة باستخدام تفعيل ميزة البث

التشخيص

الإجراء رقم 1: استخدام Trace

1. تفعيل التتبُّع ، وإجراء طلب بيانات من واجهة برمجة التطبيقات لإعادة إنتاج المشكلة - خطأ في الخادم الداخلي 500.
2. اختَر أحد الطلبات التي تعذّر تنفيذها وافحص عملية التتبُّع.
3. يمكنك التنقّل خلال مراحل عملية التتبُّع المختلفة وتحديد مكان حدوث الفشل.
4. قد يكون هذا الخطأ قد حدث أثناء تحليل إحدى السياسات لحمولة الطلب/الاستجابة.
5. في ما يلي لقطة شاشة نموذجية لتتبُّع عملية JSONThreatProtection سياسة حدوث الخطأ "Expecting }" في السطر 1":

   

   دوِّن المعلومات التالية من نتائج التتبُّع، كما هو موضَّح أعلاه لقطة شاشة:
   

   سياسة عدم اجتياز المراجعة: JSONThreatProtection

   التدفق: طلب الخادم الوكيل

6. تحقَّق من تعريف السياسة الذي تعذّر تطبيقه وراجِع الحمولة التي يتم تحليلها.

   في نموذج السيناريو، عليك فحص سياسة JSONThreatProtection المسماة JSON-Threat-Protection الذي أخفق وتحقَّق من العنصر <Source>.

   <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
      <DisplayName>JSON Threat Protection</DisplayName>
      <ArrayElementCount>20</ArrayElementCount>
      <ContainerDepth>10</ContainerDepth>
      <ObjectEntryCount>15</ObjectEntryCount>
      <ObjectEntryNameLength>50</ObjectEntryNameLength>
      <Source>request</Source>
      <StringValueLength>1000</StringValueLength>
   </JSONThreatProtection>
   

   لاحِظ أنّ العنصر <Source> يشير إلى request.يعني ذلك حدث الخطأ أثناء تحليل حمولة الطلب.

7. حدِّد نوع الحمولة التي يتم تحليلها من خلال التحقّق من طلب البيانات من واجهة برمجة التطبيقات.

يمكنك التحقّق من محتوى حمولة الطلب وعنوان Content-Type في طلب واجهة برمجة التطبيقات. في المثال التالي على الأمر curl، يتم استخدام حمولة بيانات JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

يمكنك أيضًا التحقّق من السياسة المتعذِّرة وتحديد نوع الحمولة تحليله. في مثال السيناريو أعلاه، يتعذّر تنفيذ سياسة JSON-Threat-Protection. ويشير ذلك إلى أنّ الحمولة يجب أن تكون بتنسيق JSON.

8. تحقَّق مما إذا كانت الحمولة بالتنسيق الصحيح. قد يظهر هذا الخطأ إذا كانت الحمولة غير صالحة.

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

   استنادًا إلى الحمولة التي يتم تحليلها من خلال السياسة (كما هو محدَّد في الخطوة رقم 6)، فحص محتوى الحمولة في أداة التتبع في المرحلة المناسبة.

   في السيناريو كمثال، يتم تحليل حمولة الطلب، لذا افحص مرحلة "تم استلام الطلب من العميل" في تتبُّع ومراجعة طلب المحتوى:

   

   إذا تبيّن أن محتوى الطلب فارغ كما هو موضح في لقطة الشاشة أعلاه، على الرغم من أنك أرسلت حمولة صالحة، فهذا يشير إلى أن السبب المحتمل لهذه المشكلة هو إذا كانت ميزة طلب بث المحتوى مفعّلة.

   ويرجع ذلك إلى أنّه عند تفعيل البث، لن تظهر حمولة الطلب في عملية التتبُّع.

   وبالمثل، إذا تم تحليل حمولة الاستجابة عند حدوث الخطأ، تحقَّق من محتوى الاستجابة في مرحلة "الردّ الذي تم تلقّيه من الخادم الهدف"

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

    في السيناريو النموذجي، تم تنفيذ السياسة التي تعذّر تنفيذها في مسار طلب الخادم الوكيل (كما هو محدّد في الخطوة رقم 5 أعلاه) لذلك، يُرجى فحص "نقطة نهاية الخادم الوكيل":

    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
        <Properties>
          <Property name="response.streaming.enabled">true</Property>
          <Property name="request.streaming.enabled">true</Property>
        </Properties>
      </HTTPProxyConnection>
    </ProxyEndpoint>
    

    كما هو موضّح في المثال أعلاه، تم تفعيل بث الطلب كما هو موضّح في تم ضبط الخاصية "request.streaming.enabled" على true.

    لذلك، يرجع سبب الخطأ إلى استخدام السياسة JSONThreatProtection في الخادم الوكيل لواجهة برمجة التطبيقات يمكنه الوصول إلى حمولة الطلب عند تفعيل ميزة "الوصول المباشر" يتسبب هذا في حدوث أخطاء لأنه يؤدي إلى التخزين المؤقت في خادم وكيل واجهة برمجة التطبيقات يلغي الغرض من استخدام البث في Apigee Edge.

    قد لا يظهر هذا الخطأ مع الأحمال الصغيرة، ولكن عند استخدام حمولات أكبر، يمكنك مشاهدة هذه الأخطاء.

11. يمكنك التحقّق من أنّ الخطأ 500 ناتج عن السياسة من خلال التحقّق من القيمة. من "X-Apigee-fault-source" في "AX" (بيانات "إحصاءات Google" المسجَّلة) المرحلة في التتبُّع باستخدام الخطوات التالية:
    1. انقر على المرحلة "AX" (البيانات المسجَّلة في "إحصاءات Google") كما هو موضّح في لقطة الشاشة أدناه:

       

    2. مرِّر لأسفل تفاصيل المرحلة حتى تصل إلى "عناوين الخطأ" و حدد قيم "X-Apigee-error-code"، "X-Apigee-fault-source" و "X-Apigee-error-policy" كما هو موضّح أدناه:

       

    3. إذا كانت قيمة "X-Apigee-fault-source" هي "policy" كما هو موضّح في الصورة أعلاه، فإنها تشير إلى أن الخطأ حدث بسبب سياسة الوصول إلى البيانات الأساسية عند تفعيل البث

الدقة

يُعد الوصول إلى الحمولة مع تفعيل البث بمثابة نمط مضاد كما هو موضّح في Antipattern: الوصول إلى حمولة الطلب/الاستجابة عند تفعيل البث

1. إذا كنت تريد معالجة الحمولة، يجب إيقاف البث في الخادم الوكيل/الاستهداف نقطة النهاية من خلال إزالة السمات "request.streaming.enabled" and "response.streaming.enabled" كما هو موضّح في مثال ProxyEndpoint أدناه:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>
   

   أو

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

ملاحظة:

• في هذا الدليل الإرشادي، تم استخدام سياسة JSONThreatProtection لمعالجة حمولة الطلب باستخدام تم تمكين البث في السيناريو النموذجي. أدى ذلك إلى حدوث 500 خطأ في الخادم الداخلي مع أخطاء مختلفة.
• ويمكن أن تظهر هذه الأخطاء أيضًا مع السياسات، مثل JSONToXML وXMLToJSON، وهما تعالجان حمولات البيانات للطلب أو الاستجابة عند تفعيل البث.
• ننصح بشدة بعدم استخدام أي من هذه السياسات في الخوادم الوكيلة التي تتطلب الوصول إلى حمولات البيانات عند تفعيل "الوصول المباشر"
• ويعد القيام بذلك بمثابة نمط مضاد، كما هو موثق في Antipattern: الوصول إلى حمولة الطلب/الاستجابة عند تفعيل البث

تشخيص المشاكل باستخدام مراقبة واجهة برمجة التطبيقات

إذا كنت من مستخدمي سحابة خاصة، يمكنك تخطي هذا الإجراء.

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

الاطّلاع على سيناريو نموذجي يوضّح كيفية تحديد مشاكل 5xx وحلّها في واجهات برمجة التطبيقات باستخدام "مراقبة واجهة برمجة التطبيقات" على سبيل المثال، قد تحتاج إلى إعداد تنبيه ليتم إعلامك عندما يتجاوز عدد 500 خطأ حدًّا معينًا.

إذا كنت تريد أن يتم إعلامك عند طرح استجابة 500 خطأ من السياسة، ستحتاج إلى إعداد التنبيه لرمز الحالة 500 باستخدام مصدر الخطأ باعتباره الخادم الوكيل.

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

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

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

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

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

• ظهور رسالة خطأ كاملة للطلبات التي تعذّر تنفيذها
• المؤسسة واسم البيئة واسم الخادم الوكيل لواجهة برمجة التطبيقات التي تلاحظ وجود 500 خطأ بها
• حزمة الخادم الوكيل لواجهة برمجة التطبيقات
• الحمولة المستخدمة في الطلب (إن وجدت)
• ملف التتبُّع الذي يحتوي على الطلبات التي تتضمّن "خطأ 500 داخلي في الخادم"
• سجلّات وصول NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
• سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log)
• الفترة الزمنية التي تتضمن معلومات المنطقة الزمنية التي حدثت فيها أخطاء 500.