503 পরিষেবা উপলভ্য নেই - NoActiveTargets - HealthCheckFailures

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

ভিডিও

503 সমস্যার ব্যাপারে আরও তথ্য পেতে, নিম্নলিখিত ভিডিও দেখুন:

ভিডিও বিবরণ
503 পরিষেবা উপলভ্য নেই - NoActiveTargets সমস্যার সমাধান করা নিম্নলিখিত বিষয়গুলি সম্পর্কে জানুন:
  • টার্গেট সার্ভার ও হেল্থ মনিটরের গুরুত্ব
  • স্বাস্থ্য পরীক্ষা ব্যর্থ হওয়ার কারণে হওয়া রিয়েল-টাইম 503 Service Unavailable - NoActiveTargets সমস্যার সমাধান করা

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

API প্রক্সি অনুরোধের জন্য ক্লায়েন্ট অ্যাপ্লিকেশন 503 HTTP রেসপন্স স্ট্যাটাস কোড সহ পরিষেবা উপলভ্য নেই মেসেজ এবং NoActiveTargets সমস্যা কোড পায়।

সমস্যা সংক্রান্ত মেসেজ

আপনি নিম্নলিখিত সমস্যার উত্তর দেখতে পাবেন:

HTTP/1.1 503 Service Unavailable
  

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

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

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

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

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

হেলথ চেক করা যায়নি

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

কোনও টার্গেট সার্ভার হেলথ চেক করতে না পারলে, 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 সংখ্যায় পৌঁছেছে তা বুঝতে এটি আপনাকে সাহায্য করে:

  • টার্গেট সার্ভারের নাম
  • সংস্থা ও এনভায়রনমেন্টের নাম
  • API প্রক্সির নাম
  • টার্গেট এন্ডপয়েন্টের নাম

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

API প্রক্সি আবার ডিপ্লয় না করেই, Health Monitor ব্যবহার করলে, Apigee Edge অটোমেটিক কোনও টার্গেট সার্ভার সুস্থ হয়ে উঠলে, সেটিকে আবার রোটেট করার জন্য অন্তর্ভুক্ত করতে পারে।

হেলথ চেক ব্যর্থ হওয়ার সম্ভাব্য কারণগুলি এখানে দেওয়া হল:

কারণ বিবরণ কে সমস্যার সমাধানকারী ধাপগুলি অনুসরণ করতে পারবেন
কানেকশন টাইম-আউট সংক্রান্ত সমস্যা LoadBalancer কনফিগারেশনে নির্দিষ্ট টাইমআউট পিরিয়ডের মধ্যে মেসেজ প্রসেসর টার্গেট সার্ভারের সাথে কানেক্ট করতে পারছে না। Edge Private Cloud ব্যবহারকারী
অসুরক্ষিত পোর্টে সুরক্ষিত অনুরোধ
  1. টার্গেট সার্ভারকে সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হলে, কিন্তু সেটি ভুলভাবে অসুরক্ষিত পোর্ট দিয়ে কনফিগার করা হলে।
  2. টার্গেট সার্ভারকে যদি সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হয়, কিন্তু হেলথ মনিটর যদি অসুরক্ষিত পোর্টে হেলথ চেক করার জন্য কনফিগার করা হয়।
Edge Private Cloud ব্যবহারকারী
সুরক্ষিত পোর্টে অ-সুরক্ষিত অনুরোধ
  1. টার্গেট সার্ভারকে যদি অ-সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হয়, কিন্তু সেটি যদি ভুলভাবে সুরক্ষিত পোর্ট দিয়ে কনফিগার করা হয়।
  2. যদি টার্গেট সার্ভারকে অ-সুরক্ষিত সার্ভার হিসেবে সংজ্ঞায়িত করা হয়, কিন্তু হেলথ মনিটরটি একটি সুরক্ষিত পোর্টে হেলথ চেক করার জন্য কনফিগার করা হয়।
Edge Private Cloud ব্যবহারকারী
হেলথ চেক API সমস্যার মেসেজ দেখাচ্ছে হেলথ চেক API যদি কোনও ত্রুটি বা রেসপন্স কোড সহ উত্তর দেয়, তাহলে হেলথ মনিটরের SuccessResponse এলিমেন্টে নির্দিষ্ট করা ছাড়া অন্য কিছু। Edge Private Cloud ব্যবহারকারী

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

