درخواست‌های میانای برنامه‌سازی کاربردی در واسط کاربر Edge ضبط نشده است

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

نشانه

تصویر زیر نشان می‌دهد که وقتی جلسه ردیابی شروع می‌شود، درخواست‌های API در «واسط کاربر Edge» ضبط نمی‌شود:

پیام خطا

وقتی این مشکل رخ می‌دهد، هیچ پیام خطایی در «میانای کاربری Edge» نمایش داده نمی‌شود.

علل احتمالی

جدول زیر دلایل احتمالی عدم ضبط درخواست‌های API در «ردیابی میانای کاربری Edge» را نشان می‌دهد:

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

تشخیص

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

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

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

• علت

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

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

  curl: (6) Could not resolve host: hostName
  

• وضوح

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

  dig hostName

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

  telnet hostName port

سناریو ۲: درخواست‌ها در Apigee Edge Router ناموفق است

• علت

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

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

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

• وضوح

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

  دست‌دهی TLS/SSL ناموفق

  ‫400 درخواست نادرست - خطای گواهینامه 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"
      }
    }
  }

• وضوح

  برای عیب‌یابی و رفع این مشکل، به این دفترچه مراجعه کنید: ‫۴۰۴ نمی‌توان کارگزار میزبان را شناسایی کرد.

دلیل: «پراکسی میانای برنامه‌سازی کاربردی» در درخت طبقه‌بندی پیدا نشد

تشخیص

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

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

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

   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. به هریک از میزبان‌های «پردازشگر پیام» که کارگزار میانای برنامه‌سازی کاربردی خاص در «درخت طبقه‌بندی» را ندارد وارد شوید و از دستور زیر برای بازراه‌اندازی «پردازشگر پیام» استفاده کنید:

   /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