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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info

المشكلة

يتلقّى تطبيق العميل رمز حالة استجابة 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 مع ظهور الخطأ "Expecting } at line 1":

    alt_text

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

    السياسة التي تعذّر تنفيذها: 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. حدِّد نوع الحمولة التي يتم تحليلها من خلال التحقّق من طلب البيانات من واجهة برمجة التطبيقات.

    8. يمكنك التحقّق من محتوى حمولة الطلب وعنوان 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)، افحص محتوى الحمولة في أداة التتبُّع في المرحلة المناسبة.

    في سيناريو المثال، يتم تحليل حمولة الطلب، لذا افحص مرحلة "Request Received from Client" في التتبُّع وتحقَّق من Request Content.

    alt_text

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

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

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

  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" (Analytics Data Recorded) في التتبُّع باستخدام الخطوات الموضّحة أدناه:
    1. انقر على "AX" (Analytics Data Recorded) المرحلة كما هو موضّح في لقطة الشاشة أدناه:

      alt_text

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

      alt_text

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

الدقة

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

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

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

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

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

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

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

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

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

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

  • اسم المؤسسة
  • اسم البيئة
  • اسم الخادم الوكيل لواجهة برمجة التطبيقات
  • أمر 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