অনুরোধটি কেন সম্পূর্ণ করা যায়নি তা মেসেজ আইডি থেকে বোঝা

ট্রেস টুল

Trace টুল ব্যবহার করে ব্যর্থ অনুরোধের মেসেজ আইডি নির্ধারণ করতে:

  1. ট্রেস সেশন চালু করুন, API কল করুন এবং সমস্যাটি আবার তৈরি করুন - 503 পরিষেবা উপলভ্য নেই, সমস্যা কোড NoActiveTargets.
  2. কাজ না করা অনুরোধগুলির মধ্যে একটি বেছে নিন।
  3. AX ফেজ-এ নেভিগেট করুন এবং নিম্নলিখিত ছবিতে দেখানো ফেজ বিবরণ বিভাগে নিচে স্ক্রল করে অনুরোধের মেসেজ আইডি (X-Apigee.Message-ID) নির্ধারণ করুন।

    ফেজ বিবরণ বিভাগে মেসেজ আইডি

NGINX অ্যাক্সেস লগ

NGINX অ্যাক্সেস লগ ব্যবহার করে ব্যর্থ অনুরোধের মেসেজ আইডি নির্ধারণ করতে:

এছাড়াও, 503 সমস্যার জন্য মেসেজ আইডি নির্ধারণ করতে, আপনি NGINX অ্যাক্সেস লগ দেখতে পারেন। অতীতে সমস্যা হয়ে থাকলে অথবা সমস্যাটি মাঝে মাঝে হলে এবং আপনি UI-তে ট্রেস ক্যাপচার করতে না পারলে এটি বিশেষভাবে উপযোগী। NGINX অ্যাক্সেস লগ থেকে এই তথ্য নির্ধারণ করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

  1. NGINX অ্যাক্সেস লগ চেক করুন: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. নির্দিষ্ট সময়সীমার মধ্যে নির্দিষ্ট API প্রক্সির জন্য কোনও 503 সমস্যা আছে কিনা তা সার্চ করুন (যদি সমস্যাটি আগে ঘটে থাকে) অথবা এখনও 503 সহ কোনও অনুরোধ ব্যর্থ হচ্ছে কিনা তা দেখুন।
  3. X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets সহ কোনও 503 সমস্যা থাকলে, নিচের উদাহরণে দেখানো হয়েছে এমন এক বা একাধিক অনুরোধের জন্য মেসেজ আইডি নোট করুন:

    503 সমস্যার কোড সহ নমুনা এন্ট্রি

    স্ট্যাটাস কোড, মেসেজ আইডি, সমস্যার সোর্স ও সমস্যার কোড সহ এন্ট্রি

সাধারণ সমস্যার মেসেজ

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

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

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>

এইসব সমস্যার মেসেজ থেকে বোঝা যায় যে, কোনও সমস্যার কারণে ব্যাকএন্ড সার্ভারে অনুরোধ পাঠানো যায়নি। এর ফলে, মেসেজ প্রসেসর ক্লায়েন্টকে উত্তর হিসেবে 503 পরিষেবা উপলভ্য নেই সমস্যার কোড NoActiveTargets পাঠায়।

কারণ: কানেকশন টাইম-আউট হয়ে গেছে

