503 পরিষেবা অনুপলব্ধ - NoActiveTargets - HealthCheckfailures

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

ভিডিও

503 ত্রুটি সম্পর্কে আরও তথ্যের জন্য নিম্নলিখিত ভিডিওগুলি দেখুন:

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি এপিআই প্রক্সি অনুরোধগুলির জন্য HTTP প্রতিক্রিয়া স্ট্যাটাস কোড 503 , 'Service Unavailable' বার্তা এবং 'NoActiveTargets' ত্রুটি কোড গ্রহণ করে।

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

আপনি নিম্নলিখিত ত্রুটিপূর্ণ প্রতিক্রিয়া দেখতে পাবেন:

HTTP/1.1 503 Service Unavailable
  

আপনি HTTP রেসপন্সে নিম্নলিখিত এরর মেসেজটি দেখতে পাবেন:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

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

আপনার এপিআই প্রক্সির টার্গেট এন্ডপয়েন্ট কনফিগারেশনে এক বা একাধিক টার্গেট সার্ভার ব্যবহার করলে, সাধারণত NoActiveTargets এরর কোড সহ 503 Service Unavailable HTTP রেসপন্সটি দেখা যায়।

এই প্লেবুকটি হেলথ চেক ব্যর্থতার কারণে সৃষ্ট NoActiveTargets এরর কোড সহ 503 Service Unavailable এররটি নিয়ে আলোচনা করে। এই এররের অন্যান্য কারণ সম্পর্কে জানতে অনুগ্রহ করে এই প্লেবুকটি দেখুন।

স্বাস্থ্য পরীক্ষার ব্যর্থতা

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

যখন কোনো টার্গেট সার্ভার হেলথ চেক-এ ব্যর্থ হয়, তখন Edge সেই সার্ভারের ব্যর্থতার সংখ্যা বাড়িয়ে দেয়। যদি সেই সার্ভারের হেলথ চেক ব্যর্থতার সংখ্যা পূর্বনির্ধারিত থ্রেশহোল্ডে ( <MaxFailures> ) পৌঁছে যায়, তাহলে মেসেজ প্রসেসর তার লগ ফাইলে নিচে দেখানো সতর্কীকরণ বার্তাটি লগ করে:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

সতর্কীকরণ বার্তাটি নিম্নলিখিত তথ্য প্রদান করে। এটি আপনাকে বুঝতে সাহায্য করে যে কোন টার্গেট সার্ভারটি MaxFailure সংখ্যায় পৌঁছেছে:

• টার্গেট সার্ভারের নাম
• সংগঠন এবং পরিবেশের নাম
• এপিআই প্রক্সি নাম
• টার্গেট এন্ডপয়েন্টের নাম

এরপরে, Edge সেই নির্দিষ্ট সার্ভারে আর কোনো অনুরোধ পাঠানো বন্ধ করে দেয়। LoadBalancer কনফিগারেশনে কনফিগার করা সমস্ত টার্গেট সার্ভার MaxFailure সংখ্যায় পৌঁছালে, পরবর্তী API অনুরোধগুলোর জবাবে NoActiveTargets এরর কোডসহ 503 Service Unavailable বার্তা পাঠানো হয়।

হেলথ মনিটর ব্যবহার করলে, এপিআই প্রক্সি পুনরায় স্থাপন না করেই, কোনো টার্গেট সার্ভার সুস্থ হয়ে উঠলে Apigee Edge স্বয়ংক্রিয়ভাবে সেটিকে রোটেশনে ফিরিয়ে আনতে পারে।

স্বাস্থ্য পরীক্ষা ব্যর্থ হওয়ার সম্ভাব্য কারণগুলো নিচে দেওয়া হলো:

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

ব্যর্থ অনুরোধটির মেসেজ আইডি নির্ধারণ করুন।

সাধারণ ত্রুটির বার্তা

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

