404 হোস্টের জন্য প্রক্সি সনাক্ত করতে অক্ষম: <ভার্চুয়াল হোস্ট নাম> এবং url: <path>

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

উপসর্গ

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

এই ত্রুটির মানে হল যে এজ নির্দিষ্ট ভার্চুয়াল হোস্ট এবং পাথের জন্য 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"
      }
   }
}

উপরের ত্রুটি বার্তাটি নির্দেশ করে যে এজ default ভার্চুয়াল হোস্ট এবং /oauth2/token পথের জন্য API প্রক্সি খুঁজে পায়নি।

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

এই ত্রুটির জন্য সম্ভাব্য কিছু কারণ নীচে তালিকাভুক্ত করা হয়েছে:

সাধারণ রোগ নির্ণয়ের পদক্ষেপ

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

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. মেসেজ প্রসেসর লগগুলি ( /opt/apigee/var/log/edge-message-processor/logs/system.log) পরীক্ষা করে দেখুন আপনার কাছে নির্দিষ্ট API-এর জন্য messaging.adaptors.http.flow.ApplicationNotFound আছে কিনা বা আপনার কাছে আছে কিনা API অনুরোধের জন্য ধাপ 2 থেকে অনন্য বার্তা আইডি।

   বার্তা প্রসেসর লগ থেকে নমুনা ত্রুটি বার্তা

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 প্রক্সি নির্দিষ্ট ভার্চুয়াল হোস্টের জন্য অনুরোধগুলি গ্রহণ করার জন্য কনফিগার করা না থাকে, তাহলে আমরা Unable to identify proxy for host: VIRTUAL_HOST and url: PATH . ত্রুটি বার্তা সহ একটি 404 Not Found প্রতিক্রিয়া পেতে পারি।

রোগ নির্ণয়

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

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

   

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

   নাম	বন্দর	হোস্ট আলিয়াস
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. আপনি URL http://myorg-prod.apigee.net/weather ব্যবহার করে default VirtualHost একটি API অনুরোধ করেন
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>

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

   

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

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

কারণ: এপিআই প্রক্সির নতুন নিয়োজিত সংশোধনে ভার্চুয়াল হোস্ট সরানো হয়েছে

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

রোগ নির্ণয়

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

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

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

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

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

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

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

রেজোলিউশন

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

দৃশ্যকল্প #1: ইচ্ছাকৃত পরিবর্তন

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

1. একটি ভিন্ন বেস পাথ সহ একটি নতুন প্রক্সি তৈরি করুন এবং একটি ভিন্ন ভার্চুয়াল হোস্ট ব্যবহার করুন (যা পূর্বে স্থাপন করা সংশোধনে বিদ্যমান নেই)৷

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

   এটি নিশ্চিত করবে যে এই API প্রক্সির ব্যবহারকারীরা পরিবর্তনের দ্বারা প্রভাবিত হবেন না।

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

   এটি নিশ্চিত করবে যে এই API প্রক্সির ব্যবহারকারীরা পরিবর্তন সম্পর্কে সচেতন এবং তারা এই API প্রক্সিতে কল করার জন্য একটি ভিন্ন ভার্চুয়াল হোস্ট ব্যবহার করতে পারে৷ অতএব, তারা পরিবর্তন দ্বারা প্রভাবিত হবে না.

দৃশ্যকল্প #2: অনিচ্ছাকৃত পরিবর্তন

যে ক্ষেত্রে ভার্চুয়াল হোস্ট অপসারণ ভুল করে করা হয়েছে এবং ইচ্ছাকৃত নয়, তাহলে নিম্নলিখিতগুলি করুন:

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 প্রক্সি কনফিগার করা না থাকলে, আমরা Unable to identify proxy for host: VIRTUAL_HOST and url: PATH . ত্রুটি বার্তা সহ একটি 404 Not Found প্রতিক্রিয়া পেতে পারি।

রোগ নির্ণয়

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

দৃশ্য #1: পাথ 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

দৃশ্যকল্প #2: পাথ উপলভ্য শর্তসাপেক্ষ প্রবাহের সাথে মেলে না

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 অনুরোধ ইউআরএলে নির্দিষ্ট করা 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. আপনি যদি path /Delhi এর জন্য নীতির কোনো নির্দিষ্ট সেট চালাতে চান, তাহলে প্রয়োজনীয় নীতির সেটের সাথে একটি পৃথক প্রবাহ যোগ করুন এবং নিশ্চিত করুন যে একটি শর্ত আছে যা /proxy.pathsuffix /Delhi এর সাথে মেলে যা নীচে দেখানো হয়েছে:

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

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

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

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

কারণ: পরিবেশে API প্রক্সি স্থাপন করা হয়নি