ডায়াগনসিস

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

    যেমন, নিম্নলিখিত HEALTH MONITOR সমস্যার মেসেজ থেকে বোঝা যায় যে মেসেজ প্রসেসর হেলথ চেক API অনুরোধ করার সময় কানেকশন টাইম-আউট সংক্রান্ত সমস্যার কারণে কাজ করতে পারেনি:

    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>
            

    Health Monitor-এ কনফিগার করা 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}
            

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

  4. উপরের উদাহরণে, connection timed out সমস্যার কারণে হেলথ চেক করা যায়নি। আপনি telnet কমান্ড ব্যবহার করে প্রতিটি মেসেজ প্রসেসর থেকে সরাসরি নির্দিষ্ট ব্যাকএন্ড সার্ভারে কানেক্ট করতে পারছেন কিনা তা চেক করুন:
  5. telnet <BackendServer-HostName> 443
          
  6. আপনি ব্যাকএন্ড সার্ভারের সাথে কানেক্ট করতে পারলে, এই ধরনের মেসেজ দেখতে পেতে পারেন: ব্যাকএন্ড সার্ভারের সাথে কানেক্ট করা হয়েছে। তাহলে সমস্যাটি সাময়িক হতে পারে এবং এটি সমাধান হয়ে গেছে অথবা মাঝে মাঝে হচ্ছে। ৪ নম্বর ধাপটি কয়েকবার (১০+ বার) রিপিট করুন এবং আউটপুট যাচাই করুন।
    1. telnet কমান্ডে যদি কোনও সমস্যা না থাকে, তাহলে সমস্যাটি সমাধান হয়ে গেছে। হেল্থ চেক সংক্রান্ত সমস্যা বন্ধ হয়েছে কিনা তা আবার চেক করুন। যদি হ্যাঁ হয়, তাহলে আপনাকে আর কিছু করতে হবে না।
    2. আপনি যদি telnet কমান্ডের মাধ্যমে ব্যাকএন্ড সার্ভারের সাথে মাঝে মাঝে কানেক্ট করতে না পারেন, তাহলে নেটওয়ার্ক সংক্রান্ত সমস্যা হতে পারে অথবা আপনার ব্যাকএন্ড সার্ভার ব্যস্ত থাকতে পারে।
  7. আপনি যদি telnet কমান্ডের মাধ্যমে ব্যাকএন্ড সার্ভারের সাথে ক্রমাগত কানেক্ট করতে না পারেন, তাহলে এর কারণ হতে পারে যে নির্দিষ্ট ব্যাকএন্ড সার্ভারে মেসেজ প্রসেসর থেকে ট্রাফিক অনুমোদিত নয়।

রেজোলিউশন

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

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

কারণ: সুরক্ষিত পোর্ট ব্যবহার না করে সুরক্ষিত অনুরোধ করা হয়েছে

ডায়াগনসিস

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

    যেমন, আপনি নিচে দেখানো 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>
            

    Health Monitor-এ কনফিগার করা 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}
            

    সতর্কতা মেসেজে দেওয়া তথ্য মনোযোগ দিয়ে পড়ুন। নির্দিষ্ট API প্রক্সির জন্য ব্যবহৃত টার্গেট সার্ভারের জন্য 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?
          

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

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

    • নিরাপদ পোর্ট ছাড়া নিরাপদ টার্গেট সার্ভার
    • নিরাপদ টার্গেট সার্ভার নির্দিষ্ট করা হয়েছে কিন্তু হেলথ মনিটর অ-নিরাপদ পোর্ট দিয়ে কনফিগার করা হয়েছে

    সুরক্ষিত টার্গেট নন-সিকিওর পোর্ট

    পরিস্থিতি ১: সুরক্ষিত টার্গেট সার্ভার অ-সুরক্ষিত পোর্ট দিয়ে ডিফাইন করা হয়েছে

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

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

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

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

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

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

      হেলথ মনিটর কনফিগারেশন

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

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

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

    নিরাপদ টার্গেট নন-সিকিওর HM পোর্ট

    পরিস্থিতি ২: সুরক্ষিত টার্গেট সার্ভার নির্দিষ্ট করা আছে কিন্তু হেলথ মনিটর অ-সুরক্ষিত পোর্ট দিয়ে কনফিগার করা আছে

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

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

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

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

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

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

    2. এরপরে, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য Health Monitor কনফিগারেশন চেক করুন:

      হেলথ মনিটর কনফিগারেশন

      <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, পোর্ট ৮০-এর সাথে একটি সুরক্ষিত কল হিসেবে হেলথ চেক API তৈরি করে এবং উপরে উল্লিখিত সমস্যাটি হয়।

রেজোলিউশন

সুরক্ষিত টার্গেট নন-সিকিওর পোর্ট

পরিস্থিতি ১: সুরক্ষিত টার্গেট সার্ভার অ-সুরক্ষিত পোর্ট দিয়ে ডিফাইন করা হয়েছে