NoActiveTargets এরর কোড সহ 503 Service Unavailable এররটির জন্য মেসেজ প্রসেসর লগ-এ ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) সাধারণত যে এরর মেসেজগুলো দেখা যায়, সেগুলো নিম্নরূপ:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

এই ত্রুটি বার্তাগুলো নির্দেশ করে যে, কোনো ব্যর্থতার কারণে অনুরোধটি ব্যাকএন্ড সার্ভারে পাঠানো যায়নি। ফলস্বরূপ, মেসেজ প্রসেসর ক্লায়েন্টের কাছে তার প্রতিক্রিয়া হিসাবে NoActiveTargets ত্রুটি কোড সহ 503 Service Unavailable বার্তাটি পাঠায়।

কারণ: সংযোগের সময়সীমা শেষ

রোগ নির্ণয়

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

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

   Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
   java.net.ConnectException: Connection timed out (Connection timed out)
   	at java.net.PlainSocketImpl.socketConnect(Native Method)
   	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   …<snipped>
           

   হেলথ মনিটরে কনফিগার করা MaxFailure সংখ্যক বার এই ত্রুটিটি পুনরাবৃত্ত হলে, আপনি এই ধরনের একটি সতর্কীকরণ বার্তা দেখতে পাবেন:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   সতর্কীকরণ বার্তায় দেওয়া তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে, নির্দিষ্ট এপিআই প্রক্সিতে ব্যবহৃত টার্গেট সার্ভারটির জন্য MaxFailure কাউন্ট পূর্ণ হয়েছে, যেটির জন্য আপনি NoActiveTargets এরর কোডসহ 503 রেসপন্স কোড পাচ্ছেন।

4. উপরের উদাহরণে, ‘ connection timed out ত্রুটির কারণে হেলথ চেকটি ব্যর্থ হয়েছে। প্রতিটি মেসেজ প্রসেসর থেকে telnet কমান্ড ব্যবহার করে সরাসরি নির্দিষ্ট ব্যাকএন্ড সার্ভারে সংযোগ করতে পারছেন কিনা তা পরীক্ষা করুন:

telnet <BackendServer-HostName> 443
      

5. আপনি যদি ব্যাকএন্ড সার্ভারে সংযোগ করতে পারেন, তাহলে আপনি 'Connected to backend-server'-এর মতো একটি বার্তা দেখতে পারেন। সেক্ষেত্রে সমস্যাটি একটি অস্থায়ী বিষয় হতে পারে এবং এটি হয় সমাধান হয়ে যাবে অথবা এটি একটি মাঝে মাঝে হওয়া সমস্যা। ধাপ ৪ কয়েকবার (১০ বারের বেশি) পুনরাবৃত্তি করুন এবং আউটপুট যাচাই করুন।
1. যদি telnet কমান্ডে ধারাবাহিকভাবে কোনো ত্রুটি না থাকে, তাহলে সমস্যাটির সমাধান হয়ে গেছে। হেলথ চেক ফেইলরগুলো বন্ধ হয়েছে কিনা তা আবার পরীক্ষা করুন। যদি হয়ে থাকে, তাহলে আপনাকে আর কিছু করতে হবে না।
2. যদি আপনি মাঝে মাঝে telnet কমান্ড দিয়ে ব্যাকএন্ড সার্ভারে সংযোগ করতে না পারেন, তাহলে সম্ভবত নেটওয়ার্কে কোনো সমস্যা আছে অথবা আপনার ব্যাকএন্ড সার্ভারটি ব্যস্ত রয়েছে।
6. যদি আপনি telnet কমান্ড ব্যবহার করে ধারাবাহিকভাবে ব্যাকএন্ড সার্ভারে সংযোগ করতে না পারেন, তাহলে এর কারণ হতে পারে যে নির্দিষ্ট ব্যাকএন্ড সার্ভারের মেসেজ প্রসেসরগুলো থেকে ট্র্যাফিকের অনুমতি নেই।

