خطأ في الخادم الداخلي 500

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

الفيديوهات

شاهد مقاطع الفيديو التالية لمعرفة المزيد عن حل 500 خطأ في الخادم الداخلي.

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

المشكلة

يحصل تطبيق العميل على رمز حالة HTTP 500 مع الرسالة "خطأ داخلي في الخادم" كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات. خادم 500 الداخلي قد يكون ناتجًا عن خطأ أثناء تنفيذ أي سياسة داخل Edge أو عن طريق الخطأ على الخادم الهدف/الخلفية.

رمز حالة HTTP 500 هو استجابة خطأ عامة. وهذا يعني أن الخادم واجه حالة غير متوقعة منعته من تلبية الطلب. يحدث هذا الخطأ عادةً التي يعرضها الخادم عندما لا يكون هناك أي رمز خطأ آخر مناسبًا.

رسائل الخطأ

قد تظهر لك رسالة الخطأ التالية:

HTTP/1.1 500 Internal Server Error

في بعض الحالات، قد تظهر رسالة خطأ أخرى تتضمّن المزيد من التفاصيل. إليك عيّنة رسالة الخطأ:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

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

ربما يحدث الخطأ 500 في الخادم الداخلي نظرًا لعدد من الأسباب المختلفة. في Edge، يمكن تصنيف الأسباب إلى فئتين رئيسيتين بناءً على مكان حدوث الخطأ:

السبب التفاصيل تتوفر خطوات مفصّلة لتحديد المشاكل وحلّها
خطأ في التنفيذ في إحدى سياسات Edge سياسة داخل الخادم الوكيل لواجهة برمجة التطبيقات لسبب ما. مستخدمو Edge Private وPublic Cloud
خطأ في خادم الخلفية قد يخفق خادم الخلفية لسبب ما. مستخدمو Edge Private وPublic Cloud

خطأ تنفيذ في سياسة Edge

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

التشخيص

خطوات التشخيص لمستخدمي السحابة الإلكترونية الخاصة والعامة

إذا كانت لديك جلسة واجهة مستخدم التتبع للخطأ، نفِّذ ما يلي:

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

خطوات التشخيص لمستخدمي السحابة الإلكترونية الخاصة فقط

إذا لم تكن لديك جلسة واجهة مستخدم التتبُّع، نفِّذ ما يلي:

  1. تحقَّق من حدوث الخطأ أثناء تنفيذ إحدى السياسات. يُرجى الاطّلاع على مقالة تحديد مصدر المشكلة لمعرفة التفاصيل.
  2. إذا كان الخطأ ناتجًا عن تنفيذ السياسة، يُرجى المتابعة. في حال حدوث الخطأ أثناء تنفيذ السياسة والتنفيذ. إذا كان سبب الخطأ هو خادم الخلفية، انتقِل إلى خطأ في خادم الخلفية.
  3. استخدم سجلات وصول NGINX كما هو موضح في تحديد مصدر المشكلة لتحديد السياسة التي أخفقت في الخادم الوكيل لواجهة برمجة التطبيقات معرّف رسالة الطلب الفريد
  4. التحقق من سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log) وابحث عن معرف رسالة الطلب الفريد بها.
  5. إذا عثرت على معرّف رسالة الطلب الفريد، تحقَّق مما إذا كان بإمكانك الحصول على مزيد من المعلومات حول سبب الإخفاق.

الدقة

إذا حددت سبب المشكلة في السياسة، فحاول تصحيح المشكلة عن طريق وإصلاح السياسة وإعادة نشر الخادم الوكيل.

توضح الأمثلة التالية كيفية تحديد سبب وحل مشاكل وأنواع المشكلات.

إذا كنت بحاجة إلى مزيد من المساعدة في تحديد مشاكل الخطأ 500 الداخلي في الخادم وحلّها أو إذا كنت تشك في إذا كانت المشكلة في Edge، يُرجى التواصل مع Apigee الدعم:

المثال 1: إخفاق سياسة وسيلة شرح الخدمة بسبب خطأ في الخلفية الخادم

