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

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

علامت

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

پیغام خطا

در صورت بروز این مشکل هیچ پیام خطایی در رابط کاربری Edge نمایش داده نمی شود.

علل احتمالی

جدول زیر دلایل احتمالی شکست درخواست‌های API در Edge UI Trace را نشان می‌دهد:

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

تشخیص

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

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

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

• علت

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

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

  curl: (6) Could not resolve host: hostName
  

• قطعنامه

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

  dig hostName

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

  telnet hostName port

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

• علت

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

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

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

• قطعنامه

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

  خطاهای دست دادن TLS/SSL

  400 درخواست بد - خطای گواهی SSL

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

• علت

  در این سناریو، پردازشگر پیام 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"
      }
    }
  }
  
  

• قطعنامه

  برای عیب‌یابی و رفع این مشکل به این کتاب راهنما مراجعه کنید: 404 قادر به شناسایی پروکسی برای میزبان نیست .

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

تشخیص

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

مراحل زیر را برای تعیین اینکه آیا این مورد است دنبال کنید:

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

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

   خروجی نمونه:

   دستور بالا لیستی از ویرایش های مستقر شده را خروجی می دهد. به عنوان مثال، اگر نسخه 12 مستقر شده باشد، خروجی زیر را خواهید دید:

   [ "12" ]
   

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

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

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

3. مراحل 1 و 2 را برای هر پردازشگر پیام تکرار کنید. اگر نام پراکسی 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 مستقر شده باشد، خروجی زیر را خواهید دید:

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