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

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

الفيديوهات

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

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP 500 مع الرسالة "حدث خطأ في الخادم الداخلي" كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات. يمكن أن يكون سبب الخطأ 500 Internal Server حدوث خطأ أثناء تنفيذ أي سياسة ضمن 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 Internal Server Error لعدد من الأسباب المختلفة. في Edge، يمكن تصنيف الأسباب إلى فئتَين رئيسيتَين استنادًا إلى مكان حدوث الخطأ:

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

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

التشخيص

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

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

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

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

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

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

الدقة

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

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

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

المثال 1: تعذُّر تنفيذ سياسة Service Callout بسبب حدوث خطأ في خادم الخلفية

إذا تعذّر إجراء طلب إلى خادم الخلفية ضمن سياسة "استدعاء الخدمة" بسبب أي خطأ، مثل 4XX أو 5XX، سيتم التعامل معه على أنّه "500 خطأ في الخادم الداخلي".

1. في ما يلي مثال على تعذُّر تشغيل خدمة الخلفية بسبب ظهور الخطأ 404 ضمن سياسة Service Callout. يتم إرسال رسالة الخطأ التالية إلى المستخدم النهائي:

   {
   "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 بسبب حدوث خطأ في سياسة Service Callout:

   

3. في هذا المثال، تسرد السمة "error" سبب تعذُّر تنفيذ سياسة "استدعاء الخدمة" على النحو التالي: "يتم التعامل مع رمز الاستجابة 404 على أنّه خطأ". قد يحدث هذا الخطأ إذا كان المرجع الذي يتم الوصول إليه من خلال عنوان URL لخادم الخلفية في سياسة "استدعاء الخدمة" غير متاح.
4. تحقَّق من توفّر المرجع على خادم الخلفية. قد لا يكون متاحًا مؤقتًا أو نهائيًا أو قد يكون تم نقله إلى موقع جغرافي آخر.

حلّ المثال 1

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

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

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

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

   

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

   <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. لاحظ معرّف الرسالة الفريد "X-Apigee.Message-ID" لطلب واجهة برمجة التطبيقات المحدّد هذا من التتبُّع، كما يلي:
   1. اختَر مرحلة "تسجيل بيانات الإحصاءات" من الطلب.
   2. انتقِل للأسفل ودوِّن قيمة X-Apigee.Message-ID.

   

7. عرض سجلّ Message Processor (/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

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

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".
   • إذا كان خادم الخلفية لا يستجيب على المنفذ المحدّد.

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

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

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

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

المثال 3: تعذُّر تنفيذ سياسة JavaCallout

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

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

   

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

   

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

حلّ المثال 3

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

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

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

التشخيص

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

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

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

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

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

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

إذا كانت لديك جلسة "تتبُّع"، ستساعدك الخطوات التالية في تشخيص المشكلة.

1. في أداة "التتبُّع"، اختَر طلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه بسبب الخطأ 500 Internal Server.
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 - علامة التبويب "نظرة عامة" لخادم وكيل API

   

الحلّ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   مثال على إدخال يعرض خطأ في السياسة

   

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

   

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