إذا تعذَّر الاتصال بخادم الخلفية في إطار سياسة وسيلة شرح الخدمة مع ظهور أي خطأ كخطأ 4XX أو 5XX، فسيتم التعامل معه على أنه خطأ 500 في الخادم الداخلي.

  1. في ما يلي مثال على تعذُّر تشغيل خدمة الخلفية مع ظهور الخطأ 404 في الخدمة سياسة وسائل الشرح. يتم إرسال رسالة الخطأ التالية إلى المستخدم النهائي: 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. تعرض جلسة واجهة مستخدم التتبُّع التالية 500 رمز حالة ناتج عن خطأ في الخدمة سياسة وسائل الشرح:

  3. في هذا المثال، تشير عبارة "خطأ" سبب سياسة وسيلة شرح الخدمة الفشل لأن "ResponseCode 404 يتم التعامل معه على أنه خطأ". قد يحدث هذا الخطأ إذا لم يكن المورد الذي يتم الوصول إليه عبر عنوان URL لخادم الخلفية في سياسة وسيلة شرح الخدمة المتوفرة.
  4. تحقَّق من مدى توفّر المورد على خادم الخلفية. قد لا تكون متاحة. بشكل مؤقت/نهائي أو ربما تم نقله إلى موقع آخر.

المثال الأول على الحلّ

  1. تحقَّق من مدى توفّر المورد على خادم الخلفية. قد لا تكون متاحة. بشكل مؤقت/نهائي أو ربما تم نقله إلى موقع آخر.
  2. يجب إصلاح عنوان URL لخادم الخلفية في سياسة وسيلة شرح الخدمة للتوجيه إلى عنوان URL صالح وحالي المصدر.
  3. إذا كان المورد غير متاح بشكل مؤقت فقط، فحاول تقديم طلب واجهة برمجة التطبيقات بعد المورد الخاص بـ YouTube.

المثال 2: تعذُّر استخراج سياسة المتغيّرات

لنلقِ نظرة الآن على مثال آخر، حيث ظهر الخطأ 500 في الخادم الداخلي في سياسة "استخراج المتغيرات" والاطّلاع على كيفية تحديد المشاكل وحلّها

  1. يُظهر التتبع التالي في جلسة واجهة المستخدم 500 رمز حالة بسبب خطأ في الاستخراج سياسة المتغيّرات:

  2. حدِّد سياسة المتغيّرات التي تعذّر استخراجها، وانتقِل للأسفل وألقِ نظرة على رسالة "الخطأ "المحتوى" لمزيد من التفاصيل:

  3. يشير محتوى الخطأ إلى أن عدم توفُّر المتغيّر "serviceCallout.oamCookieValidationResponse" في سياسة استخراج المتغيرات وكما يشير اسم المتغير، يجب أن يحمل المتغير استجابة لسياسة وسيلة شرح الخدمة السابقة
  4. اختر سياسة وسيلة شرح الخدمة في التتبع، وقد تجد أن "serviceCallout.oamCookieValidationResponse" لم يتم ضبط المتغيّر. هذا النمط يشير إلى فشل الاتصال بخدمة الخلفية، مما نتج عنه استجابة فارغة المتغير.
  5. على الرغم من تعذُّر تنفيذ سياسة وسيلة شرح الخدمة، يتم تنفيذ السياسات بعد انتهاء الخدمة تستمر سياسة وسيلة الشرح لأن رسالة "continueOnError" تم ضبط العلامة في سياسة "وسيلة شرح الخدمة" على "صحيح"، كما هو موضّح أدناه:

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. دوِّن معرّف الرسالة الفريد &quot;X-Apigee.Message-ID&quot; لواجهة برمجة التطبيقات هذه تحديدًا الطلب من التتبع، على النحو التالي:
    1. حدد "بيانات الإحصاءات المسجلة" مرحلة من الطلب.
    2. انتقِل للأسفل وسجِّل قيمة X-Apigee.Message-ID.

  7. عرض سجل معالج الرسائل (/opt/apigee/var/log/edge-message-processor/system.log) وابحث عن القيمة الفريدة تدوين معرف الرسالة في الخطوة رقم 6. تمت ملاحظة رسالة الخطأ التالية لواجهة برمجة التطبيقات المحدّدة الطلب: 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

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

  8. لتحديد سبب خطأ مهلة الاتصال، تم تنفيذ telnet إلى خادم الخلفية من معالج(معالجي الرسائل). شبكة telnet ظهرت رسالة "انتهت مهلة الاتصال". كما هو موضح أدناه: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    عادةً ما تتم ملاحظة هذا الخطأ في الحالات التالية:

    • عندما لا يتم ضبط خادم الخلفية للسماح بالزيارات من Edge Message المعالِجات:
    • إذا كان خادم الخلفية لا يستجيب على المنفذ المحدّد.

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

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

