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

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

المشكلة

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

رسالة الخطأ

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

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

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

السبب: لم تتم معالجة الطلبات من خلال "معالج الرسائل"

التشخيص

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

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

السيناريو 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

• السبب

  في هذه الحالة، قد يكون سبب الخطأ هو تعذُّر تأكيد الاتصال عبر بروتوكول أمان النقل (TLS) أو طبقة المقابس الآمنة (SSL). في هذه الحالة، قد يظهر لك أحد الأخطاء التالية:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

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

• الدقة

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

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

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

السيناريو 3: يتعذّر على "معالج الرسائل" معالجة الطلبات

• السبب

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

  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. بعد أن يصبح "معالج الرسائل" جاهزًا، تحقَّق من توفّر خادم API الوكيل باستخدام الأمر التالي:

   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
   

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

Must Gather Diagnostic Information

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

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