সমাধান

যদি বারবার ' connection timed out ত্রুটি দেখা যায়, তাহলে নিশ্চিত করুন যে ব্যাকএন্ড সার্ভারে কোনো ফায়ারওয়াল বিধিনিষেধ নেই এবং এটি Apigee Edge Message Processors থেকে আসা ট্র্যাফিকের অনুমতি দেয়। উদাহরণস্বরূপ, Linux-এ, আপনি ব্যাকএন্ড সার্ভারে Message Processor-এর IP অ্যাড্রেসগুলো থেকে আসা ট্র্যাফিকের অনুমতি দেওয়ার জন্য iptables ব্যবহার করতে পারেন।

যদি সমস্যাটি অব্যাহত থাকে, তবে সমস্যাটি চিহ্নিত ও সমাধান করার জন্য আপনার নেটওয়ার্ক অ্যাডমিনিস্ট্রেটরের সাথে কাজ করুন। Apigee-এর কাছ থেকে আপনার আরও কোনো সহায়তার প্রয়োজন হলে, Apigee Support-এর সাথে যোগাযোগ করুন।

কারণ: অসুরক্ষিত পোর্টে সুরক্ষিত অনুরোধ

রোগ নির্ণয়

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

   উদাহরণস্বরূপ, আপনি নীচে দেখানো HEALTH MONITOR ত্রুটি দেখতে পারেন:

   Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
           at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
           at sun.security.ssl.InputRecord.read(InputRecord.java:527)
           at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
   …<snipped>
           

   হেলথ মনিটরে কনফিগার করা MaxFailure সংখ্যক বার এই ত্রুটিটি পুনরাবৃত্ত হলে, আপনি এই ধরনের একটি সতর্কীকরণ বার্তা দেখতে পাবেন:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   সতর্কীকরণ বার্তায় দেওয়া তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে, নির্দিষ্ট এপিআই প্রক্সিতে ব্যবহৃত টার্গেট সার্ভারটির জন্য MaxFailure কাউন্ট পূর্ণ হয়েছে, যেটির জন্য আপনি NoActiveTargets এরর কোডসহ 503 রেসপন্স কোড পাচ্ছেন।

