এজ UI এ API অনুরোধগুলি ক্যাপচার করা হয়নি

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

উপসর্গ

নিম্নলিখিত চিত্রটি দেখায় যে এজ UI এ API অনুরোধগুলি ক্যাপচার করা হয় না যখন একটি ট্রেস সেশন শুরু হয়:

ত্রুটি বার্তা

এই সমস্যাটি ঘটলে এজ UI-তে কোনো ত্রুটির বার্তা প্রদর্শিত হবে না।

সম্ভাব্য কারণ

নিম্নলিখিত টেবিলটি এজ UI ট্রেসে API অনুরোধগুলি ক্যাপচার করতে ব্যর্থতার সম্ভাব্য কারণগুলি দেখায়:

কারণ: বার্তা প্রসেসর দ্বারা অনুরোধগুলি প্রক্রিয়া করা হয় না

রোগ নির্ণয়

একটি ট্রেস সেশনে একটি API অনুরোধ ক্যাপচার করতে, API অনুরোধটি এজ এর উপাদান বার্তা প্রসেসর দ্বারা প্রক্রিয়া করা আবশ্যক। একটি এপিআই অনুরোধ একটি ট্রেস লেনদেনে ক্যাপচার নাও হতে পারে এমন বিভিন্ন কারণ রয়েছে৷

উদাহরণস্বরূপ, যদি একটি API অনুরোধ Apigee এজ পর্যন্ত পৌঁছাতে ব্যর্থ হয়, এজ (অর্থাৎ, রাউটার) এন্ট্রি পয়েন্টে ব্যর্থ হয় বা এটি মেসেজ প্রসেসর দ্বারা প্রক্রিয়া করার আগে ব্যর্থ হয়, তাহলে ট্রেসটি ক্যাপচার করা যাবে না। এই পরিস্থিতিতে প্রতিটি নীচে বৃহত্তর বিস্তারিতভাবে রূপরেখা করা হয়েছে.

দৃশ্যকল্প 1: অনুরোধগুলি Apigee প্রান্তে পৌঁছাতে ব্যর্থ হয়েছে৷

• কারণ

  এই পরিস্থিতিতে, ত্রুটিটি একটি 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 অনুরোধ এজ UI-তে ট্রেস সেশনে দেখানো হবে না।

এই ক্ষেত্রে কিনা তা নির্ধারণ করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:

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