المثال الثاني على الحلّ

  1. أصلِح سبب الخطأ أو التعذُّر في سياسة "استخراج المتغيّرات" بشكل مناسب.
  2. في المثال المصور أعلاه، كان الحل هو تصحيح تكوين الشبكة السماح بالزيارات من معالجات رسائل Edge إلى خادم الخلفية. تم هذا بواسطة إدراج معالجي الرسائل في القائمة المسموح بها عناوين IP على خادم الخلفية المحدد. على سبيل المثال: على نظام التشغيل Linux، يمكنك استخدام iptables للسماح بالزيارات من عناوين IP لمعالج الرسائل على خادم الخلفية

المثال 3: تعذُّر تطبيق سياسة JavaCallout

لنلقِ الآن نظرة على مثال آخر، يظهر فيه خطأ 500 في الخادم الداخلي في سياسة وسائل شرح Java ومعرفة كيفية تحديد المشاكل وحلّها وحلها.

  1. يعرض تتبُّع واجهة المستخدم التالي رمز الحالة 500 بسبب خطأ في سياسة وسيلة شرح Java:

  2. اختَر المسار المُسمّى "خطأ" متبوعًا بسياسة وسيلة شرح Java التي تعذّر تنفيذها. للحصول على تفاصيل الخطأ كما هو موضّح في الشكل أدناه:

  3. في هذا المثال، توضّح السمة "error" ضمن قسم "Properties" (الخصائص) أن سبب الفشل يرجع إلى استخدام كلمة مرور منتهية الصلاحية أثناء الاتصال بقاعدة بيانات Oracle من داخل سياسة JavaCallout. ستعمل وسيلة شرح Java بشكل مختلف تعبئة رسالة مختلفة في الخاصية error.
  4. راجِع رمز سياسة JavaCallout وتأكَّد من الإعدادات الصحيحة التي يجب استخدام البيانات المختلفة.

المثال الثالث على الحلّ

يجب إصلاح رمز وسيلة شرح Java أو ضبطه بشكلٍ مناسب لتجنُّب استثناء بيئة التشغيل. ضِمن مثال توضيحي حول إخفاق وسيلة شرح Java أعلاه، سيحتاج المرء إلى استخدام كلمة المرور الصحيحة للاتصال بقاعدة بيانات Oracle لحل المشكلة.

حدث خطأ في خادم الخلفية

قد ينشأ أيضًا خطأ خادم داخلي 500 من خادم الخلفية. هذا القسم يشرح كيفية تحديد المشكلة وحلّها إذا كان الخطأ صادرًا من خادم الخلفية.

التشخيص

خطوات التشخيص لجميع المستخدمين

يمكن أن يختلف سبب أخطاء الخلفية الأخرى اختلافًا كبيرًا. يجب تشخيص كل حالة كل على حدة.

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

إذا لم يكن لديك جلسة تتبُّع لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه:

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

إذا كانت لديك جلسة تتبُّع لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه:

إذا كانت لديك جلسة Trace، فستساعدك الخطوات التالية على تشخيص المشكلة.

  1. في أداة التتبع، حدد طلب واجهة برمجة التطبيقات الذي أخفق مع 500 خادم داخلي حدث خطأ.
  2. اختَر مرحلة "الردّ الذي تم استلامه من الخادم الهدف" من مرحلة تعذّر إكمال العملية. طلب بيانات من واجهة برمجة التطبيقات كما هو موضّح في الشكل أدناه:

  3. راجِع القسم "محتوى الردّ" للحصول على تفاصيل حول الخطأ.

  4. في هذا المثال، يُظهر محتوى الاستجابة، وهو مغلف SOAP، سلسلة الخطأ على أنه رسالة "غير مفوَّض": السبب الأكثر احتمالًا لذلك هي أن بيانات الاعتماد الصحيحة (اسم المستخدم/كلمة المرور، رمز الدخول، وما إلى ذلك) لا يتم تمريرها إلى خادم الخلفية من قبل المستخدم. يمكن حل هذه المشكلة من خلال تمرير بيانات الاعتماد الصحيحة إلى خادم الخلفية.