4. নিম্নলিখিত ত্রুটির কারণে স্বাস্থ্য পরীক্ষাটি ব্যর্থ হয়েছে:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   ত্রুটির বার্তা এবং ইউআরএল থেকে বোঝা যাচ্ছে যে, এই সমস্যার কারণ হলো অসুরক্ষিত পোর্ট ৮০- তে একটি সুরক্ষিত কল (HTTPS) করা হয়েছিল।

   এই ত্রুটিটি নিম্নলিখিত দুটি পরিস্থিতিতে ঘটতে পারে:

   • অসুরক্ষিত পোর্ট দিয়ে সুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করা হয়েছে
   • সুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করা হয়েছে কিন্তু হেলথ মনিটর একটি অসুরক্ষিত পোর্ট দিয়ে কনফিগার করা হয়েছে।

   সুরক্ষিত লক্ষ্য অসুরক্ষিত পোর্ট

   দৃশ্যকল্প ১: অসুরক্ষিত পোর্ট দিয়ে সুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করা হয়েছে

   আপনি যদি একটি সুরক্ষিত টার্গেট সার্ভার নির্ধারণ করে থাকেন কিন্তু পোর্ট ৮০-এর মতো কোনো অসুরক্ষিত পোর্ট ব্যবহার করেন, তাহলে আপনি এই ত্রুটিটি পাবেন। এই সমস্যার কারণ এটিই কিনা তা যাচাই করতে নিচের ধাপগুলো অনুসরণ করুন:

   1. টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা যাচাই করুন।

   টার্গেট সার্ভারের সংজ্ঞা পেতে Get TargetServer API ব্যবহার করুন।

   টার্গেট সার্ভার সংজ্ঞা আউটপুট

   <TargetServer name="mocktarget">
     <Host>mocktarget.apigee.net</Host>
     <Port>80</Port>
     <IsEnabled>true</IsEnabled>
     <SSLInfo>
         <Enabled>true</Enabled>
     </SSLInfo>
   </TargetServer>
             

   উপরের উদাহরণে, সংজ্ঞাটি থেকে দেখা যায় যে, SSLInfo ব্লক অনুযায়ী টার্গেট সার্ভার mocktarget একটি সুরক্ষিত সার্ভার। তবে, এটি একটি অ-সুরক্ষিত পোর্ট ৮০ দিয়ে কনফিগার করা হয়েছে।

   2. এখন, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশনটি পরীক্ষা করুন:

      স্বাস্থ্য মনিটর কনফিগারেশন

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      লক্ষ্য করুন যে উপরের হেলথ মনিটর কনফিগারেশনে কোনো <Port> এলিমেন্ট নির্দিষ্ট করা নেই। এক্ষেত্রে, Edge-এর মেসেজ প্রসেসর হেলথ চেক API কল করার জন্য টার্গেট সার্ভার ডেফিনিশনে নির্দিষ্ট করা পোর্টটি (যা ৮০) ব্যবহার করে।

   3. উপরোক্ত তথ্যের ভিত্তিতে, এই ত্রুটির কারণ হলো টার্গেট সার্ভারটিকে একটি সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হয়েছে (যেহেতু SSLInfo ব্লকটি সক্রিয় করা আছে), কিন্তু এর পোর্ট ৮০ অসুরক্ষিত।

   সুরক্ষিত লক্ষ্য অসুরক্ষিত এইচএম পোর্ট

   দৃশ্যকল্প ২: সুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করা হয়েছে কিন্তু হেলথ মনিটর একটি অসুরক্ষিত পোর্ট দিয়ে কনফিগার করা হয়েছে

   আপনি যদি একটি সুরক্ষিত টার্গেট সার্ভার নির্ধারণ করে থাকেন কিন্তু হেলথ মনিটরটি ৮০-এর মতো কোনো অসুরক্ষিত পোর্ট দিয়ে কনফিগার করা থাকে, তাহলে আপনি এই ত্রুটিটি পাবেন। এই সমস্যার কারণ এটিই কিনা তা যাচাই করতে নিচের ধাপগুলো অনুসরণ করুন:

   1. টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা যাচাই করুন।

      টার্গেট সার্ভারের সংজ্ঞা পেতে Get TargetServer API ব্যবহার করুন।

      টার্গেট সার্ভার সংজ্ঞা আউটপুট

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
              

      উপরের উদাহরণে, সংজ্ঞাটি থেকে দেখা যায় যে, SSLInfo ব্লক দ্বারা নির্দেশিত টার্গেট সার্ভার mocktarget একটি সুরক্ষিত সার্ভার।

   2. এরপরে, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশনটি পরীক্ষা করুন:

      স্বাস্থ্য মনিটর কনফিগারেশন

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      উপরের উদাহরণে, <Port> এলিমেন্ট দ্বারা নির্দেশিত হিসাবে হেলথ মনিটরটি একটি অসুরক্ষিত পোর্ট ৮০ দিয়ে কনফিগার করা হয়েছে।

   3. উপরোক্ত তথ্যের ভিত্তিতে, এই ত্রুটির কারণ হলো যে টার্গেট সার্ভারটিকে একটি সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হয়েছে (যেহেতু SSLInfo ব্লকটি সক্রিয় করা আছে) এবং এটি সুরক্ষিত পোর্ট ৪৪৩ ব্যবহার করে, কিন্তু হেলথ মনিটরটি একটি অ-সুরক্ষিত পোর্ট ৮০ (যা <Port> এলিমেন্টে নির্দিষ্ট করা আছে) দিয়ে হেলথ চেক করার জন্য কনফিগার করা হয়েছে।

      অর্থাৎ, এই ক্ষেত্রে, Edge অসুরক্ষিত পোর্ট ৮০ ব্যবহার করে হেলথ চেক এপিআইগুলোকে একটি সুরক্ষিত কল হিসেবে পাঠায় এবং উপরে উল্লিখিত ত্রুটি দেখিয়ে ব্যর্থ হয়।