এই সমস্যার সমাধান করতে, উপযুক্ত সুরক্ষিত পোর্ট ব্যবহার করার জন্য টার্গেট সার্ভারের সংজ্ঞা আপডেট করুন।

টার্গেট সার্ভারের সংজ্ঞা আপডেট করতে এবং এটি নিশ্চিত করতে Update a TargetServer API ব্যবহার করুন যে নিচের উদাহরণে দেখানো একটি সুরক্ষিত পোর্ট (যেমন: 443) ব্যবহার করা হয়েছে:

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

নিরাপদ টার্গেট নন-সিকিওর HM পোর্ট

পরিস্থিতি ২: সুরক্ষিত টার্গেট সার্ভার নির্দিষ্ট করা আছে কিন্তু হেলথ মনিটর অ-সুরক্ষিত পোর্ট দিয়ে কনফিগার করা আছে

এই সমস্যার সমাধান করতে, নিচে উল্লেখ করা নির্দেশাবলী অনুসরণ করুন:

  1. নিচে দেখানো অনুযায়ী, ব্যর্থ API প্রক্সির টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের হেলথ চেক পারফর্ম করতে, নিরাপদ পোর্ট (যেমন: 443) ব্যবহার করার জন্য হেলথ মনিটর কনফিগারেশন পরিবর্তন করুন:
    <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>
            
  2. API প্রক্সিতে করা পরিবর্তন সেভ করুন।

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