إذا كانت الخلفية هي خادم Node.js:

  1. إذا كانت الخلفية هي خادم خلفية Node.js، يجب التحقّق من سجلّات Node.js. لخادم وكيل واجهة برمجة التطبيقات المحدد في واجهة مستخدم Edge (يمكن لكل من المستخدمين العامين والخاصين على السحابة الإلكترونية، تحقّق من سجلّات Node.js). إذا كنت أحد مستخدمي Edge Private Cloud، يجب: مراجعة سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log) لمزيد من التفاصيل بشأن الخطأ.

    خيار سجلات NodeJS في واجهة مستخدم Edge - علامة التبويب "نظرة عامة" في الخادم الوكيل لواجهة برمجة التطبيقات

الحلّ

  1. بعد تحديد سبب الخطأ، أصلِح المشكلة في خادم الخلفية.
  2. إذا كان خادم الواجهة الخلفية Node.js:
    1. تحقَّق مما إذا كان الخطأ ناتجًا عن الرمز المخصّص وأصلِح المشكلة، إن أمكن.
    2. إذا لم يظهر الخطأ من خلال الرمز المخصّص أو إذا كنت بحاجة إلى مساعدة، يُرجى التواصل مع فريق الدعم. دعم Apigee:

إذا كنت بحاجة إلى مزيد من المساعدة في تحديد مشاكل الخطأ 500 الداخلي في الخادم وحلّها أو إذا كنت تشك في إذا كانت المشكلة في Edge، يُرجى التواصل مع Apigee الدعم:

تحديد مصدر المشكلة

استخدِم أحد الإجراءات التالية لتحديد ما إذا كان قد حدث الخطأ 500 الخاص بالخادم الداخلي. أثناء تنفيذ سياسة داخل الخادم الوكيل لواجهة برمجة التطبيقات أو من خلال خادم الخلفية.

استخدام "التتبّع" في واجهة المستخدم

ملاحظة: يمكن تنفيذ الخطوات الواردة في هذا القسم بواسطة كلٍ من "Public" (عام) مستخدمو Private Cloud.

  1. إذا كانت المشكلة لا تزال نشطة، عليك تفعيل ميزة التتبُّع في واجهة المستخدم لواجهة برمجة التطبيقات المتأثرة.
  2. بعد تسجيل عملية التتبُّع، اختَر طلب البيانات من واجهة برمجة التطبيقات الذي يعرض رمز الاستجابة 500.
  3. يمكنك الانتقال إلى جميع مراحل طلب البيانات من واجهة برمجة التطبيقات الذي تعذّر إكماله والتحقّق من المرحلة التي سيتم إرجاعها خطأ 500 في الخادم الداخلي:
    1. إذا ظهر الخطأ أثناء تنفيذ سياسة، انتقِل إلى خطأ في التنفيذ في سياسة Edge.
    2. إذا استجاب خادم الخلفية بـ 500 خادم داخلي، يمكنك المتابعة إلى خطأ في خادم الخلفية.

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

ملاحظة: يمكن لمستخدمي Public Cloud فقط تنفيذ الخطوات الواردة في هذا القسم.

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

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

استخدام الوصول إلى NGINX السجلّات

ملاحظة: الخطوات الواردة في هذا القسم مخصّصة لمستخدمي Edge Private Cloud. فقط.

يمكنك أيضًا الرجوع إلى سجلات NGINX Access لتحديد ما إذا تم طرح رمز الحالة 500 أثناء تنفيذ سياسة داخل الخادم الوكيل لواجهة برمجة التطبيقات أو من خلال خادم الخلفية. هذا هو مفيدة بشكل خاص إذا حدثت المشكلة في الماضي أو إذا كانت المشكلة متقطعة يتعذّر تسجيل آثار الأنشطة في واجهة المستخدم. استخدم الخطوات التالية لتحديد هذه المعلومات من سجلات وصول NGINX:

  1. تحقَّق من سجلات وصول NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
  2. ابحث عما إذا كان هناك 500 خطأ للخادم الوكيل المحدد لواجهة برمجة التطبيقات على المدة.
  3. إذا كان هناك أي 500 خطأ، فتحقق مما إذا كان الخطأ يتعلق بالسياسة أو خطأ في الخادم الهدف، كما هو موضح أدناه:

    إدخال نموذجي يعرض خطأً في السياسة

    إدخال نموذجي يعرض خطأ في الخادم الهدف

  4. بعد تحديد ما إذا كان خطأ في السياسة أو الخادم الهدف:
    1. انتقل إلى خطأ في التنفيذ في سياسة Edge إذا فهو خطأ في السياسة.
    2. انتقِل إلى خطأ في خادم الخلفية إذا كان هدفًا. حدث خطأ في الخادم.