সমাধান

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    

কারণ: সুরক্ষিত পোর্টে অসুরক্ষিত অনুরোধ

রোগ নির্ণয়

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

   উদাহরণস্বরূপ, আপনি নীচে দেখানো HEALTH MONITOR ত্রুটি দেখতে পারেন:

   Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
   …<snipped>
             

   হেলথ মনিটরে কনফিগার করা MaxFailure সংখ্যক বার এই ত্রুটিটি পুনরাবৃত্ত হলে, আপনি এই ধরনের একটি সতর্কীকরণ বার্তা দেখতে পাবেন:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

   সতর্কীকরণ বার্তায় দেওয়া তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে, নির্দিষ্ট এপিআই প্রক্সিতে ব্যবহৃত টার্গেট সার্ভারটির জন্য MaxFailure কাউন্ট পূর্ণ হয়েছে, যেটির জন্য আপনি NoActiveTargets এরর কোডসহ 503 রেসপন্স কোড পাচ্ছেন।

4. নিম্নলিখিত ত্রুটির কারণে স্বাস্থ্য পরীক্ষাটি ব্যর্থ হয়েছে:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   ত্রুটির বার্তা এবং ইউআরএল থেকে বোঝা যাচ্ছে যে, সুরক্ষিত পোর্ট ৪৪৩- এ একটি অসুরক্ষিত কল (HTTP) করা হয়েছিল।

   এই ত্রুটিটি নিম্নলিখিত দুটি পরিস্থিতিতে ঘটতে পারে:

   • সুরক্ষিত পোর্ট দিয়ে সংজ্ঞায়িত অসুরক্ষিত টার্গেট সার্ভার
   • অসুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করা হয়েছে, কিন্তু হেলথ মনিটর একটি সুরক্ষিত পোর্ট দিয়ে কনফিগার করা হয়েছে।

   অসুরক্ষিত লক্ষ্য সুরক্ষিত পোর্ট

   দৃশ্যকল্প ১: সুরক্ষিত পোর্ট দিয়ে সংজ্ঞায়িত অসুরক্ষিত টার্গেট সার্ভার

   আপনি যদি একটি অসুরক্ষিত টার্গেট সার্ভার নির্ধারণ করে থাকেন কিন্তু 443-এর মতো একটি সুরক্ষিত পোর্ট ব্যবহার করেন, তাহলে আপনি এই ত্রুটিটি পাবেন। এই সমস্যার কারণ এটিই কিনা তা যাচাই করতে নিচের ধাপগুলো অনুসরণ করুন:

   1. টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা যাচাই করুন।

      টার্গেট সার্ভারের সংজ্ঞা পেতে Get TargetServer API ব্যবহার করুন।

      টার্গেট সার্ভার সংজ্ঞা আউটপুট

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
                    

      উপরের উদাহরণে, সংজ্ঞা থেকে দেখা যায় যে টার্গেট সার্ভার mocktarget একটি অসুরক্ষিত সার্ভার, কারণ এতে কোনো SSLInfo ব্লক নেই। তবে, এটিকে ভুলবশত একটি সুরক্ষিত পোর্ট ৪৪৩ দিয়ে কনফিগার করা হয়েছে ।

   2. এখন, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশনটি পরীক্ষা করুন:

      স্বাস্থ্য মনিটর কনফিগারেশন

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      লক্ষ্য করুন যে উপরের হেলথ মনিটর কনফিগারেশনে কোনো <Port> এলিমেন্ট নির্দিষ্ট করা নেই। এক্ষেত্রে, Edge-এর মেসেজ প্রসেসর টার্গেট সার্ভার ডেফিনিশনে নির্দিষ্ট করা পোর্টটি, অর্থাৎ 443, ব্যবহার করবে।

   3. উপরোক্ত তথ্যের ভিত্তিতে, এই ত্রুটির কারণ হলো টার্গেট সার্ভারটিকে একটি অ-সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হয়েছে (কারণ SSLInfo ব্লকটি সংজ্ঞায়িত করা নেই), কিন্তু এর পোর্ট ৪৪৩ সুরক্ষিত।

      অর্থাৎ, Edge সুরক্ষিত পোর্ট 443 ব্যবহার করে একটি অসুরক্ষিত কল হিসাবে স্বাস্থ্য পরীক্ষা করে এবং উপরে উল্লিখিত ত্রুটির কারণে ব্যর্থ হয়।

   অসুরক্ষিত লক্ষ্য সুরক্ষিত HM পোর্ট

   দৃশ্যকল্প ২: অসুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করা হয়েছে কিন্তু হেলথ মনিটর একটি সুরক্ষিত পোর্ট দিয়ে কনফিগার করা হয়েছে

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

   1. টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা যাচাই করুন।

      টার্গেট সার্ভারের সংজ্ঞা পেতে Get TargetServer API ব্যবহার করুন।

      টার্গেট সার্ভার সংজ্ঞা আউটপুট

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      উপরের উদাহরণে, সংজ্ঞাটি থেকে দেখা যায় যে টার্গেট সার্ভার mocktarget একটি অসুরক্ষিত সার্ভার (কারণ এখানে কোনো SSLInfo ব্লক নেই) এবং এটি অসুরক্ষিত পোর্ট ৮০-তে সঠিকভাবে কনফিগার করা আছে।

   2. এরপরে, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশনটি পরীক্ষা করুন:

      স্বাস্থ্য মনিটর কনফিগারেশন

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      উপরের উদাহরণে, <Port> এলিমেন্ট দ্বারা নির্দেশিত হিসাবে হেলথ মনিটরটি একটি সুরক্ষিত পোর্ট 443 দিয়ে কনফিগার করা হয়েছে।

   3. উপরোক্ত তথ্যের ভিত্তিতে, এই ত্রুটির কারণ হলো, টার্গেট সার্ভারটিকে একটি নন-সিকিউর সার্ভার হিসেবে (যেহেতু SSLInfo ব্লকটি সংজ্ঞায়িত করা নেই) এবং নন-সিকিউর পোর্ট ৮০ সঠিকভাবে ব্যবহার করা হয়েছে, কিন্তু হেলথ মনিটরটি একটি সিকিউর পোর্ট ৪৪৩ (যা <Port> এলিমেন্টে নির্দিষ্ট করা আছে) ব্যবহার করে হেলথ চেক করার জন্য কনফিগার করা আছে।

      অর্থাৎ, এই ক্ষেত্রে, Edge সুরক্ষিত পোর্ট 443 ব্যবহার করে একটি অসুরক্ষিত কল হিসাবে স্বাস্থ্য পরীক্ষা করে এবং উপরে উল্লিখিত ত্রুটির কারণে ব্যর্থ হয়।

