خطأ في الخادم الداخلي 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: استخدام التتبع

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

   

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

   سياسة الإخفاق: JSONThreatProtection

   Flow: طلب الخادم الوكيل

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" التي تم ضبطها على "صحيح".

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

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

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

       

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

       

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

درجة الدقّة

الوصول إلى البيانات الأساسية مع تفعيل البث هو نمط غير نمطي كما هو موضّح في القسم 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: الوصول إلى حمولة الطلب/الاستجابة عندما يكون البث مفعلاً.

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

إذا كنت من مستخدمي Private Cloud، يُرجى تخطي هذا الإجراء.

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

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

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

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

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

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

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

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

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