درخواست‌های API در رابط کاربری Edge ثبت نشده‌اند

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

علامت

تصویر زیر نشان می‌دهد که درخواست‌های API هنگام شروع جلسه ردیابی در رابط کاربری Edge ثبت نمی‌شوند:

پیام خطا

هنگام بروز این مشکل، هیچ پیام خطایی در رابط کاربری Edge نمایش داده نمی‌شود.

علل احتمالی

جدول زیر دلایل احتمالی عدم موفقیت در ضبط درخواست‌های API در Edge UI Trace را نشان می‌دهد:

علت: درخواست‌ها توسط پردازشگر پیام پردازش نمی‌شوند

تشخیص

برای ثبت یک درخواست API در یک جلسه Trace، درخواست API باید توسط پردازشگر پیام (Message Processor) کامپوننت Edge پردازش شود. دلایل مختلفی وجود دارد که چرا ممکن است یک درخواست API در یک تراکنش Trace ثبت نشود.

برای مثال، اگر یک درخواست API به Apigee Edge نرسد، در نقطه ورود به Edge (یعنی روتر) با شکست مواجه شود یا قبل از پردازش توسط پردازنده پیام با شکست مواجه شود، ردیابی قابل ثبت نیست. هر یک از این سناریوها با جزئیات بیشتر در زیر شرح داده شده است.

سناریو ۱: درخواست‌ها به Apigee Edge نمی‌رسند

• علت

  در این سناریو، خطا ممکن است ناشی از مشکل در وضوح DNS یا اتصال شبکه باشد. در این صورت، ممکن است هنگام اجرای این دستور خطای زیر را مشاهده کنید:

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

  curl: (6) Could not resolve host: hostName
  

• وضوح تصویر

  با دستور زیر می‌توانید پیکربندی DNS را بررسی کنید:

  dig hostName

  با دستور زیر می‌توانید اتصال شبکه را بررسی کنید:

  telnet hostName port

سناریو ۲: درخواست‌ها در روتر Apigee Edge با شکست مواجه می‌شوند

• علت

  در این سناریو، خطا ممکن است ناشی از خرابی TLS/SSL handshake باشد. در این صورت، ممکن است یکی از خطاهای زیر را مشاهده کنید:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  همچنین ممکن است خطای گواهی SSL را مشاهده کنید.

• وضوح تصویر

  برای رفع این مشکلات و حل آنها به کتاب‌های راهنمای زیر مراجعه کنید:

  خطاهای مربوط به TLS/SSL Handshake

  خطای ۴۰۰ درخواست نامناسب - خطای گواهی SSL

سناریو ۳: درخواست‌ها توسط پردازشگر پیام قابل پردازش نیستند

• علت

  در این سناریو، پردازشگر پیام Apigee نمی‌تواند پروکسی API را برای میزبان مجازی و مسیر مشخص شده پیدا کند. در نتیجه، ممکن است یکی از خطاهای زیر را مشاهده کنید:

  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"
      }
    }
  }

• وضوح تصویر

  برای عیب‌یابی و حل این مشکل به این راهنما مراجعه کنید: ۴۰۴ Unable to detect proxy for host .

علت: پروکسی API در درخت طبقه‌بندی یافت نشد

تشخیص

اگر یک پردازشگر پیام نتواند یک پروکسی API را در درخت طبقه‌بندی خود پیدا کند، هرگونه درخواست API به آن پروکسی خاص در جلسات ردیابی در رابط کاربری Edge نمایش داده نخواهد شد.

برای تشخیص اینکه آیا این مورد وجود دارد یا خیر، مراحل زیر را دنبال کنید:

1. به هر یک از پردازنده‌های پیام وارد شوید و با استفاده از دستور زیر بررسی کنید که آیا نسخه خاص API درخواستی در محیط مربوط به پردازنده پیام مستقر شده است یا خیر:

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

   خروجی مثال:

   دستور بالا لیستی از نسخه‌های نصب‌شده را نمایش می‌دهد. برای مثال، اگر نسخه ۱۲ نصب‌شده باشد، خروجی زیر را خواهید دید:

   [ "12" ]
   

   مگر اینکه با خطاهای متناوب HTTP 404 مواجه شوید، احتمالاً خواهید دید که نسخه خاص اعمال شده است.

2. درخت طبقه‌بندی را بخوانید و با استفاده از دستور زیر، وجود نام پروکسی API را بررسی کنید:

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

3. مراحل ۱ و ۲ را برای هر پردازنده پیام تکرار کنید. اگر نام پروکسی API داده شده در درخت طبقه‌بندی هر یک از پردازنده‌های پیام وجود ندارد، راه‌حل زیر را دنبال کنید.

وضوح تصویر

لطفاً برای حل این مشکل مراحل زیر را دنبال کنید. حتماً اقدامات احتیاطی لازم را برای جلوگیری از قطع تولید که ممکن است در اثر راه‌اندازی مجدد پردازنده‌های پیام در هنگام مواجهه با بارهای درخواست بالا رخ دهد، انجام دهید.

1. به هر یک از میزبان‌های پردازشگر پیام که پروکسی API خاص را در درخت طبقه‌بندی ندارند، وارد شوید و از دستور زیر برای راه‌اندازی مجدد پردازشگر پیام استفاده کنید:

   /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" ]
   

   مگر اینکه با خطاهای متناوب HTTP 404 مواجه شوید، احتمالاً خواهید دید که نسخه خاص اعمال شده است.

4. درخت طبقه‌بندی را بخوانید و با استفاده از دستور زیر، وجود نام پروکسی API را تأیید کنید:

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

   اگر مشکل همچنان ادامه داشت، به «اطلاعات تشخیصی مورد نیاز برای جمع‌آوری» بروید.

باید اطلاعات تشخیصی جمع‌آوری شود

اگر مشکل پس از دنبال کردن دستورالعمل‌های بالا همچنان ادامه داشت، لطفاً اطلاعات تشخیصی زیر را جمع‌آوری کرده و با پشتیبانی 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