সমাধান

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

কারণ: হেলথ চেক এপিআই একটি ত্রুটি সহ সাড়া দিয়েছে

রোগ নির্ণয়

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

   উদাহরণস্বরূপ, আপনি নীচে দেখানো হেলথ মনিটর (HEALTH MONITOR) সতর্কতাটি দেখতে পারেন:

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
   Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
           

   হেলথ মনিটরে কনফিগার করা MaxFailure সংখ্যক বার এই ত্রুটিটি পুনরাবৃত্ত হলে, আপনি এই ধরনের একটি সতর্কীকরণ বার্তা দেখতে পাবেন:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   সতর্কীকরণ বার্তায় দেওয়া তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে, নির্দিষ্ট এপিআই প্রক্সিতে ব্যবহৃত টার্গেট সার্ভারটির জন্য MaxFailure কাউন্ট পূর্ণ হয়েছে, যেটির জন্য আপনি NoActiveTargets এরর কোডসহ 503 রেসপন্স কোড পাচ্ছেন।

4. স্বাস্থ্য পরীক্ষাটি সতর্কীকরণ বার্তাটি ফেরত দিয়েছে:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   উপরের সতর্কীকরণ বার্তায় বলা হয়েছে যে, হেলথ চেক এপিআই-এর জন্য প্রত্যাশিত রেসপন্স কোড ছিল ২০০ , কিন্তু প্রকৃত প্রাপ্ত রেসপন্স হলো ৪০৪। তাই, এটিকে একটি ব্যর্থতা হিসেবে গণ্য করা হচ্ছে।

