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

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

المشكلة

توضح الصورة التالية طلبات واجهة برمجة التطبيقات لم يتم تسجيلها في واجهة مستخدم Edge عند بدء جلسة تتبُّع:

رسالة الخطأ

لن يتم عرض أي رسائل خطأ في واجهة مستخدم Edge عند حدوث هذه المشكلة.

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

يعرض الجدول التالي الأسباب المحتملة لتعذُّر التقاط طلبات واجهة برمجة التطبيقات في Edge UI Trace

السبب: لم يعالج معالج الرسائل الطلبات

التشخيص

لتسجيل طلب من واجهة برمجة التطبيقات في جلسة تتبُّع، يجب أن يعالج تطبيق "معالج الرسائل" الخاص بمكوِّن Edge طلب البيانات من واجهة برمجة التطبيقات. هناك عدة أسباب قد تؤدي إلى عدم تسجيل طلب بيانات من واجهة برمجة التطبيقات في معاملة تتبُّع.

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

السيناريو 1: تعذُّر وصول الطلبات إلى Apigee Edge

• السبب

  في هذا السيناريو، قد يكون سبب الخطأ هو حل نظام أسماء النطاقات (DNS) أو مشكلة في الاتصال بالشبكة. وفي هذه الحالة، قد يظهر لك الخطأ التالي عند تشغيل هذا الأمر:

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• الدقة

  يمكنك التحقّق من إعدادات نظام أسماء النطاقات باستخدام الأمر التالي:

  dig hostName

  يمكنك التحقّق من الاتصال بالشبكة باستخدام الأمر التالي:

  telnet hostName port

السيناريو 2: تعذُّر الطلبات في جهاز توجيه Apigee Edge

• السبب

  في هذا السيناريو، قد يكون سبب الخطأ هو إخفاق تأكيد اتصال بروتوكول أمان طبقة النقل/طبقة المقابس الآمنة. وإذا كان الأمر كذلك، قد يظهر لك أحد الأخطاء التالية:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  قد يظهر لك أيضًا خطأ في شهادة طبقة المقابس الآمنة (SSL).

• الدقة

  يمكنك الاطّلاع على الأدلّة الإرشادية التالية لتحديد هذه المشاكل وحلّها:

  تعذّر تأكيد الاتصال من خلال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL)

  طلب غير صالح 400: خطأ في شهادة طبقة المقابس الآمنة (SSL)

السيناريو 3: لا يمكن لمعالجة الطلبات بواسطة معالج الرسائل

• السبب

  في هذا السيناريو، يتعذّر على معالج Apigee Message Processor العثور على الخادم الوكيل لواجهة برمجة التطبيقات المضيف الظاهري المحدد والمسار المحدد. وبالتالي، قد يظهر لك أحد الأخطاء التالية:

  HTTP/1.1 404 Not Found
  

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

• الدقة

  راجِع هذا الدليل الإرشادي لتحديد هذه المشكلة وحلّها: 404 تعذُّر تحديد الخادم الوكيل للمضيف.

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

التشخيص

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

يُرجى اتباع الخطوات التالية لتحديد ما إذا كان الأمر كذلك:

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

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

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

   سيؤدي الأمر أعلاه إلى إخراج قائمة بالمراجعات المنشورة. على سبيل المثال، إذا تم نشر المراجعة 12، فسترى الناتج التالي:

   [ "12" ]
   

   ما لم تكن تواجه أخطاء HTTP 404 متقطّعة، يمكنك على الأرجح رؤية أنّه تم نشر النسخة السابقة المحدّدة.

2. اقرأ شجرة التصنيف وتحقَّق من توفُّر اسم الخادم الوكيل لواجهة برمجة التطبيقات باستخدام الأمر التالي:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

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

الحلّ

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

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

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

2. بعد إعادة التشغيل، استخدِم الأمر أدناه للانتظار إلى أن يصبح الجهاز نشطًا:

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

3. عندما يصبح معالج الرسائل جاهزًا، تحقق من توفر الخادم الوكيل لواجهة برمجة التطبيقات باستخدام الأمر التالي:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

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

   سيؤدي الأمر أعلاه إلى إخراج قائمة بالمراجعات المنشورة. على سبيل المثال، إذا تم نشر المراجعة 12، فسترى الناتج التالي:

   [ "12" ]
   

   ما لم تكن تواجه أخطاء HTTP 404 متقطّعة، يمكنك على الأرجح رؤية أنّه تم نشر النسخة السابقة المحدّدة.

4. يُرجى الاطّلاع على شجرة التصنيف والتأكّد من توفُّر اسم الخادم الوكيل لواجهة برمجة التطبيقات باستخدام الأمر التالي:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   في حال استمرار المشكلة، انتقِل إلى ضرورة جمع معلومات التشخيص.

يجب جمع معلومات التشخيص

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

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree