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

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

المشكلة

يتلقّى تطبيق العميل رمز حالة 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.

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

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

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

ستكون سجلّات 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. تحقَّق من إعدادات نقطة نهاية الخادم الوكيل لخادم API الوكيل، واطّلِع على ما إذا كان خادم API الوكيل مضبوطًا لقبول الطلبات الخاصة المضيف الافتراضي المحدّد في الخطأ. ويتم الإشارة إلى ذلك باستخدام العنصر 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. بدلاً من ذلك، في المثال المشار إليه أعلاه، إذا كنت تنوي استخدام secure VirtualHost فقط لخادم وكيل واجهة برمجة التطبيقات المحدّد هذا، عليك إرسال طلبات البيانات من واجهة برمجة التطبيقات إلى secure VirtualHost فقط باستخدام بروتوكول HTTPS:

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

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

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

التشخيص

1. تحقَّق من إعدادات نقطة نهاية الخادم الوكيل لخادم API الوكيل لمعرفة ما إذا كان خادم API الوكيل مُعدًّا لقبول الطلبات الخاصة المضيف الافتراضي المحدّد في الخطأ. ويتم تحديد ذلك من خلال العنصر 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: لا يتطابق المسار مع basepath لخادم وكيل واجهة برمجة التطبيقات

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 محدّد (المسار بعد basepath).
   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 (المسار بعد basepath) مع /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، فأضِف مسارًا منفصلاً يتضمّن المجموعة المطلوبة من السياسات وتأكَّد من توفّر شرط يطابق /proxy.pathsuffix /Delhi كما هو موضّح أدناه:

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

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

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

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

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

التشخيص

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

   على سبيل المثال، لنفترض الإعداد التالي:

   • إذا كان عنوان URL هو http://myorg-prod.apigee.net/weather ، فإنّ 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 في &quot;معالجات الرسائل&quot; بحثًا عن أي أخطاء أثناء تحميل البيئات.
4. قد تحدث العديد من الأخطاء المختلفة التي قد تؤدي إلى تعذُّر تحميل بيئة على &quot;معالج الرسائل&quot;. تعتمد طريقة الحل على الخطأ الذي حدث.

الدقة

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

1. إذا ظهر أحد الأخطاء التالية في سجلّ &quot;معالج الرسائل&quot;، يكون السبب مشكلة في الشهادات أو المفاتيح التي تمت إضافتها إلى مخزن المفاتيح أو مخزن الثقة المحدّدَين في البيئة المحدّدة.

   الخطأ رقم 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. احصل على تفاصيل ملف تخزين المفاتيح/ملف تخزين الشهادات المحدّد في رسالة الخطأ المعروضة في الخطوة السابقة باستخدام طلب البيانات التالي من Management API:

   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. توضّح نتيجة المثال أنّ هناك شهادتَين ومفتاحًا في مستودع الثقة 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. احذف الشهادة المنتهية الصلاحية أو غير المرغوب فيها من مستودع الشهادات الموثوقة myTruststore.

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

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

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

التشخيص

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

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

2. إذا لم تظهر المراجعة المحدّدة لخادم وكيل واجهة برمجة التطبيقات كنتيجة للأمر المذكور في الخطوة 1 أعلاه، أعِد تشغيل &quot;معالج الرسائل&quot; المحدّد كما هو موضّح في الحلّ.
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. إذا كنت من مستخدمي السحابة الإلكترونية العامة، يُرجى تقديم المعلومات التالية:
   • اسم المؤسسة
   • اسم البيئة
   • اسم خادم وكيل لواجهة برمجة التطبيقات
   • أكمِل أمر 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. تفاصيل حول الأقسام التي جرّبتها في دليل التشغيل هذا وأي إحصاءات أخرى تساعدنا في تسريع حلّ هذه المشكلة