404 হোস্টের জন্য প্রক্সি শনাক্ত করা যায়নি: <virtual host name> এবং URL: <path>

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

সমস্যার উপসর্গ

API কলের উত্তর হিসেবে ক্লায়েন্ট অ্যাপ্লিকেশন 404 HTTP স্ট্যাটাস কোড সহ মেসেজ Not Found এবং সমস্যা সংক্রান্ত মেসেজ Unable to identify proxy for host: VIRTUAL_HOST and url: PATH পায়।

এই সমস্যার অর্থ হল, Edge নির্দিষ্ট করা ভার্চুয়াল হোস্ট ও পাথের জন্য API প্রক্সি খুঁজে পায়নি।

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

আপনি নিম্নলিখিত HTTP স্ট্যাটাস কোড পাবেন:

HTTP/1.1 404 Not Found

এছাড়াও, আপনি নিচে দেখানো মেসেজের মতো একটি সমস্যার মেসেজ দেখতে পাবেন:

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

উপরের সমস্যার মেসেজ থেকে বোঝা যাচ্ছে যে Edge, default ভার্চুয়াল হোস্ট ও /oauth2/token পাথের জন্য API প্রক্সি খুঁজে পায়নি।

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

এই সমস্যার সম্ভাব্য কিছু কারণ নিচে উল্লেখ করা হল:

সাধারণ ডায়াগনসিস ধাপ

404 সমস্যার সমাধান করার জন্য NGINX এবং মেসেজ প্রসেসর লগ সহায়ক হবে। লগ চেক করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. নিম্নলিখিত কমান্ড ব্যবহার করে NGINX লগ দেখুন:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. লগ এন্ট্রিতে নিম্নলিখিত ফিল্ড আছে কিনা দেখুন:

   ফিল্ড	ভ্যালু
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   লগ থেকে মেসেজ আইডি লিখে নিন।

3. Message Processor লগ চেক করুন (/opt/apigee/var/log/edge-message-processor/logs/system.log) নির্দিষ্ট API-এর জন্য আপনার কাছে messaging.adaptors.http.flow.ApplicationNotFound আছে কিনা অথবা API অনুরোধের জন্য ধাপ ২ থেকে আপনার কাছে অনন্য মেসেজ আইডি আছে কিনা তা দেখুন।

   মেসেজ প্রসেসর লগ থেকে সমস্যার মেসেজের নমুনা

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

উপরের লগ থেকে সমস্যার কোড ও মেসেজটি দেখা যাচ্ছে:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

কারণ: API প্রক্সি নির্দিষ্ট ভার্চুয়াল হোস্টের সাথে যুক্ত নয়

নির্দিষ্ট ভার্চুয়াল হোস্টের জন্য অনুরোধ গ্রহণ করার জন্য API প্রক্সি কনফিগার করা না থাকলে, আমরা সমস্যা সংক্রান্ত মেসেজ সহ 404 Not Found উত্তর পেতে পারি Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

ডায়াগনসিস

1. API প্রক্সির জন্য প্রক্সি এন্ডপয়েন্ট কনফিগারেশন চেক করুন এবং দেখুন যে API প্রক্সিটি ভুল মেসেজে উল্লেখ করা ভার্চুয়াল হোস্টের জন্য অনুরোধ গ্রহণ করার জন্য কনফিগার করা হয়েছে কিনা। এটি VirtualHost এলিমেন্ট দ্বারা বোঝানো হয়। এটি বোঝার জন্য ProxyEndpoint কনফিগারেশনের একটি নমুনা দেখা যাক।

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

   