5. হেলথ চেক এপিআই থেকে আসা ত্রুটিপূর্ণ প্রতিক্রিয়ার কারণ অনুসন্ধান করার আগে, এজ কেন হেলথ চেক এপিআই-এর জন্য প্রতিক্রিয়া কোড হিসেবে ২০০ আশা করে, তা নির্ধারণ করুন। এর জন্য, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের হেলথ মনিটর কনফিগারেশনটি পরীক্ষা করুন:

   স্বাস্থ্য মনিটর কনফিগারেশন

   <HealthMonitor>
     <IsEnabled>true</IsEnabled>
     <IntervalInSec>5</IntervalInSec>
     <HTTPMonitor>
       <Request>
         <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
         <Port>443</Port>
         <Verb>GET</Verb>
         <Path>/status/200</Path>
       </Request>
       <SuccessResponse>
         <ResponseCode>200</ResponseCode>
       </SuccessResponse>
     </HTTPMonitor>
   </HealthMonitor>
           

   লক্ষ্য করুন যে হেলথ মনিটর কনফিগারেশনটি <SuccessResponse> এলিমেন্টের অধীনে 200 রেসপন্স কোড দিয়ে কনফিগার করা হয়েছে। এর মানে হলো, Edge যদি হেলথ চেক API থেকে 200 ছাড়া অন্য কোনো রেসপন্স কোড (যেমন 400, 401, 404, 500) পায়, তবে এটিকে একটি ত্রুটি হিসেবে গণ্য করা হবে এবং ব্যর্থতার সংখ্যা বেড়ে যাবে।

6. এখন, হেলথ চেক এপিআই থেকে প্রাপ্ত ত্রুটিপূর্ণ প্রতিক্রিয়ার কারণ অনুসন্ধান করতে নিচের ধাপগুলো অনুসরণ করুন:
1. মেসেজ প্রসেসর লগে সতর্কীকরণ বার্তার আগের বার্তাটি দেখুন।

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
             

   এই বার্তা থেকে স্বাস্থ্য পরীক্ষার URL-টি লিখে রাখুন।

2. আপনি মেসেজ প্রসেসর থেকে সরাসরি এই ইউআরএল-এ কল করে প্রকৃত প্রতিক্রিয়াটি যাচাই করতে পারেন।

   curl -i https://mocktarget.apigee.net:443/status/200
             

   মেসেজ প্রসেসর লগ অনুযায়ী, উপরের কলটির প্রতিক্রিয়া হিসেবে 404 পাওয়া গেছে:

   < HTTP/2 404
             