রোগ নির্ণয়

1. আপনার API অনুরোধ URL-এ ব্যবহৃত হোস্ট উপনাম বিদ্যমান রয়েছে এমন পরিবেশ নির্ধারণ করুন। এজ UI-তে আপনার প্রতিষ্ঠানের প্রতিটি পরিবেশে সমস্ত ভার্চুয়াল হোস্টের বিবরণ পরীক্ষা করে এটি করা যেতে পারে।

   উদাহরণস্বরূপ, নিম্নলিখিত কনফিগারেশন অনুমান করুন:

   • যদি http://myorg-prod.apigee.net/weather আপনার ইউআরএল হয়, তাহলে myorg-prod.apigee.net হল হোস্ট উপনাম।
   • হোস্ট ওরফে myorg-prod.apigee.net আপনার প্রতিষ্ঠানের prod পরিবেশে ভার্চুয়াল হোস্টগুলির একটির অংশ হিসাবে কনফিগার করা হয়েছে৷
2. উপরের ধাপ 1 এ নির্ধারিত নির্দিষ্ট পরিবেশে নির্দিষ্ট API প্রক্সি স্থাপন করা হয়েছে কিনা তা পরীক্ষা করে দেখুন।
3. যদি API প্রক্সি নির্দিষ্ট পরিবেশে স্থাপন করা না হয়, তাহলে এটি 404 ত্রুটির কারণ।
   1. সুতরাং উপরের ধাপ 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 পরিবেশ লোড করার সময় কোনো ত্রুটির জন্য বার্তা প্রসেসরগুলিতে /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log ।
4. মেসেজ প্রসেসরে পরিবেশ লোড করতে ব্যর্থতার কারণ হতে পারে এমন অনেকগুলি বিভিন্ন ত্রুটি থাকতে পারে। রেজোলিউশন যে ত্রুটি ঘটেছে তার উপর নির্ভর করে।

রেজোলিউশন

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

1. আপনি যদি মেসেজ প্রসেসর লগে নিম্নলিখিত ত্রুটিগুলির মধ্যে একটি দেখতে পান, তবে এটি নির্দিষ্ট পরিবেশে নির্দিষ্ট কীস্টোর/ট্রাস্টস্টোরে যোগ করা শংসাপত্র/কীগুলির সাথে পাওয়া একটি সমস্যার কারণে ঘটে।

   ত্রুটি #1: java.security.KeyStoreException: নিজের সার্টিফিকেট ওভাররাইট করা যাবে না

   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

   ত্রুটি #2: java.security.KeyStoreException: গোপন কী ওভাররাইট করা যাবে না

   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 থেকে মেয়াদোত্তীর্ণ বা অবাঞ্ছিত শংসাপত্র মুছুন।

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

কারণ: API প্রক্সি এক বা একাধিক বার্তা প্রসেসরে স্থাপন করা হয়নি

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

রোগ নির্ণয়

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

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

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

রেজোলিউশন

নির্দিষ্ট বার্তা প্রসেসরগুলি পুনরায় আরম্ভ করুন যেখানে API প্রক্সির নির্দিষ্ট সংশোধন স্থাপন করা হয়নি।

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

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

API মনিটরিং আপনাকে ত্রুটি, কর্মক্ষমতা, এবং লেটেন্সি সমস্যা এবং তাদের উৎস যেমন ডেভেলপার অ্যাপস, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম নির্ণয় করতে সমস্যা এলাকাগুলিকে দ্রুত বিচ্ছিন্ন করতে সক্ষম করে।

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

• ফল্ট কোড: messaging.adaptors.http.flow.ApplicationNotFound
• স্ট্যাটাস কোড: 404
• ফল্ট উত্স: Apigee বা MP

উপরন্তু, আপনি উপরের স্ক্রিনশটে দেখানো লগগুলি দেখুন ক্লিক করতে পারেন এবং আরও পরীক্ষা করতে পারেন।

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

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

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

1. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
   • প্রতিষ্ঠানের নাম
   • পরিবেশের নাম
   • API প্রক্সি নাম
   • ত্রুটিটি পুনরুত্পাদন করতে কার্ল কমান্ডটি সম্পূর্ণ করুন
2. আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন তবে নিম্নলিখিত তথ্য প্রদান করুন:
   • সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত
   • পরিবেশের নাম
   • 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. আপনি এই প্লেবুকের কোন বিভাগগুলি চেষ্টা করেছেন এবং অন্য কোন অন্তর্দৃষ্টি যা আমাদের এই সমস্যার দ্রুত সমাধান করতে সাহায্য করবে সে সম্পর্কে বিশদ বিবরণ।