2. ধরা যাক, নির্দিষ্ট এনভায়রনমেন্টে ভার্চুয়াল হোস্টকে এইভাবে সংজ্ঞায়িত করা হয়েছে:

   নাম	পোর্ট	হোস্টের ছদ্মনাম
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. আপনি URL ব্যবহার করে default VirtualHost-এ API অনুরোধ করেন http://myorg-prod.apigee.net/weather
4. যেহেতু ProxyEndpoint-এ default VirtualHost নেই, যেমনটি উপরের উদাহরণে দেখানো হয়েছে, তাই আপনি নিম্নলিখিত সমস্যার মেসেজ সহ 404 রেসপন্স কোড পাবেন:

   {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

5. এই সমস্যার সমাধান করতে, নিচে সমাধান বিভাগে যান।
6. ProxyEndpoint যদি default-এ অনুরোধ গ্রহণ করার জন্য কনফিগার করা থাকে VirtualHost, তাহলে পরবর্তী কারণ দেখুন - পাথ কোনও API প্রক্সির সাথে যুক্ত নেই।

রেজোলিউশন

1. সমস্যার সমাধান করতে ProxyEndpoint কনফিগারেশনে বাদ পড়ে যাওয়া VirtualHost যোগ করুন। উপরে দেখানো উদাহরণে, আপনি ProxyEndpoint কনফিগারেশনে ডিফল্ট VirtualHost যোগ করতে পারেন, যেমন:

   <VirtualHost>default</VirtualHost>

   ডিফল্ট> VirtualHost> যোগ করা হচ্ছে, এমন প্রক্সি এন্ডপয়েন্ট কনফিগারেশনের নমুনা

   

2. অথবা, উপরে উল্লেখ করা উদাহরণে, আপনি যদি এই নির্দিষ্ট API প্রক্সির জন্য শুধুমাত্র secure VirtualHost ব্যবহার করতে চান, তাহলে HTTPS প্রোটোকল ব্যবহার করে শুধুমাত্র secure VirtualHost-এ API অনুরোধ করুন:

   https://myorg-prod.apigee.net/weather

কারণ: API প্রক্সির নতুন ডিপ্লয় করা রিভিশনে ভার্চুয়াল হোস্ট সরিয়ে দেওয়া হয়েছে

নির্দিষ্ট ভার্চুয়াল হোস্ট সরিয়ে দেওয়ার পরে API প্রক্সির নতুন রিভিশন ডেপ্লয় করা হলে (যা আগে ডেপ্লয় করা রিভিশনের অংশ ছিল), সেটি যদি এখনও ক্লায়েন্টরা API অনুরোধ করার জন্য ব্যবহার করে, তাহলে এই সমস্যা হতে পারে।

ডায়াগনসিস

1. API প্রক্সি, API-এর জন্য প্রক্সি এন্ডপয়েন্ট কনফিগারেশন চেক করে দেখুন যে এটি সমস্যাতে উল্লেখ করা ভার্চুয়াল হোস্টের অনুরোধ গ্রহণ করার জন্য কনফিগার করা আছে কিনা। এটি ProxyEndpoint কনফিগারেশনে VirtualHost এলিমেন্ট দ্বারা বোঝানো হয়।
2. সমস্যাতে উল্লেখ করা ভার্চুয়াল হোস্ট যদি ProxyEndpoint কনফিগারেশনে না থাকে, তাহলে নিম্নলিখিত ধাপগুলি অনুসরণ করুন। অন্যথায়, পরবর্তী কারণ - পাথ কোনও API প্রক্সির সাথে যুক্ত নয়-এ যান।
3. আগে ডিপ্লয় করা রিভিশনের ProxyEndpoint কনফিগারেশনের সাথে বর্তমানে ডিপ্লয় করা রিভিশনের তুলনা করুন।
   1. যেমন, ধরুন আপনার আগে ডিপ্লয় করা রিভিশন ছিল 5 এবং আপনার বর্তমানে ডিপ্লয় করা রিভিশন হল 6:
      • রিভিশন ৫-এ প্রক্সি এন্ডপয়েন্টে কনফিগার করা ভার্চুয়াল হোস্ট

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>

      • রিভিশন ৬-এ প্রক্সি এন্ডপয়েন্টে কনফিগার করা ভার্চুয়াল হোস্ট

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>

   2. উপরের উদাহরণে, revision 5,-এ VirtualHost vh1 ছিল কিন্তু revision 6-এ সেটি সরিয়ে VirtualHost secure দিয়ে প্রতিস্থাপন করা হয়েছে।
   3. তাই, আপনি বা আপনার ক্লায়েন্ট যদি এই API প্রক্সিতে VirtualHost vh1 (যা revision 5-এর অংশ ছিল) ব্যবহার করে অনুরোধ করেন, তাহলে আপনি 404 রেসপন্স কোড সহ নিম্নলিখিত সমস্যার মেসেজ পাবেন:

      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

4. বর্তমানে ডিপ্লয় করা রিভিশনে ভার্চুয়াল হোস্ট পরিবর্তন ইচ্ছাকৃতভাবে করা হয়েছে নাকি অনিচ্ছাকৃতভাবে করা হয়েছে তা চেক করে দেখুন এবং সমাধান বিভাগে ব্যাখ্যা করা উপযুক্ত ব্যবস্থা নিন।

রেজোলিউশন

আপনি যদি শনাক্ত করেন যে নতুন রিভিশনে ভার্চুয়াল হোস্ট বা হোস্ট সরিয়ে দেওয়া হয়েছে, তাহলে এটি ইচ্ছাকৃতভাবে বা দুর্ঘটনাবশত হতে পারে। প্রতিটি ক্ষেত্রে, সমস্যার সমাধান করতে নিম্নলিখিত সমাধান/সুপারিশ করা ধাপগুলি অনুসরণ করুন।

পরিস্থিতি #১: ইচ্ছাকৃত পরিবর্তন

যদি ভার্চুয়াল হোস্ট সরিয়ে দেওয়ার বিষয়টি ইচ্ছাকৃত হয়, তাহলে আপনি নিম্নলিখিত বিকল্পগুলির মধ্যে একটি বেছে নিতে পারেন প্রথম বিকল্পটি হল সাজেস্ট করা পদ্ধতি:

1. আলাদা বেস পাথ সহ নতুন প্রক্সি তৈরি করুন এবং আলাদা ভার্চুয়াল হোস্ট ব্যবহার করুন (যা আগে ডিপ্লয় করা রিভিশনে নেই)।

2. আপনি যদি আগে থেকে থাকা API প্রক্সি ব্যবহার করা চালিয়ে যেতে চান কিন্তু অন্য ভার্চুয়াল হোস্ট ব্যবহার করতে চান, তাহলে আগে থেকে থাকা ভার্চুয়াল হোস্ট রেখে দিয়ে অতিরিক্ত ভার্চুয়াল হোস্ট যোগ করাই ভাল।

   এর ফলে এই API প্রক্সি ব্যবহারকারীদের উপর পরিবর্তনের কোনও প্রভাব পড়বে না।

3. আপনি যদি আগে থেকে থাকা API প্রক্সি ব্যবহার করতে চান এবং শুধুমাত্র একটি আলাদা ভার্চুয়াল হোস্ট থাকে, তাহলে আপনার ব্যবহারকারীদের আগে থেকে জানান এবং রক্ষণাবেক্ষণের সময় এই পরিবর্তন করুন।

   এর ফলে এই API প্রক্সি ব্যবহারকারীরা পরিবর্তনের ব্যাপারে সচেতন হবেন এবং তারা এই API প্রক্সিতে কল করার জন্য অন্য ভার্চুয়াল হোস্ট ব্যবহার করতে পারবেন। তাই, এই পরিবর্তন তাদের উপর কোনও প্রভাব ফেলবে না।

পরিস্থিতি #২: অনিচ্ছাকৃত পরিবর্তন

ভুলবশত ভার্চুয়াল হোস্ট সরিয়ে দেওয়া হলে এবং তা ইচ্ছাকৃত না হলে,নিম্নলিখিত কাজগুলি করুন:

1. আগে ডিপ্লয় করা রিভিশনে ব্যবহৃত একই ভার্চুয়াল হোস্ট ব্যবহার করতে বর্তমানে ডিপ্লয় করা রিভিশনে ProxyEndpoint কনফিগারেশন আপডেট করুন। উপরের উদাহরণে, নিম্নলিখিত বিভাগটি পরিবর্তন করে:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>

   এই পর্যন্ত

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>

2. রিভিশন আবার ডিপ্লয় করুন।

পেশাদার পদ্ধতি

সবসময় পরামর্শ দেওয়া হয় যে রক্ষণাবেক্ষণের সময় বা যখন ট্রাফিক সবচেয়ে কম থাকে তখন নতুন প্রক্সি বা নতুন রিভিশন প্রয়োগ করুন, যাতে প্রয়োগ করার সময় কোনও সমস্যা হলে তা এড়ানো যায় বা ট্রাফিকের উপর প্রভাব কমানো যায়।

কারণ: পাথ কোনও API প্রক্সির সাথে যুক্ত নয়

API অনুরোধ URL-এ ব্যবহৃত নির্দিষ্ট পাথের জন্য অনুরোধ গ্রহণ করার জন্য API প্রক্সি কনফিগার করা না থাকলে, আমরা 404 Not Found উত্তর পেতে পারি যার সাথে সমস্যা সংক্রান্ত মেসেজ Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. থাকে

ডায়াগনসিস

1. আপনি যে নির্দিষ্ট API প্রক্সির জন্য API অনুরোধ করতে চেয়েছিলেন সেটির ProxyEndpoint কনফিগারেশন দেখুন।
2. সমস্যার মেসেজে উল্লেখ করা নির্দিষ্ট পাথ সংক্রান্ত অনুরোধ গ্রহণ করার জন্য এপিআই প্রক্সি কনফিগার করা আছে কিনা তা চেক করুন। আপনি পরিস্থিতি #১ এবং পরিস্থিতি #২-এ উল্লেখ করা ধাপগুলি অনুসরণ করে এটি করতে পারবেন।

পরিস্থিতি #১: পাথ, API প্রক্সির বেসপাথের সাথে মিলছে না

1. সমস্যার মেসেজে উল্লেখ করা path যদি নির্দিষ্ট API প্রক্সির basepath -এর মতো না হয় অথবা এটি basepath দিয়ে শুরু না হয়, তাহলে সেটি সমস্যার কারণ হতে পারে।
2. এটি ব্যাখ্যা করার জন্য একটি উদাহরণ নেওয়া যাক:
1. প্রত্যাশিত API প্রক্সির basepath হল /weather
2. API সংক্রান্ত অনুরোধের URL হল https://myorg-prod.apigee.net/climate. এর অর্থ হল যে API অনুরোধ URL-এ ব্যবহৃত পাথ হল /climate.
3. এই উদাহরণে, path, basepath-এর মতো নয় এবং এটি basepath দিয়ে শুরু হয়নি। তাই আপনি নিম্নলিখিত সমস্যাটি দেখতে পাবেন:

   {
      "fault":{
         "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
         "detail":{
            "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
         }
      }
   }

রেজোলিউশন

1. আপনার API অনুরোধ URL-এ ব্যবহৃত path এবং নির্দিষ্ট API প্রক্সির basepath একই কিনা তা নিশ্চিত করুন।
2. উপরের উদাহরণে, API অনুরোধের URL এইরকম হতে হবে:

   {
   https://myorg-prod.apigee.net/weather

পরিস্থিতি #২: পাথ উপলভ্য শর্তসাপেক্ষ ফ্লোয়ের কোনওটির সাথে মিলছে না

1. API অনুরোধ URL-এ ব্যবহৃত path যদি basepath দিয়ে শুরু হয়, তাহলে হতে পারে যে সমস্যার মেসেজে উল্লেখ করা path suffix (basepath-এর পরে থাকা অংশ) কোনও কন্ডিশনাল ফ্লোর সাথে ম্যাচ করছে না, তাহলে এর ফলে 404 সমস্যা হতে পারে।
2. এটি ব্যাখ্যা করার জন্য একটি উদাহরণ নেওয়া যাক:
   1. প্রত্যাশিত API প্রক্সির basepath হল /weather
   2. API অনুরোধের URL হল https://myorg-prod.apigee.net/weather/Delhi. এর অর্থ হল API অনুরোধ URL-এ ব্যবহৃত পাথ হল /weather/Delhi.
3. এই উদাহরণে, path basepath /weather দিয়ে শুরু হচ্ছে। এছাড়াও, এতে /Delhi-এর path suffix আছে।
4. ProxyEndpoint-এ কোনও কনডিশনাল ফ্লো আছে কিনা তা চেক করে দেখুন।
5. কোনও কন্ডিশনাল ফ্লো না থাকলে বা অল্প কিছু নন-কন্ডিশনাল ফ্লো থাকলে, তাহলে পরবর্তী কারণ - পরিবেশে API প্রক্সি ডেপ্লয় করা হয়নি-তে যান।
6. ProxyEndpoint-এ শুধুমাত্র কনডিশনাল ফ্লো থাকলে, নিম্নলিখিত বিষয়গুলি চেক করুন:
   1. এইসব কন্ডিশনাল ফ্লোতে কন্ডিশনগুলি যদি একটি নির্দিষ্ট proxy.pathsuffix (বেসপাথের পরের পাথ) চেক করে।
   2. এছাড়াও, API অনুরোধের URL-এ উল্লেখ করা path suffix যদি কোনও শর্তের সাথে না মেলে, তাহলে সেটিই সমস্যার কারণ।
7. ধরা যাক, ProxyEndpoint-এ আমাদের দুটি ফ্লো আছে এবং দুটিই নিচে দেখানো কন্ডিশনাল ফ্লো:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>

   1. উপরে দেখানো উদাহরণে, আমাদের দুটি কন্ডিশনাল ফ্লো আছে, একটি proxy.pathsuffix (বেসপাথের পরে পাথ) থেকে /Bangalore-এর সাথে ম্যাচ করে এবং অন্যটি /Chennai-এর সাথে ম্যাচ করে। কিন্তু /Delhi এর সাথে কোনওটিই ম্যাচ করছে না, যেটি API অনুরোধের URL-এ path suffix হিসেবে পাস করা হয়েছে।
   2. 404 সমস্যার কারণ এটিই। তাই আপনি নিম্নলিখিত সমস্যা দেখতে পাবেন:

      {
         "fault":{
            "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
            "detail":{
               "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
            }
         }
      }

রেজোলিউশন

1. আপনার প্রক্সি এন্ডপয়েন্টে কন্ডিশনাল ফ্লোয়ের সাথে path suffix অন্তত একটি ম্যাচ করছে কিনা তা নিশ্চিত করুন।
2. উপরের উদাহরণে, সমস্যার সমাধান করতে আপনি নিম্নলিখিত পদ্ধতি ব্যবহার করতে পারেন:
   1. আপনি যদি /Delhi পাথের জন্য কোনও নির্দিষ্ট নীতি প্রয়োগ করতে চান, তাহলে প্রয়োজনীয় নীতি সহ একটি আলাদা ফ্লো যোগ করুন এবং নিশ্চিত করুন যে এমন একটি কন্ডিশন আছে যা নিচে দেখানো /proxy.pathsuffix /Delhi-এর সাথে ম্যাচ করে:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. আপনি যদি পাথ /Delhi-এর জন্য সাধারণ নীতি প্রয়োগ করতে চান, তাহলে সাধারণ ফ্লোতে, এমন একটি কন্ডিশন আছে কিনা তা নিশ্চিত করুন যা একটি জেনেরিক /proxy.pathsuffix-কে অনুমতি দেয়। অর্থাৎ, এটি basepath /weather-এর পরে যেকোনও পাথকে অনুমতি দেবে, যেমন নিচে দেখানো হয়েছে:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

API URL-এ উল্লেখ করা ProxyEndpoint-এ সঠিক basepath থাকলে এবং path suffix কোনও কন্ডিশনাল ফ্লোয়ের সাথে ম্যাচ করলে, পরবর্তী কারণে যান - কোনও এনভায়রনমেন্টে API প্রক্সি ডেপ্লয় করা হয়নি।

কারণ: কোনও এনভায়রনমেন্টে API প্রক্সি ডেপ্লয় করা হয়নি

ডায়াগনসিস

1. আপনার API অনুরোধের URL-এ ব্যবহৃত হোস্ট অ্যালিয়াস কোন এনভায়রনমেন্টে আছে তা নির্ধারণ করুন। Edge UI-তে আপনার সংস্থার প্রতিটি এনভায়রনমেন্টে সব ভার্চুয়াল হোস্টের বিবরণ চেক করে এটি করা যেতে পারে।

   যেমন, নিম্নলিখিত কনফিগারেশন আছে বলে ধরে নিন:

   • যদি http://myorg-prod.apigee.net/weather আপনার URL হয়, তাহলে myorg-prod.apigee.net হল হোস্টের ছদ্মনাম।
   • হোস্টের ছদ্মনাম myorg-prod.apigee.net আপনার সংস্থার prod এনভায়রনমেন্টে ভার্চুয়াল হোস্টের অংশ হিসেবে কনফিগার করা হয়েছে।
2. উপরে উল্লিখিত ১ নম্বর ধাপে নির্ধারিত নির্দিষ্ট এনভায়রনমেন্টে নির্দিষ্ট API প্রক্সি ডেপ্লয় করা হয়েছে কিনা তা চেক করুন।
3. নির্দিষ্ট এনভায়রনমেন্টে API প্রক্সি ডেপ্লয় করা না থাকলে, এটিই হল 404 সমস্যার কারণ।
   1. তাই, উপরে ধাপ ১-এ ব্যবহৃত উদাহরণে, ধরা যাক API প্রক্সি prod এনভায়রনমেন্টে ডেপ্লয় করা হয়নি, তাহলে এটিই হল সমস্যার কারণ।
   2. নিচে সমাধান বিভাগে যান।
4. নির্দিষ্ট এনভায়রনমেন্টে API প্রক্সি ডেপ্লয় করা হলে, পরবর্তী কারণে যান - মেসেজ প্রসেসরে এনভায়রনমেন্ট লোড করা নেই।

রেজোলিউশন

আপনি যে নির্দিষ্ট এনভায়রনমেন্টে API অনুরোধ করতে চান সেখানে API প্রক্সি ডেপ্লয় করুন।

কারণ: মেসেজ প্রসেসরে এনভায়র্নমেন্ট লোড করা হয়নি

ডায়াগনসিস

1. প্রতিটি মেসেজ প্রসেসরে লগ-ইন করুন এবং আপনি যে নির্দিষ্ট এনভায়রনমেন্টে API অনুরোধ করছেন সেটি নিম্নলিখিত কমান্ড ব্যবহার করে মেসেজ প্রসেসরে লোড করা হয়েছে কিনা তা চেক করুন:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. নির্দিষ্ট এনভায়রনমেন্টটি যদি উপরের কমান্ডের অংশ হিসেবে তালিকাভুক্ত থাকে, তাহলে পরবর্তী কারণে যান - এক বা একাধিক মেসেজ প্রসেসরে API প্রক্সি ডেপ্লয় করা হয়নি।
3. নির্দিষ্ট এনভায়রনমেন্ট তালিকাভুক্ত না থাকলে, এনভায়রনমেন্ট লোড করার সময় কোনও সমস্যা হয়েছে কিনা তা /opt/apigee/var/log/edge-message-processor/logs/system.log এবং /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log থেকে মেসেজ প্রসেসর চেক করুন।
4. মেসেজ প্রসেসরে এনভায়রনমেন্ট লোড না হওয়ার পিছনে বিভিন্ন কারণ থাকতে পারে। কী ধরনের সমস্যা হয়েছে তার উপর সমাধান নির্ভর করে।

রেজোলিউশন

অনেক কারণে মেসেজ প্রসেসরে এনভায়রনমেন্ট লোড নাও হতে পারে। এই বিভাগে এই সমস্যার সম্ভাব্য কয়েকটি কারণ তুলে ধরা হয়েছে এবং কীভাবে এই সমস্যার সমাধান করতে হয় তা ব্যাখ্যা করা হয়েছে।

1. আপনি যদি মেসেজ প্রসেসর লগে নিম্নলিখিত সমস্যার মধ্যে কোনও একটি দেখতে পান, তাহলে এটি একটি সার্টিফিকেট/কী সংক্রান্ত সমস্যার কারণে হয়েছে যা নির্দিষ্ট এনভায়রনমেন্টে নির্দিষ্ট কীস্টোর/ট্রাস্টস্টোরে যোগ করা হয়েছে।

   সমস্যা #১: java.security.KeyStoreException: Cannot overwrite own certificate

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
   …
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

   ... 20 common frames omitted

   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

   সমস্যা #২: java.security.KeyStoreException: Cannot overwrite secret key

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   ...
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

2. নিম্নলিখিত ম্যানেজমেন্ট API কল ব্যবহার করে আগের ধাপে দেখানো সমস্যার মেসেজে উল্লেখ করা কীস্টোর/ট্রাস্টস্টোরের বিবরণ পান:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   আউটপুটের উদাহরণ:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }

3. আউটপুটের উদাহরণ থেকে বোঝা যায় যে ট্রাস্টস্টোরে দুটি সার্টিফিকেট ও একটি কী আছে myTruststore। সাধারণত ট্রাস্টস্টোরে কোনও কী থাকে না। যদি তা করে, তাহলে একটি সার্টিফিকেট ও একটি কী থাকলে ভালো হয়।
4. নিম্নলিখিত API ব্যবহার করে দুটি সার্টিফিকেট সম্পর্কে বিবরণ পান:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. প্রতিটি সার্টিফিকেটের মেয়াদ শেষ হওয়ার তারিখ চেক করুন এবং মেয়াদ শেষ হয়ে যাওয়া/পুরনো সার্টিফিকেট নির্ধারণ করুন।
6. ট্রাস্টস্টোর myTruststore থেকে মেয়াদ শেষ হয়ে যাওয়া বা অবাঞ্ছিত সার্টিফিকেট মুছে দিন।

সমস্যাটি এখনও থেকে গেলে অথবা উপরে ১ নম্বর ধাপে উল্লেখ করা সমস্যাগুলি ছাড়া অন্য কোনও সমস্যা দেখতে পেলে, অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে বিকল্পে যান।

কারণ: এক বা একাধিক মেসেজ প্রসেসরে API প্রক্সি ডেপ্লয় করা হয়নি

এক বা একাধিক মেসেজ প্রসেসরে API প্রক্সি ডেপ্লয় করা নাও হতে পারে। এই সমস্যাটি খুব কমই ঘটে এবং বেশিরভাগ ক্ষেত্রে ম্যানেজমেন্ট সার্ভার থেকে নির্দিষ্ট API প্রক্সি ডেপ্লয় করার সময় মেসেজ প্রসেসরে ইভেন্ট বিজ্ঞপ্তি না থাকার কারণে ঘটে। এই ক্ষেত্রেও, আপনি Edge UI-তে ট্রেস সেশন তৈরি করতে পারবেন না।

ডায়াগনসিস

1. প্রতিটি মেসেজ প্রসেসরে লগ-ইন করুন এবং নিম্নলিখিত কমান্ড ব্যবহার করে API প্রক্সির নির্দিষ্ট রিভিশন ডেপ্লয় করা হয়েছে কিনা তা চেক করুন:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. ১ নম্বর ধাপে উল্লিখিত কমান্ডের আউটপুট হিসেবে API প্রক্সির নির্দিষ্ট রিভিশনটি দেখা না গেলে, সমাধান-এ ব্যাখ্যা করা নির্দিষ্ট মেসেজ প্রসেসর রিস্টার্ট করুন।
3. সব মেসেজ প্রসেসরের জন্য ১-২ ধাপগুলি আবার করুন।
4. API প্রক্সির নির্দিষ্ট রিভিশন যদি সব মেসেজ প্রসেসরে ডেপ্লয় করা থাকে, তাহলে এটি এই সমস্যার কারণ নয়। ডায়াগনস্টিক তথ্য অবশ্যই সংগ্রহ করতে হবে বিকল্পে যান।

রেজোলিউশন

নির্দিষ্ট মেসেজ প্রসেসর রিস্টার্ট করুন যেখানে API প্রক্সির নির্দিষ্ট রিভিশন ডেপ্লয় করা হয়নি।

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

API মনিটরিং ব্যবহার করে সমস্যার ডায়াগনসিস করা

API মনিটরিং আপনাকে দ্রুত সমস্যার ক্ষেত্রগুলি আলাদা করতে সাহায্য করে যাতে আপনি সমস্যা, পারফর্ম্যান্স ও লেটেন্সি সংক্রান্ত সমস্যা এবং সেগুলির সোর্স যেমন ডেভেলপার অ্যাপ, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম ডায়াগনসিস করতে পারেন।

এই সমস্যার জন্য, আপনি API মনিটরিং > তদন্ত করুন পৃষ্ঠায় নেভিগেট করতে পারেন এবং উপযুক্ত তারিখ, প্রক্সি ইত্যাদি বেছে নিতে পারেন এবং আপনি নিম্নলিখিত বিবরণ দেখতে পেতে পারেন:

• সমস্যার কোড: messaging.adaptors.http.flow.ApplicationNotFound
• স্ট্যাটাস কোড: 404
• সমস্যার সোর্স: Apigee বা MP

এছাড়াও, আপনি উপরের স্ক্রিনশটে দেখানো লগ দেখুন বিকল্পে ক্লিক করে আরও চেক করতে পারবেন।

একটি নমুনা পরিস্থিতি ধাপে ধাপে দেখুন, এটি দেখায় যে কীভাবে API মনিটরিং ব্যবহার করে আপনার API-তে 5xx সংক্রান্ত সমস্যার সমাধান করতে হয়। যেমন, আপনি 404 স্ট্যাটাস কোডের সংখ্যা কোনও নির্দিষ্ট থ্রেশহোল্ডের বেশি হয়ে গেলে বিজ্ঞপ্তি পাওয়ার জন্য অ্যালার্ট সেট-আপ করতে পারেন।

অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে

উপরে উল্লেখ করা নির্দেশাবলী অনুসরণ করার পরেও সমস্যার সমাধান না হলে, নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন। Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করে এই তথ্য শেয়ার করুন।

1. আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে, নিম্নলিখিত তথ্য দিন:
   • সংস্থার নাম
   • পরিবেশের নাম
   • API প্রক্সির নাম
   • সমস্যাটি আবার তৈরি করতে curl কমান্ড সম্পূর্ণ করুন
2. আপনি Private Cloud ব্যবহারকারী হলে, নিম্নলিখিত তথ্য দিন:
   • সম্পূর্ণ সমস্যার মেসেজ দেখা গেছে
   • পরিবেশের নাম
   • API প্রক্সি বান্ডেল
   • মেসেজ প্রসেসর লগ /opt/apigee/var/log/edge-message-processor/logs/system.log
   • প্রতিটি মেসেজ প্রসেসরের নিম্নলিখিত কমান্ডের আউটপুট।

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

3. এই প্লেবুকের কোন কোন বিভাগ আপনি চেষ্টা করেছেন এবং অন্য কোনও ইনসাইট যা এই সমস্যার সমাধান দ্রুত করতে আমাদের সাহায্য করবে, সেই সম্পর্কিত বিবরণ।