3. এতে দেখা যায় যে, হেলথ চেক ইউআরএল-এ সরাসরি কল করলেও একই রেসপন্স কোড ৪০৪ দিয়ে তা ব্যর্থ হয়। এর মানে হলো, হেলথ চেক ইউআরএলটি হয়তো ভুল অথবা ইউআরএল-এর অংশ হিসেবে অ্যাক্সেস করা রিসোর্সটি আর উপলব্ধ নেই।
4. উপরে প্রদত্ত উদাহরণ হেলথ চেক এপিআই-তে সমস্যাটি দেখা দেয়, কারণ হেলথ মনিটর কনফিগারেশনে একটি ভুল ইউআরএল ব্যবহার করা হয়েছিল। মক টার্গেট এপিআই থেকে সঠিক ইউআরএলটি হলো https://mocktarget.apigee.net:443/statuscode/200 ।
7. যদি অন্য কোনো ত্রুটিপূর্ণ প্রতিক্রিয়া পান, তাহলে উপরের ধাপগুলো অনুসরণ করে তার কারণ নির্ণয় করুন। প্রয়োজনে আপনার ব্যাকএন্ড টিমের সাথে কাজ করুন।

সমাধান

1. আপনার ব্যাকএন্ড সার্ভারে হেলথ চেক এপিআই-এর সমস্যাটি সমাধান করুন।
2. উপরে আলোচিত উদাহরণে সমস্যাটি সমাধান করতে:
1. হেলথ মনিটর কনফিগারেশনে <Path> এলিমেন্টটি নিচে দেখানো অনুযায়ী /statuscode/200 এ পরিবর্তন করুন:

   <Path>/statuscode/200</Path>
           

2. এপিআই প্রক্সিতে পরিবর্তনগুলো সংরক্ষণ করুন।

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

এপিআই মনিটরিং ব্যবহার করে সমস্যা নির্ণয় করুন

এপিআই মনিটরিং আপনাকে ত্রুটি, পারফরম্যান্স, এবং লেটেন্সি সমস্যা ও সেগুলোর উৎস—যেমন ডেভেলপার অ্যাপ, এপিআই প্রক্সি, ব্যাকএন্ড টার্গেট বা এপিআই প্ল্যাটফর্ম—দ্রুত শনাক্ত করে সমস্যাযুক্ত এলাকাগুলো চিহ্নিত করতে সক্ষম করে।

এপিআই মনিটরিং ব্যবহার করে আপনার এপিআই-এর 5xx সমস্যাগুলো কীভাবে সমাধান করবেন, তা দেখানোর জন্য একটি নমুনা পরিস্থিতি ধাপে ধাপে অনুসরণ করুন । উদাহরণস্বরূপ, আপনি হয়তো একটি অ্যালার্ট সেট আপ করতে চাইতে পারেন, যাতে messaging.adaptors.http.flow.NoActiveTargets ফল্টের সংখ্যা একটি নির্দিষ্ট সীমা অতিক্রম করলে আপনাকে জানানো হয়।

রোগ নির্ণয়ের তথ্য অবশ্যই সংগ্রহ করতে হবে

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

1. আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
1. সংস্থার নাম
2. পরিবেশের নাম
3. এপিআই প্রক্সি নাম
4. ত্রুটিটি পুনরুৎপাদন করতে সম্পূর্ণ কার্ল (curl) কমান্ডটি ব্যবহার করুন।
5. ট্রেস ফাইলে 503 সার্ভিস আনঅ্যাভেইলেবল এবং নোঅ্যাক্টিভটার্গেটস এরর কোডসহ অনুরোধগুলো রয়েছে।
2. আপনি যদি প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
   1. সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে
   2. পরিবেশের নাম
   3. এপিআই প্রক্সি বান্ডেল
   4. ট্রেস ফাইলে 503 সার্ভিস আনঅ্যাভেইলেবল এবং নোঅ্যাক্টিভটার্গেটস এরর কোডসহ অনুরোধগুলো রয়েছে।
   5. NGINX অ্যাক্সেস লগ

      ( /opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log )

   6. বার্তা প্রসেসর লগ

      ( /opt/apigee/var/log/edge-message-processor/logs/system.log )