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 Public و Private Cloud
تمت إزالة المضيف الافتراضي في نسخة سابقة تم نشرها مؤخرًا من الخادم الوكيل لواجهة برمجة التطبيقات إزالة المضيف الافتراضي من النسخة السابقة المنشورة مؤخرًا أثناء عدم عمل البرنامج استخدام المضيف الظاهري المحدد إلى حدوث هذه المشكلة. مستخدمو Edge Public و Private Cloud
المسار غير مرتبط بأي خادم وكيل لواجهة برمجة التطبيقات لم يتم ضبط الخادم الوكيل لواجهة برمجة التطبيقات المحدّد لقبول الطلبات على المسار المحدّد في رسالة الخطأ. مستخدمو Edge Public و Private Cloud
لم يتم نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة. لا يتم نشر الخادم الوكيل المحدد لواجهة برمجة التطبيقات في البيئة المحددة التي تتواجد فيها محاولة تقديم طلبات واجهة برمجة التطبيقات. مستخدمو Edge Public و Private Cloud
لم يتم تحميل البيئة على معالج الرسائل إنّ البيئة المحدّدة (التي تحاول فيها إجراء طلبات البيانات من واجهة برمجة التطبيقات) لم تم تحميلها على معالجات الرسائل بسبب حدوث خطأ. مستخدمو 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 لطلب البيانات من واجهة برمجة التطبيقات.

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

  4. 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. يتم إرسال طلب من واجهة برمجة التطبيقات إلى VirtualHost في default باستخدام عنوان 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&gt; تتم إضافتها

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

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

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