404 تعذر تحديد الوكيل للمضيف: <اسم المضيف الافتراضي> وعنوان URL: <path>

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

المشكلة

يحصل تطبيق العميل على رمز حالة HTTP 404 مع الرسالة Not Found ورسالة الخطأ Unable to identify proxy for host: VIRTUAL_HOST and url: PATH كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات.

يعني هذا الخطأ أن Edge لم يتمكن من العثور على الخادم الوكيل لواجهة برمجة التطبيقات للمضيف والمسار الافتراضي المحدّدَين.

رسالة الخطأ

ستحصل على رمز حالة HTTP التالي:

HTTP/1.1 404 Not Found

ستلاحظ أيضًا رسالة خطأ مماثلة لتلك الظاهرة أدناه:

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

تشير رسالة الخطأ أعلاه إلى أنّ متصفّح Edge لم يتمكن من العثور على الخادم الوكيل لواجهة برمجة التطبيقات للمضيف default الافتراضي ومسار /oauth2/token.

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

في ما يلي بعض الأسباب المحتملة لهذا الخطأ:

السبب	الوصف	تعليمات تحديد المشاكل وحلّها السارية على
الخادم الوكيل لواجهة برمجة التطبيقات غير مرتبط بالمضيف الافتراضي المحدّد	لم يتم إعداد الخادم الوكيل المحدّد لواجهة برمجة التطبيقات لقبول الطلبات على المضيف الافتراضي المحدّد في رسالة الخطأ.	مستخدمو Edge العام والخاص على السحابة الإلكترونية
إزالة المضيف الافتراضي في نسخة منشورة حديثًا من الخادم الوكيل لواجهة برمجة التطبيقات	يمكن أن تؤدي إزالة المضيف الافتراضي من النسخة السابقة التي تم نشرها مؤخرًا إلى أن يكون العميل لا يزال يستخدم المضيف الظاهري المحدد أن تتسبب في حدوث هذه المشكلة.	مستخدمو Edge العام والخاص على السحابة الإلكترونية
مسار غير مرتبط بأي خادم وكيل لواجهة برمجة التطبيقات	لم يتم إعداد الخادم الوكيل المحدّد لواجهة برمجة التطبيقات لقبول الطلبات في المسار المحدّد في رسالة الخطأ.	مستخدمو Edge العام والخاص على السحابة الإلكترونية
عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة	لم يتم نشر الخادم الوكيل المحدّد لواجهة برمجة التطبيقات في البيئة المحدّدة التي تحاول إجراء طلبات البيانات من واجهة برمجة التطبيقات فيها.	مستخدمو Edge العام والخاص على السحابة الإلكترونية
لم يتم تحميل البيئة على معالج الرسائل	لم يتم تحميل البيئة المحددة (التي تحاول تقديم طلبات واجهة برمجة التطبيقات فيها) في معالجات الرسائل بسبب حدوث خطأ.	مستخدمو Edge Private Cloud
عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات على معالِج رسائل واحد أو أكثر	قد لا يتم نشر الخادم الوكيل لواجهة برمجة التطبيقات على معالِجات رسائل واحدة أو أكثر بسبب عدم توفُّر إشعارات برصد أحداث أثناء النشر.	مستخدمو Edge Private Cloud

خطوات التشخيص الشائعة

يمكنك الاستفادة من سجلات NGINX و"معالج الرسائل" في تحديد مشاكل 404 وحلّها. ويمكنك اتّباع الخطوات التالية للتحقّق من السجلّات:

1. اعرض سجلات NGINX باستخدام الأمر التالي:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. تحقَّق من الحقول التالية في إدخالات السجلّ:

   الحقل	القيمة
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   دوِّن معرّف الرسالة من السجلات.

3. راجِع سجلّات "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log) لمعرفة ما إذا كان لديك messaging.adaptors.http.flow.ApplicationNotFound لواجهة برمجة التطبيقات المحددة أو إذا كان لديك معرِّف الرسالة الفريد من الخطوة 2 لطلب البيانات من واجهة برمجة التطبيقات.

   نموذج لرسالة خطأ من سجلّ "معالج الرسائل"

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

يعرض السجلّ أعلاه رمز الخطأ وتظهر رسالة الخطأ على النحو التالي:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

السبب: الخادم الوكيل لواجهة برمجة التطبيقات غير مرتبط بالمضيف الافتراضي المحدّد