ডায়াগনসিস

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

    যেমন, আপনি নিচে দেখানো 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>
              

    Health Monitor-এ কনফিগার করা 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}
              

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

  4. এই সমস্যার কারণে হেলথ চেক করা যায়নি:
    Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
          

    সমস্যা সংক্রান্ত মেসেজ ও URL থেকে বোঝা যাচ্ছে যে এর কারণ হল, একটি নিরাপদ নয় এমন কল (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>
                      

      লক্ষ্য করুন যে উপরে Health Monitor কনফিগারেশনে কোনও <Port> এলিমেন্ট নির্দিষ্ট করা নেই। এই ক্ষেত্রে, Edge-এর মেসেজ প্রসেসর টার্গেট সার্ভারের সংজ্ঞায় উল্লেখ করা পোর্ট ব্যবহার করবে, যেটি হল ৪৪৩।

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

      অর্থাৎ, Edge সুরক্ষিত পোর্ট ৪৪৩ সহ একটি অ-সুরক্ষিত কল হিসেবে হেলথ চেক করে এবং উপরে উল্লিখিত সমস্যাটি হওয়ার কারণে ব্যর্থ হয়।

    নিরাপদ নয় এমন টার্গেট নিরাপদ HM পোর্ট

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

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

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

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

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

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

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

    2. এরপরে, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য Health Monitor কনফিগারেশন চেক করুন:

      হেলথ মনিটর কনফিগারেশন

      <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> এলিমেন্ট দ্বারা নির্দেশিত নিরাপদ পোর্ট ৪৪৩-এর সাথে হেলথ মনিটর কনফিগার করা হয়েছে।

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

      অর্থাৎ, এই ক্ষেত্রে, Edge সুরক্ষিত পোর্ট ৪৪৩ সহ একটি অ-সুরক্ষিত কল হিসেবে হেলথ চেক করে এবং উপরে উল্লিখিত সমস্যাটি হয়।

রেজোলিউশন

অসুরক্ষিত টার্গেট সুরক্ষিত পোর্ট

পরিস্থিতি ১: সুরক্ষিত পোর্ট সহ অ-সুরক্ষিত টার্গেট সার্ভার

এই সমস্যার সমাধান করতে, উপযুক্ত সুরক্ষিত পোর্ট ব্যবহার করার জন্য টার্গেট সার্ভারের সংজ্ঞা আপডেট করুন।

টার্গেট সার্ভারের সংজ্ঞা আপডেট করতে এবং এটি নিশ্চিত করতে টার্গেট সার্ভার API আপডেট করুন ব্যবহার করুন যে নিচে দেখানো উদাহরণে সুরক্ষিত নয় এমন পোর্ট (যেমন: ৮০) ব্যবহার করা হয়েছে :

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

নিরাপদ নয় এমন টার্গেট নিরাপদ HM পোর্ট

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

এই সমস্যার সমাধান করতে, নিচে উল্লেখ করা নির্দেশাবলী অনুসরণ করুন:

  1. Health Monitor কনফিগারেশন থেকে <Port> এলিমেন্ট সরিয়ে দিন অথবা Health Monitor কনফিগারেশন পরিবর্তন করে অসুরক্ষিত পোর্ট (যেমন: ৮০) ব্যবহার করুন, যাতে নিচে দেখানো মতো ব্যর্থ API প্রক্সির টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভার হেলথ চেক করা যায়:
    <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>
    </HealthMonitor>
            
  2. API প্রক্সিতে করা পরিবর্তন সেভ করুন।

কারণ: হেল্থ চেক API সমস্যা সহ উত্তর দেয়

ডায়াগনসিস

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

    যেমন, আপনি নিচে দেখানো 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
            

    Health Monitor-এ কনফিগার করা 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}
            

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

  4. হেল্থ চেক থেকে এই সতর্কতামূলক মেসেজ পাওয়া গেছে:
    HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
          

    উপরের সতর্কতামূলক মেসেজে বলা হয়েছে যে হেলথ চেক API-এর জন্য প্রত্যাশিত রেসপন্স কোড ছিল 200, কিন্তু প্রকৃত রেসপন্স পাওয়া গেছে 404। তাই, এটি ব্যর্থ হিসেবে গণ্য করা হয়।

  5. হেলথ চেক API থেকে পাওয়া সমস্যার কারণ তদন্ত করার আগে, Edge কেন হেলথ চেক API-এর জন্য উত্তর কোড হিসেবে 200 আশা করে তা নির্ধারণ করুন। এর জন্য, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য Health Monitor কনফিগারেশন চেক করুন:

    হেলথ মনিটর কনফিগারেশন

    <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 রেসপন্স কোড সহ হেলথ মনিটর কনফিগারেশন কনফিগার করা হয়েছে। এর অর্থ হল, হেলথ চেক API থেকে Edge যদি 200 ছাড়া অন্য কোনও রেসপন্স কোড (যেমন 400, 401, 404, 500) পায়, সেটি একটি সমস্যা হিসেবে গণ্য করা হবে এবং ব্যর্থতার সংখ্যা বাড়িয়ে দেওয়া হবে।

  6. এখন, হেলথ চেক API থেকে পাওয়া সমস্যার উত্তরের কারণ তদন্ত করতে, নিচে উল্লেখ করা ধাপগুলি অনুসরণ করুন:
    1. মেসেজ প্রসেসর লগে সতর্কতামূলক মেসেজের আগে মেসেজটি দেখুন।
      Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
                

      এই মেসেজ থেকে হেলথ চেক URL লিখে নিন।

    2. আপনি মেসেজ প্রসেসর থেকে এই URL-এ সরাসরি কল করতে এবং আসল উত্তর চেক করতে পারবেন
      curl -i https://mocktarget.apigee.net:443/status/200
                

      উপরের কল থেকে পাওয়া উত্তরটি মেসেজ প্রসেসর লগে ৪০৪ হিসেবে দেখা যাচ্ছে:

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

রেজোলিউশন

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

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

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

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

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

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

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

  1. আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে, নিম্নলিখিত তথ্য প্রদান করুন:
    1. সংস্থার নাম
    2. পরিবেশের নাম
    3. API প্রক্সির নাম
    4. সমস্যাটি আবার তৈরি করতে curl কমান্ড সম্পূর্ণ করুন
    5. 503 Service Unavailable সহ অনুরোধ থাকা ট্রেস ফাইল, যার মধ্যে NoActiveTargets সমস্যার কোড রয়েছে
  2. আপনি Private Cloud ব্যবহারকারী হলে, নিম্নলিখিত তথ্য দিন:
    1. সম্পূর্ণ সমস্যার মেসেজ যা দেখা গেছে
    2. পরিবেশের নাম
    3. API Proxy বান্ডেল
    4. 503 Service Unavailable সহ অনুরোধ থাকা ট্রেস ফাইল, যার মধ্যে NoActiveTargets সমস্যার কোড রয়েছে
    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)