إذا لم يتم إعداد الخادم الوكيل لواجهة برمجة التطبيقات لقبول الطلبات الخاصة بالمضيف الافتراضي المحدّد، يمكننا الحصول على استجابة 404 Not Found مع رسالة الخطأ Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

التشخيص

1. تحقَّق من إعدادات نقطة نهاية الخادم الوكيل للخادم الوكيل لواجهة برمجة التطبيقات وتعرَّف على ما إذا تم ضبط الخادم الوكيل لواجهة برمجة التطبيقات لقبول طلبات المضيف الظاهري المحدّد في الخطأ. ويُشار إلى ذلك من خلال العنصر VirtualHost. لنلقِ نظرة على نموذج لإعدادات ProxyEndpoint لفهم ذلك.

   نموذج لإعداد نقطة نهاية الخادم الوكيل يوضح أنّ الخادم الوكيل لواجهة برمجة التطبيقات يقبل الطلبات على مضيف افتراضي آمن

   

2. لنفترض أن المضيفين الافتراضيين تم تعريفهم في البيئة المحددة على النحو التالي:

   الاسم	ميناء	الاسم المستعار للمضيف
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. يمكنك تقديم طلب بيانات من واجهة برمجة التطبيقات إلى default VirtualHost باستخدام عنوان URL http://myorg-prod.apigee.net/weather.
4. بما أنّ ProxyEndpoint لا تحتوي على default VirtualHost كما هو موضّح في المثال أعلاه، ستحصل على رمز الاستجابة 404 مع رسالة الخطأ التالية:

   {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

5. انتقِل إلى قسم الحلّ أدناه لمعالجة هذه المشكلة.
6. في حال ضبط ProxyEndpoint لقبول الطلبات في default VirtualHost، انتقِل إلى السبب التالي، المسار غير مرتبط بأي خادم وكيل لواجهة برمجة التطبيقات.

درجة الدقّة

1. أضِف السمة VirtualHost غير المتوفّرة إلى إعدادات ProxyEndpoint لحلّ المشكلة. في المثال المعروض أعلاه، يمكنك إضافة السمة VirtualHost التلقائية إلى إعدادات ProxyEndpoint كما يلي:

   <VirtualHost>default</VirtualHost>

   نموذج لإعداد نقطة نهاية الخادم الوكيل يعرض الإعداد التلقائي> VirtualHost> الذي تتم إضافته

   

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

   https://myorg-prod.apigee.net/weather

السبب: تمت إزالة المضيف الظاهري في نسخة منشورة حديثًا من الخادم الوكيل لواجهة برمجة التطبيقات.

قد تحدث هذه المشكلة إذا تم نشر نسخة جديدة من خادم وكيل لواجهة برمجة التطبيقات بعد إزالة مضيف افتراضي محدَّد (كان جزءًا من النسخة السابقة المنشورة)، والتي كانت لا تزال قيد الاستخدام من قِبل العملاء لإجراء طلبات البيانات من واجهة برمجة التطبيقات.

التشخيص

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

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>
      

      • الأجهزة المضيفة الافتراضية التي تم إعدادها في نقطة نهاية الخادم الوكيل في النسخة 6

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>
      

   2. في المثال أعلاه، كانت السمة VirtualHost vh1 متوفرة في revision 5, ولكن تمت إزالتها في revision 6 واستبدالها بـ VirtualHost secure.
   3. لذلك، إذا أرسلت أنت أو عملائك الطلبات إلى الخادم الوكيل لواجهة برمجة التطبيقات هذا باستخدام VirtualHost vh1 (الذي كان جزءًا من revision 5)، سيظهر لك رمز الاستجابة 404 مع رسالة الخطأ التالية:

      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
      

      .
4. تحقَّق ممّا إذا تم إجراء تغيير المضيف الافتراضي عمدًا أو عن غير قصد في النسخة السابقة المنشورة حاليًا واتّخِذ الإجراءات المناسبة كما هو موضّح في قسم الحل.

درجة الدقّة

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

السيناريو 1: التغيير المقصود

إذا كانت إزالة المضيف الظاهري متعمدة، يمكنك تحديد أحد الخيارات التالية، على أن يكون الخيار الأول هو الأسلوب المقترَح:

1. أنشئ خادمًا وكيلاً جديدًا مع مسار أساسي مختلف واستخدم مضيفًا افتراضيًا مختلفًا (غير متوفر في النسخة السابقة المنشورة).

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

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

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

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

السيناريو 2: تغيير غير مقصود

إذا تمت إزالة المضيف الظاهري عن طريق الخطأ وليس مقصودًا، عليك إجراء ما يلي:

1. عليك تعديل إعدادات ProxyEndpoint في النسخة السابقة المنشورة حاليًا لاستخدام المضيفين الافتراضيين نفسهم التي تم استخدامها في النسخة المنشورة سابقًا. في المثال أعلاه، غيِّر القسم التالي من:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>
   

   إلى

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>
   

2. أعِد نشر النسخة السابقة.

أفضل الممارسات

ننصح دائمًا بنشر خوادم وكيلة جديدة أو إجراء مراجعات جديدة أثناء فترة الصيانة أو عندما يكون عدد الزيارات غير متوقّع بشكل أقل كي يمكن تجنُّب أي مشكلة تنشأ أثناء النشر أو تقليل تأثيرها على عدد الزيارات إلى أدنى حد ممكن.

السبب: المسار غير مرتبط بأي خادم وكيل لواجهة برمجة التطبيقات.

إذا لم يتم إعداد الخادم الوكيل لواجهة برمجة التطبيقات لقبول الطلبات الخاصة بالمسار المحدّد المستخدَم في عنوان URL لطلب واجهة برمجة التطبيقات، يمكننا الحصول على استجابة 404 Not Found مع رسالة الخطأ Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

التشخيص

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

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

1. إذا كانت علامة path المُشار إليها في رسالة الخطأ مختلفة عن basepath للخادم الوكيل المحدّد لواجهة برمجة التطبيقات أو لم تبدأ بـ basepath، قد يكون ذلك هو سبب الخطأ.
2. لنأخذ مثالاً لشرح ذلك:
1. basepath للخادم الوكيل المقصود لواجهة برمجة التطبيقات هو /weather.
2. عنوان URL لطلب واجهة برمجة التطبيقات هو https://myorg-prod.apigee.net/climate. وهذا يعني أنّ المسار المستخدَم في عنوان URL لطلب واجهة برمجة التطبيقات هو /climate.
3. في هذا المثال، تختلف السمة path عن السمة basepath ولا تبدأ بالسمة basepath. ولهذا السبب، يظهر لك الخطأ التالي:

   {
      "fault":{
         "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
         "detail":{
            "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
         }
      }
   }

درجة الدقّة

1. تأكَّد من أنّ path المستخدَم في عنوان URL لطلب واجهة برمجة التطبيقات هو نفسه basepath للخادم الوكيل المحدّد لواجهة برمجة التطبيقات.
2. في المثال أعلاه، يجب أن يكون عنوان URL لطلب واجهة برمجة التطبيقات على النحو التالي:

   {
   https://myorg-prod.apigee.net/weather
   

السيناريو 2: المسار لا يتطابق مع أي من التدفقات الشرطية المتاحة

1. إذا كانت السمة path المستخدَمة في عنوان URL لطلب واجهة برمجة التطبيقات تبدأ بـ basepath، من المحتمل أنّ path suffix (الجزء الذي يأتي بعد basepath) المُشار إليه في رسالة الخطأ لا يتطابق مع أي من التدفقات الشرطية، ما قد يؤدي إلى حدوث خطأ 404.
2. لنلقِ نظرة على مثال لشرح ذلك:
   1. basepath للخادم الوكيل المقصود لواجهة برمجة التطبيقات هو /weather.
   2. عنوان URL لطلب واجهة برمجة التطبيقات هو https://myorg-prod.apigee.net/weather/Delhi. يعني ذلك أنّ المسار المستخدَم في عنوان URL الخاص بطلب البيانات من واجهة برمجة التطبيقات هو /weather/Delhi..
3. في هذا المثال، تبدأ السمة path بـ basepath /weather. بالإضافة إلى ذلك، يتضمّن المنتج path suffix بقيمة /Delhi.
4. تحقَّق الآن لمعرفة ما إذا كانت هناك أي تدفقات شرطية في ProxyEndpoint.
5. في حال عدم وجود تدفقات مشروطة أو بعض التدفقات غير المشروطة، انتقِل إلى السبب التالي، وهو عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة.
6. إذا كانت السمة ProxyEndpoint تحتوي على تدفقات شرطية فقط، تحقَّق مما يلي:
   1. إذا كانت الشروط في جميع هذه التدفقات الشرطية تبحث عن proxy.pathsuffix محدّد (المسار بعد المسار الأساسي).
   2. وإذا كان path suffix المحدّد في عنوان URL لطلب واجهة برمجة التطبيقات لا يتطابق مع أي من الشروط، يكون هذا هو سبب الخطأ.
7. لنفترض أنّ لدينا مسارَين في ProxyEndpoint وكلاهما تدفقان شرطيان كما هو موضّح أدناه:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
   

   1. في المثال أعلاه، هناك مساران شرطيان، أحدهما يتطابق مع proxy.pathsuffix (المسار بعد المسار الأساسي) إلى /Bangalore والآخر يتطابق مع /Chennai. ولكن لا تتطابق أي منها مع /Delhi، وهي path suffix التي تم تمريرها في عنوان URL لطلب واجهة برمجة التطبيقات.
   2. وهذا هو سبب خطأ 404. وبالتالي، ستظهر لك رسالة الخطأ التالية:

      {
         "fault":{
            "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
            "detail":{
               "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
            }
         }
      }

درجة الدقّة

1. تأكَّد من مطابقة path suffix لتدفق واحد على الأقل من التدفقات الشرطية في نقطة نهاية الخادم الوكيل.
2. في المثال أعلاه، يمكنك استخدام الأساليب التالية لإصلاح الخطأ:
   1. إذا أردت تنفيذ أي مجموعة محدّدة من السياسات للمسار /Delhi، أضِف مسارًا منفصلاً يتضمّن المجموعة المطلوبة من السياسات وتأكَّد من توفّر شرط يتطابق مع /Delhi /proxy.pathsuffix كما هو موضّح أدناه:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. إذا أردت تنفيذ مجموعة مشتركة من السياسات للمسار /Delhi، تأكَّد من في المسار المشترك أنّ هناك شرط يسمح باستخدام /proxy.pathsuffix عام. وهذا يعني أنّه سيسمح بأي مسار بعد /weather basepath كما هو موضّح أدناه:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

إذا كان العنصر ProxyEndpoint يحتوي على basepath الصحيح، وكان path suffix المحدّد في عنوان URL لواجهة برمجة التطبيقات يتطابق مع أحد التدفقات الشرطية، يتم الانتقال إلى السبب التالي، وهو عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة.

السبب: عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة

التشخيص

1. حدِّد البيئة التي يوجد بها الاسم المستعار للمضيف المُستخدَم في عنوان URL لطلب واجهة برمجة التطبيقات. ويمكن إجراء ذلك من خلال التحقّق من تفاصيل جميع المضيفين الافتراضيين في كل بيئات مؤسستك في واجهة مستخدم Edge.

   لنفترض مثلاً الإعدادات التالية:

   • إذا كان http://myorg-prod.apigee.net/weather هو عنوان URL الخاص بك، يكون myorg-prod.apigee.net هو الاسم المستعار للمضيف.
   • تم إعداد الاسم المستعار للمضيف myorg-prod.apigee.net كجزء من أحد المضيفين الافتراضيين في بيئة prod في مؤسستك.
2. تحقَّق مما إذا كان الخادم الوكيل المحدَّد لواجهة برمجة التطبيقات منشورًا في البيئة المحدّدة التي تم تحديدها في الخطوة 1 أعلاه.
3. إذا لم يتم نشر الخادم الوكيل لواجهة برمجة التطبيقات في البيئة المحدّدة، قد يكون هذا هو سبب خطأ 404.
   1. في المثال المستخدَم في الخطوة 1 أعلاه، لنفترض أنّه لم يتم نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة prod، وهذا هو سبب الخطأ.
   2. انتقِل إلى قسم الحلّ أدناه.
4. في حال نشر الخادم الوكيل لواجهة برمجة التطبيقات في البيئة المحدّدة، انتقِل إلى السبب التالي، وهو عدم تحميل البيئة على معالِجات الرسائل.

درجة الدقّة

انشر الخادم الوكيل لواجهة برمجة التطبيقات في البيئة المحدّدة التي تنوي فيها إرسال طلبات البيانات من واجهة برمجة التطبيقات.

السبب: عدم تحميل البيئة على معالِجات الرسائل

التشخيص

1. سجِّل الدخول إلى كل معالِجات رسائل وتحقَّق مما إذا كانت البيئة المحدّدة التي يتم تقديم طلب البيانات من خلالها من خلال واجهة برمجة التطبيقات قد تم تحميلها على "معالج الرسائل" باستخدام الأمر التالي:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

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

درجة الدقّة

قد لا يتم تحميل البيئة على "معالج الرسائل" لعدة أسباب. يوضِّح هذا القسم بعض الأسباب المحتملة التي يمكن أن تؤدي إلى هذه المشكلة، كما يفسّر كيفية حلّها.

1. إذا ظهر لك أحد الأخطاء التالية في سجلّ "معالج الرسائل"، يرجع ذلك إلى مشكلة تم رصدها في الشهادات أو المفاتيح التي تمت إضافتها إلى ملف تخزين المفاتيح/ملف تخزين المفاتيح المحدّد في البيئة المحدّدة.

   الخطأ رقم 1: java.security.KeyStoreException: لا يمكن استبدال شهادته

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
   …
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   

   ... 20 common frames omitted

   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
   

   الخطأ رقم 2: java.security.KeyStoreException: لا يمكن استبدال المفتاح السري

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   ...
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

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

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   مثال على الناتج:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }
   

3. يوضِّح مثال الناتج أنّ هناك شهادتَين ومفتاحًا في Truststore myTruststore. لا يحتوي Truststore بشكل عام على أي مفتاح. وفي هذه الحالة، من الأفضل استخدام شهادة واحدة ومفتاح واحد.
4. يمكنك الحصول على تفاصيل حول الشهادتَين باستخدام واجهة برمجة التطبيقات التالية:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. تحقق من تاريخ انتهاء صلاحية كل شهادة من الشهادات وحدد الشهادة منتهية الصلاحية/الأقدم.
6. احذف الشهادة منتهية الصلاحية أو غير المرغوب فيها من Truststore myTruststore.

إذا استمرت المشكلة أو إذا ظهر لك أي خطأ غير الأخطاء المذكورة في الخطوة 1 أعلاه، انتقِل إلى ضرورة جمع معلومات التشخيص.

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

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

التشخيص

1. يُرجى تسجيل الدخول إلى كل معالج من معالجات الرسائل والتحقّق مما إذا كان قد تم نشر النسخة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات أم لا باستخدام الأمر التالي:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. إذا لم تظهر النسخة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات كنتيجة للأمر المذكور في الخطوة 1 أعلاه، عليك إعادة تشغيل معالج الرسائل المحدّد كما هو موضّح في الحل.
3. كرِّر الخطوات من 1 إلى 2 لجميع معالجات الرسائل.
4. وإذا تم نشر النسخة السابقة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات على جميع معالِجات الرسائل، لن يكون هذا هو سبب هذه المشكلة. يُرجى الانتقال إلى جمع معلومات التشخيص.

درجة الدقّة

أعِد تشغيل معالجات الرسائل المحددة التي لم يتم نشر النسخة السابقة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات عليها.

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

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

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

لحلّ هذه المشكلة، يمكنك الانتقال إلى صفحة مراقبة واجهة برمجة التطبيقات > التحقيق واختيار التاريخ والخادم الوكيل المناسب وما إلى ذلك، وقد تظهر لك التفاصيل التالية:

• رمز الخطأ: messaging.adaptors.http.flow.ApplicationNotFound
• رمز الحالة: 404
• مصدر الخطأ: Apigee أو MP

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

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

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

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

1. إذا كنت من مستخدمي Public Cloud، يُرجى تقديم المعلومات التالية:
   • اسم المؤسسة
   • اسم البيئة
   • اسم الخادم الوكيل لواجهة برمجة التطبيقات
   • إكمال أمر curl لإعادة إظهار الخطأ
2. إذا كنت أحد مستخدمي Private Cloud، يُرجى تقديم المعلومات التالية:
   • تم رصد رسالة خطأ مكتملة.
   • اسم البيئة
   • حزمة الخادم الوكيل لواجهة برمجة التطبيقات
   • سجلات معالج الرسائل في /opt/apigee/var/log/edge-message-processor/logs/system.log
   • ناتج الأوامر التالية في كل معالج من معالِجات الرسائل.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

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