আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য
ভিডিও
503 ত্রুটি সম্পর্কে আরও তথ্যের জন্য নিম্নলিখিত ভিডিওগুলি দেখুন:
ভিডিও | বর্ণনা |
---|---|
503 পরিষেবা অনুপলব্ধ - সমস্যা সমাধান এবং সমাধান করুন - NoActiveTargets৷ | নিম্নলিখিত সম্পর্কে জানুন:
|
উপসর্গ
ক্লায়েন্ট অ্যাপ্লিকেশনটি HTTP প্রতিক্রিয়া স্ট্যাটাস কোড 503 পায় পরিষেবা অনুপলব্ধ বার্তা সহ এবং API প্রক্সি অনুরোধের জন্য ত্রুটি কোড 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 প্রক্সিতে টার্গেট এন্ডপয়েন্ট কনফিগারেশনে এক বা একাধিক টার্গেট সার্ভার ব্যবহার করেন।
এই প্লেবুকটি স্বাস্থ্য পরীক্ষা ব্যর্থতার কারণে সৃষ্ট ত্রুটি কোড NoActiveTargets সহ 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 প্রক্সি নাম
- টার্গেট এন্ডপয়েন্ট নাম
তারপরে, এজ সেই নির্দিষ্ট সার্ভারে আর কোনো অনুরোধ পাঠানো বন্ধ করে দেয়। লোডব্যালেন্সার কনফিগারেশনে কনফিগার করা সমস্ত টার্গেট সার্ভার MaxFailure
কাউন্টে পৌঁছে গেলে, পরবর্তী API অনুরোধগুলি 503 পরিষেবা অনুপলব্ধ ত্রুটি কোড NoActiveTargets সহ সাড়া দেওয়া হয়।
স্বাস্থ্য মনিটর ব্যবহার করা Apigee এজকে স্বয়ংক্রিয়ভাবে একটি টার্গেট সার্ভারকে রোটেশনে অন্তর্ভুক্ত করতে সাহায্য করে যখন এটি সুস্থ হয়ে ওঠে, API প্রক্সি পুনরায় স্থাপন না করেই।
এখানে স্বাস্থ্য পরীক্ষা ব্যর্থতার সম্ভাব্য কারণ রয়েছে:
কারণ | বর্ণনা | যারা সমস্যা সমাধানের পদক্ষেপগুলি সম্পাদন করতে পারে৷ |
---|---|---|
সংযোগের সময়সীমার ত্রুটি৷ | লোডব্যালেন্সার কনফিগারেশনের নির্দিষ্ট সময়সীমার মধ্যে মেসেজ প্রসেসর টার্গেট সার্ভারের সাথে সংযোগ করতে অক্ষম। | এজ প্রাইভেট ক্লাউড ব্যবহারকারীরা |
অ-সুরক্ষিত পোর্টে সুরক্ষিত অনুরোধ |
| এজ প্রাইভেট ক্লাউড ব্যবহারকারীরা |
নিরাপদ পোর্টে অ-সুরক্ষিত অনুরোধ |
| এজ প্রাইভেট ক্লাউড ব্যবহারকারীরা |
হেলথ চেক API একটি ত্রুটির সাথে সাড়া দেয় | হেলথ চেক এপিআই যদি কোনো ত্রুটি বা রেসপন্স কোড সহ সাড়া দেয়, তবে হেলথ মনিটরের সাকসেস রেসপন্স এলিমেন্টে উল্লেখ করা ছাড়া অন্য কিছু। | এজ প্রাইভেট ক্লাউড ব্যবহারকারীরা |
সাধারণ রোগ নির্ণয়ের পদক্ষেপ
ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করুন
ট্রেস টুল
ট্রেস টুল ব্যবহার করে ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করতে:
- ট্রেস সেশন সক্ষম করুন, API কল করুন এবং সমস্যাটি পুনরুত্পাদন করুন - ত্রুটি কোড NoActiveTargets সহ 503 পরিষেবা অনুপলব্ধ ।
- একটি ব্যর্থ অনুরোধ নির্বাচন করুন.
- AX পর্বে নেভিগেট করুন, এবং নিম্নলিখিত চিত্রে দেখানো হিসাবে ফেজ বিশদ বিভাগে নীচে স্ক্রোল করে অনুরোধের বার্তা আইডি (
X-Apigee.Message-ID
) নির্ধারণ করুন৷
NGINX অ্যাক্সেস লগ
NGINX অ্যাক্সেস লগ ব্যবহার করে ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করতে:
503 ত্রুটির জন্য বার্তা আইডি নির্ধারণ করতে আপনি NGINX অ্যাক্সেস লগগুলিও উল্লেখ করতে পারেন। এটি বিশেষভাবে উপযোগী যদি সমস্যাটি অতীতে ঘটে থাকে বা সমস্যাটি মাঝে মাঝে হয় এবং আপনি UI-তে ট্রেস ক্যাপচার করতে অক্ষম হন। NGINX অ্যাক্সেস লগ থেকে এই তথ্য নির্ধারণ করতে নিম্নলিখিত পদক্ষেপগুলি ব্যবহার করুন:
- NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন: (
/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log
) - একটি নির্দিষ্ট সময়কালের (যদি সমস্যা অতীতে ঘটে থাকে) নির্দিষ্ট API প্রক্সির জন্য কোনো 503 ত্রুটি আছে কিনা বা 503 এর সাথে এখনও কোনো অনুরোধ ব্যর্থ হলে অনুসন্ধান করুন।
- যদি X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets এর সাথে কোনো 503 ত্রুটি থাকে, তাহলে নিম্নলিখিত উদাহরণে দেখানো এক বা একাধিক অনুরোধের জন্য বার্তা আইডিটি নোট করুন:
নমুনা এন্ট্রি 503 ত্রুটি দেখাচ্ছে
সাধারণ ত্রুটি বার্তা
যখন টার্গেট সার্ভারগুলি ব্যবহার করা হয় এবং বার্তা প্রসেসর ব্যাকএন্ড সার্ভারের সাথে সংযোগ করার চেষ্টা করার সময় একটি ত্রুটি ঘটে, তখন আপনি বার্তা প্রসেসর লগগুলিতে কয়েকটি সাধারণ ত্রুটি বার্তা দেখতে পাবেন। এই ত্রুটিগুলি প্রকৃত ব্যতিক্রম/ত্রুটি বার্তার পরে লগ করা হয় যা ব্যর্থতার দিকে পরিচালিত করে।
ত্রুটি কোড NoActiveTargets এর সাথে অনুপলব্ধ 503 পরিষেবার জন্য মেসেজ প্রসেসর লগগুলিতে ( /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 পরিষেবা অনুপলব্ধ পাঠায়।
কারণ: সংযোগের সময় শেষ
রোগ নির্ণয়
- ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করুন ।
- মেসেজ প্রসেসর লগে বার্তা আইডি খুঁজুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log
)। - আপনি বার্তা আইডির সাথে সম্পর্কিত সাধারণ ত্রুটি বার্তাগুলি দেখতে পাবেন। যাইহোক, স্বাস্থ্য পরীক্ষা ব্যর্থতার প্রকৃত কারণ জানতে, এই সাধারণ ত্রুটি বার্তাগুলির উপরে স্ক্রোল করুন এবং স্বাস্থ্য মনিটর ত্রুটিগুলি পরীক্ষা করুন৷
উদাহরণস্বরূপ, নিম্নলিখিত স্বাস্থ্য মনিটর ত্রুটি বার্তাটি নির্দেশ করে যে স্বাস্থ্য পরীক্ষা 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>
যদি এই ত্রুটিটি স্বাস্থ্য মনিটরে কনফিগার করা
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 প্রতিক্রিয়া কোডটি অনুভব করছেন। - উপরের উদাহরণে,
connection timed out
ত্রুটির সাথে স্বাস্থ্য পরীক্ষা ব্যর্থ হয়েছে। আপনিtelnet
কমান্ড ব্যবহার করে প্রতিটি মেসেজ প্রসেসর থেকে সরাসরি নির্দিষ্ট ব্যাকএন্ড সার্ভারের সাথে সংযোগ করতে সক্ষম কিনা তা পরীক্ষা করুন: - আপনি যদি ব্যাকএন্ড সার্ভারের সাথে সংযোগ করতে সক্ষম হন, তাহলে আপনি ব্যাকএন্ড সার্ভারের সাথে সংযুক্ত একটি বার্তা দেখতে পারেন। তারপর সমস্যাটি একটি অস্থায়ী সমস্যা হতে পারে এবং এটি হয় সমাধান হতে পারে বা একটি অন্তর্বর্তী সমস্যা। ধাপ 4 কয়েকবার পুনরাবৃত্তি করুন (10+ বার) এবং আউটপুট যাচাই করুন।
- যদি ধারাবাহিকভাবে
telnet
কমান্ডের সাথে কোন ত্রুটি না থাকে, তাহলে সমস্যাটি সমাধান করা হয়েছে। স্বাস্থ্য পরীক্ষার ব্যর্থতা বন্ধ হয়ে গেছে কিনা তা পুনরায় পরীক্ষা করুন। যদি হ্যাঁ, তাহলে আপনাকে আর কিছু করতে হবে না। - আপনি যদি মাঝে মাঝে
telnet
কমান্ডের সাথে ব্যাকএন্ড সার্ভারের সাথে সংযোগ করতে অক্ষম হন, তাহলে একটি নেটওয়ার্ক সমস্যা হতে পারে বা আপনার ব্যাকএন্ড সার্ভার ব্যস্ত থাকতে পারে। - আপনি যদি
telnet
কমান্ডের সাথে ব্যাকএন্ড সার্ভারের সাথে ধারাবাহিকভাবে সংযোগ করতে না পারেন, তাহলে এটি হতে পারে কারণ নির্দিষ্ট ব্যাকএন্ড সার্ভারে বার্তা প্রসেসর থেকে ট্রাফিকের অনুমতি নেই।
telnet <BackendServer-HostName> 443
রেজোলিউশন
যদি connection timed out
ত্রুটি ধারাবাহিকভাবে পরিলক্ষিত হয়, তাহলে নিশ্চিত করুন যে ব্যাকএন্ড সার্ভারে কোনো ফায়ারওয়াল বিধিনিষেধ নেই এবং Apigee এজ মেসেজ প্রসেসর থেকে ট্রাফিকের অনুমতি দেয়। উদাহরণস্বরূপ, লিনাক্সে, আপনি ব্যাকএন্ড সার্ভারে বার্তা প্রসেসরের আইপি ঠিকানাগুলি থেকে ট্রাফিকের অনুমতি দিতে iptables ব্যবহার করতে পারেন।
সমস্যাটি অব্যাহত থাকলে, সমস্যাটি নির্ধারণ এবং সমাধান করতে আপনার নেটওয়ার্ক প্রশাসকের সাথে কাজ করুন। আপনার যদি Apigee থেকে আরও কোনো সহায়তার প্রয়োজন হয়, Apigee সহায়তার সাথে যোগাযোগ করুন।
কারণ: অ-সুরক্ষিত পোর্টে সুরক্ষিত অনুরোধ
রোগ নির্ণয়
- ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করুন ।
- মেসেজ প্রসেসর লগে বার্তা আইডি খুঁজুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log
)। - আপনি বার্তা আইডির সাথে সম্পর্কিত সাধারণ ত্রুটি বার্তাগুলি দেখতে পাবেন। যাইহোক, স্বাস্থ্য পরীক্ষা ব্যর্থতার প্রকৃত কারণ জানতে, এই সাধারণ ত্রুটি বার্তাগুলির উপরে স্ক্রোল করুন এবং স্বাস্থ্য মনিটর ত্রুটিগুলি পরীক্ষা করুন৷
উদাহরণস্বরূপ, আপনি নীচে দেখানো হিসাবে একটি স্বাস্থ্য মনিটর ত্রুটি দেখতে পারেন:
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}
সতর্কীকরণ বার্তায় প্রদত্ত তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে নির্দিষ্ট API প্রক্সিতে ব্যবহৃত একটি টার্গেট সার্ভারের জন্য
MaxFailure
গণনা পৌঁছে গেছে যার জন্য আপনি ত্রুটি কোড NoActiveTargets সহ 503 প্রতিক্রিয়া কোডটি অনুভব করছেন। - ত্রুটি সহ স্বাস্থ্য পরীক্ষা ব্যর্থ হয়েছে:
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200 javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
ত্রুটি বার্তা এবং URL এই সমস্যার কারণ নির্দেশ করে যে একটি নিরাপদ কল (HTTPS) অ-সুরক্ষিত পোর্ট 80 এ করা হয়েছিল।
এই ত্রুটি নিম্নলিখিত দুটি পরিস্থিতিতে ঘটতে পারে:
- নিরাপদ টার্গেট সার্ভার অ-নিরাপদ পোর্টের সাথে সংজ্ঞায়িত
- নিরাপদ লক্ষ্য সার্ভার সংজ্ঞায়িত কিন্তু স্বাস্থ্য মনিটর একটি অ-সুরক্ষিত পোর্টের সাথে কনফিগার করা হয়েছে
নিরাপদ লক্ষ্য অ-সুরক্ষিত পোর্ট
দৃশ্যকল্প 1: সুরক্ষিত লক্ষ্য সার্ভার অ-সুরক্ষিত পোর্টের সাথে সংজ্ঞায়িত
আপনি যদি একটি সুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করে থাকেন তবে একটি অ-সুরক্ষিত পোর্ট যেমন 80 সহ, তাহলে আপনি এই ত্রুটিটি পাবেন। এটি এই সমস্যার কারণ কিনা তা যাচাই করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:
- টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা পরীক্ষা করুন।
- এখন, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশন চেক করুন:
স্বাস্থ্য মনিটর কনফিগারেশন
<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>
উপাদান নির্দিষ্ট করা নেই। এই ক্ষেত্রে, এজ-এর মেসেজ প্রসেসর স্বাস্থ্য পরীক্ষা API কল করার জন্য লক্ষ্য সার্ভারের সংজ্ঞায় (যা 80) নির্দিষ্ট পোর্ট ব্যবহার করে। - উপরের তথ্যের উপর ভিত্তি করে, এই ত্রুটির কারণ হল টার্গেট সার্ভারটিকে একটি সুরক্ষিত সার্ভার হিসাবে সংজ্ঞায়িত করা হয়েছে (যেহেতু SSLInfo ব্লক সক্ষম করা হয়েছে), কিন্তু একটি অ-সুরক্ষিত পোর্ট 80 সহ।
টার্গেট সার্ভারের সংজ্ঞা পেতে 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 ব্লক দ্বারা নির্দেশিত। যাইহোক, এটি একটি অ-সুরক্ষিত পোর্ট 80 দিয়ে কনফিগার করা হয়েছে।নিরাপদ লক্ষ্য অ-নিরাপদ HM পোর্ট
দৃশ্যকল্প 2: সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত কিন্তু স্বাস্থ্য মনিটর একটি অ-সুরক্ষিত পোর্টের সাথে কনফিগার করা হয়েছে
আপনি যদি একটি সুরক্ষিত টার্গেট সার্ভার সংজ্ঞায়িত করে থাকেন তবে স্বাস্থ্য মনিটরটি একটি অ-সুরক্ষিত পোর্ট যেমন 80 দিয়ে কনফিগার করা থাকে, তাহলে আপনি এই ত্রুটিটি পাবেন। এটি এই সমস্যার কারণ কিনা তা যাচাই করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:
- টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা পরীক্ষা করুন।
টার্গেট সার্ভারের সংজ্ঞা পেতে 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 ব্লক দ্বারা নির্দেশিত। - এরপরে, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশন চেক করুন:
স্বাস্থ্য মনিটর কনফিগারেশন
<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>
উপরের উদাহরণে, স্বাস্থ্য মনিটরটিকে একটি অ-সুরক্ষিত পোর্ট 80 দিয়ে কনফিগার করা হয়েছে যেমনটি
<Port>
উপাদান দ্বারা নির্দেশিত। - উপরের তথ্যের উপর ভিত্তি করে, এই ত্রুটির কারণ হল টার্গেট সার্ভারটিকে একটি সুরক্ষিত সার্ভার হিসাবে সংজ্ঞায়িত করা হয়েছে (যেহেতু SSLInfo ব্লক সক্ষম করা হয়েছে) এবং সুরক্ষিত পোর্ট 443 ব্যবহার করে, তবে স্বাস্থ্য মনিটরটি একটি অ-সুরক্ষিত সহ স্বাস্থ্য পরীক্ষা করার জন্য কনফিগার করা হয়েছে। পোর্ট 80 (
<Port>
এলিমেন্টে নির্দিষ্ট)।অর্থাৎ, এই ক্ষেত্রে, এজ অ-সুরক্ষিত পোর্ট 80 এর সাথে একটি সুরক্ষিত কল হিসাবে স্বাস্থ্য পরীক্ষা APIs তৈরি করে এবং উপরে উল্লিখিত ত্রুটির সাথে ব্যর্থ হয়।
রেজোলিউশন
নিরাপদ লক্ষ্য অ-সুরক্ষিত পোর্ট
দৃশ্যকল্প 1: সুরক্ষিত লক্ষ্য সার্ভার অ-সুরক্ষিত পোর্টের সাথে সংজ্ঞায়িত
এই ত্রুটিটি ঠিক করতে, একটি উপযুক্ত সুরক্ষিত পোর্ট ব্যবহার করতে লক্ষ্য সার্ভারের সংজ্ঞা আপডেট করুন৷
টার্গেট সার্ভারের সংজ্ঞা আপডেট করতে এবং একটি নিরাপদ পোর্ট (উদাহরণস্বরূপ: 443) ব্যবহার করা হয়েছে তা নিশ্চিত করতে একটি টার্গেট সার্ভার API আপডেট করুন নীচের উদাহরণে দেখানো হয়েছে:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
নিরাপদ লক্ষ্য অ-নিরাপদ HM পোর্ট
দৃশ্যকল্প 2: সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত কিন্তু স্বাস্থ্য মনিটর একটি অ-সুরক্ষিত পোর্টের সাথে কনফিগার করা হয়েছে
এই ত্রুটিটি ঠিক করতে, নীচের নির্দেশাবলী অনুসরণ করুন:
- একটি নিরাপদ পোর্ট ব্যবহার করার জন্য স্বাস্থ্য মনিটর কনফিগারেশন পরিবর্তন করুন (উদাহরণস্বরূপ: 443) নিচে দেখানো হিসাবে ব্যর্থ API প্রক্সির টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের স্বাস্থ্য পরীক্ষা করতে:
<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>
- API প্রক্সিতে পরিবর্তনগুলি সংরক্ষণ করুন।
কারণ: একটি নিরাপদ পোর্টে অ-সুরক্ষিত অনুরোধ
রোগ নির্ণয়
- ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করুন ।
- মেসেজ প্রসেসর লগে বার্তা আইডি খুঁজুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log
)। - আপনি বার্তা আইডির সাথে সম্পর্কিত সাধারণ ত্রুটি বার্তাগুলি দেখতে পাবেন। যাইহোক, স্বাস্থ্য পরীক্ষা ব্যর্থতার প্রকৃত কারণ জানতে, এই সাধারণ ত্রুটি বার্তাগুলির উপরে স্ক্রোল করুন এবং স্বাস্থ্য মনিটর ত্রুটিগুলি পরীক্ষা করুন৷
উদাহরণস্বরূপ, আপনি নীচে দেখানো হিসাবে একটি স্বাস্থ্য মনিটর ত্রুটি দেখতে পারেন:
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}
সতর্কীকরণ বার্তায় প্রদত্ত তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে নির্দিষ্ট API প্রক্সিতে ব্যবহৃত একটি টার্গেট সার্ভারের জন্য
MaxFailure
গণনা পৌঁছে গেছে যার জন্য আপনি ত্রুটি কোড NoActiveTargets সহ 503 প্রতিক্রিয়া কোডটি অনুভব করছেন। - ত্রুটি সহ স্বাস্থ্য পরীক্ষা ব্যর্থ হয়েছে:
Error sending request Request URL : http://mocktarget.apigee.net:443/status java.net.SocketException: Unexpected end of file from server
ত্রুটি বার্তা এবং URL এই সমস্যার কারণ নির্দেশ করে যে নিরাপদ পোর্ট 443 এ একটি অ-সুরক্ষিত কল (HTTP) করা হয়েছিল।
এই ত্রুটি নিম্নলিখিত দুটি পরিস্থিতিতে ঘটতে পারে:
- নিরাপদ পোর্টের সাথে সংজ্ঞায়িত অ-সুরক্ষিত লক্ষ্য সার্ভার
- অ-সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত কিন্তু স্বাস্থ্য মনিটর একটি নিরাপদ পোর্টের সাথে কনফিগার করা হয়েছে
অ-সুরক্ষিত লক্ষ্য নিরাপদ পোর্ট
দৃশ্যকল্প 1: নিরাপদ পোর্টের সাথে সংজ্ঞায়িত অ-সুরক্ষিত লক্ষ্য সার্ভার
আপনি যদি একটি অ-সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত করে থাকেন তবে একটি সুরক্ষিত পোর্ট যেমন 443 সহ, তাহলে আপনি এই ত্রুটিটি পাবেন। এটি এই সমস্যার কারণ কিনা তা যাচাই করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:
- টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা পরীক্ষা করুন।
টার্গেট সার্ভারের সংজ্ঞা পেতে Get TargetServer API ব্যবহার করুন।
লক্ষ্য সার্ভার সংজ্ঞা আউটপুট
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer>
উপরের উদাহরণে, সংজ্ঞাটি দেখায় যে লক্ষ্য সার্ভার
mocktarget
একটি অ-সুরক্ষিত সার্ভার কারণ সেখানে কোনো SSLInfo ব্লক নেই। যাইহোক, এটি একটি নিরাপদ পোর্ট 443 এর সাথে ভুলভাবে কনফিগার করা হয়েছে। - এখন, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশন চেক করুন:
স্বাস্থ্য মনিটর কনফিগারেশন
<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>
উপাদান নির্দিষ্ট করা নেই। এই ক্ষেত্রে, এজ এর মেসেজ প্রসেসর টার্গেট সার্ভারের সংজ্ঞায় উল্লেখিত পোর্ট ব্যবহার করবে যা 443। - উপরের তথ্যের উপর ভিত্তি করে, এই ত্রুটির কারণ হল টার্গেট সার্ভারটিকে একটি অ-সুরক্ষিত সার্ভার হিসাবে সংজ্ঞায়িত করা হয়েছে (যেহেতু SSLInfo ব্লক সংজ্ঞায়িত করা হয়নি), কিন্তু একটি সুরক্ষিত পোর্ট 443 সহ।
অর্থাৎ, Edge নিরাপদ পোর্ট 443 এর সাথে একটি অ-সুরক্ষিত কল হিসাবে স্বাস্থ্য পরীক্ষা করে এবং উপরে উল্লিখিত ত্রুটির সাথে ব্যর্থ হয়।
অ-সুরক্ষিত লক্ষ্য নিরাপদ HM পোর্ট
দৃশ্যকল্প 2: অ-সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত কিন্তু স্বাস্থ্য মনিটর একটি নিরাপদ পোর্টের সাথে কনফিগার করা হয়েছে
আপনি যদি একটি অ-সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত করে থাকেন তবে স্বাস্থ্য মনিটরটি একটি সুরক্ষিত পোর্ট যেমন 443 এর সাথে কনফিগার করা থাকে, তাহলে আপনি এই ত্রুটিটি পাবেন। এটি এই সমস্যার কারণ কিনা তা যাচাই করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:
- টার্গেট এন্ডপয়েন্ট কনফিগারেশনে ব্যবহৃত টার্গেট সার্ভারের সংজ্ঞা পরীক্ষা করুন।
টার্গেট সার্ভারের সংজ্ঞা পেতে Get TargetServer API ব্যবহার করুন।
লক্ষ্য সার্ভার সংজ্ঞা আউটপুট
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
উপরের উদাহরণে, সংজ্ঞাটি দেখায় যে লক্ষ্য সার্ভার
mocktarget
একটি অ-সুরক্ষিত সার্ভার (যেহেতু কোন SSLInfo ব্লক নেই) একটি অ-সুরক্ষিত পোর্ট 80 এর সাথে সঠিকভাবে কনফিগার করা হয়েছে। - এরপরে, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশন চেক করুন:
স্বাস্থ্য মনিটর কনফিগারেশন
<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>
উপরের উদাহরণে, হেলথ মনিটরটিকে একটি সুরক্ষিত পোর্ট 443 দিয়ে কনফিগার করা হয়েছে যেমনটি
<Port>
উপাদান দ্বারা নির্দেশিত। - উপরের তথ্যের উপর ভিত্তি করে, এই ত্রুটির কারণ হল টার্গেট সার্ভারটিকে একটি অ-সুরক্ষিত সার্ভার হিসাবে সংজ্ঞায়িত করা হয়েছে (যেহেতু SSLInfo ব্লক সংজ্ঞায়িত করা হয়নি) অ-সুরক্ষিত পোর্ট 80 সঠিকভাবে, কিন্তু স্বাস্থ্য মনিটরটি স্বাস্থ্য পরীক্ষা করার জন্য কনফিগার করা হয়েছে। একটি সুরক্ষিত পোর্ট 443 সহ (
<Port>
উপাদানে নির্দিষ্ট করা হয়েছে)।অর্থাৎ, এই ক্ষেত্রে, Edge নিরাপদ পোর্ট 443 সহ একটি অ-সুরক্ষিত কল হিসাবে স্বাস্থ্য পরীক্ষা করে এবং উপরে উল্লিখিত ত্রুটির সাথে ব্যর্থ হয়।
রেজোলিউশন
অ-সুরক্ষিত লক্ষ্য নিরাপদ পোর্ট
দৃশ্যকল্প 1: নিরাপদ পোর্টের সাথে সংজ্ঞায়িত অ-সুরক্ষিত লক্ষ্য সার্ভার
এই ত্রুটিটি ঠিক করতে, একটি উপযুক্ত সুরক্ষিত পোর্ট ব্যবহার করতে লক্ষ্য সার্ভারের সংজ্ঞা আপডেট করুন৷
টার্গেট সার্ভারের সংজ্ঞা আপডেট করতে এবং একটি অ-সুরক্ষিত পোর্ট (উদাহরণস্বরূপ: 80) ব্যবহার করা হয়েছে তা নিশ্চিত করতে একটি টার্গেট সার্ভার API আপডেট করুন। নীচের উদাহরণে দেখানো হয়েছে:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
অ-সুরক্ষিত লক্ষ্য নিরাপদ HM পোর্ট
দৃশ্যকল্প 2: অ-সুরক্ষিত লক্ষ্য সার্ভার সংজ্ঞায়িত কিন্তু স্বাস্থ্য মনিটর একটি নিরাপদ পোর্টের সাথে কনফিগার করা হয়েছে
এই ত্রুটিটি ঠিক করতে, নীচের নির্দেশাবলী অনুসরণ করুন:
- হয় হেলথ মনিটর কনফিগারেশন থেকে
<Port>
উপাদানটি সরিয়ে ফেলুন বা স্বাস্থ্য মনিটর কনফিগারেশন পরিবর্তন করুন একটি অ-সুরক্ষিত পোর্ট ব্যবহার করার জন্য (উদাহরণস্বরূপ: 80) লক্ষ্য সার্ভারের স্বাস্থ্য পরীক্ষা করতে ব্যর্থ 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>
- API প্রক্সিতে পরিবর্তনগুলি সংরক্ষণ করুন।
কারণ: স্বাস্থ্য পরীক্ষা API একটি ত্রুটির সাথে সাড়া দেয়
রোগ নির্ণয়
- ব্যর্থ অনুরোধের বার্তা আইডি নির্ধারণ করুন ।
- মেসেজ প্রসেসর লগে বার্তা আইডি খুঁজুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log
)। - আপনি বার্তা আইডির সাথে সম্পর্কিত সাধারণ ত্রুটি বার্তাগুলি দেখতে পাবেন। যাইহোক, স্বাস্থ্য পরীক্ষা ব্যর্থতার প্রকৃত কারণ জানতে, এই সাধারণ ত্রুটি বার্তাগুলির উপরে স্ক্রোল করুন এবং স্বাস্থ্য মনিটর ত্রুটি/সতর্কতাগুলি পরীক্ষা করুন৷
উদাহরণস্বরূপ, আপনি নীচে দেখানো হিসাবে একটি স্বাস্থ্য মনিটর সতর্কতা দেখতে পারেন:
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}
সতর্কীকরণ বার্তায় প্রদত্ত তথ্য মনোযোগ সহকারে পড়ুন। নিশ্চিত করুন যে নির্দিষ্ট API প্রক্সিতে ব্যবহৃত একটি টার্গেট সার্ভারের জন্য
MaxFailure
গণনা পৌঁছে গেছে যার জন্য আপনি ত্রুটি কোড NoActiveTargets সহ 503 প্রতিক্রিয়া কোডটি অনুভব করছেন। - স্বাস্থ্য পরীক্ষা সতর্কতা বার্তা ফিরিয়ে দিয়েছে:
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
উপরের সতর্ক বার্তায় বলা হয়েছে যে হেলথ চেক API এর জন্য প্রত্যাশিত রেসপন্স কোড ছিল 200 , কিন্তু প্রকৃত রেসপন্স হল 404 । অতএব, এটি একটি ব্যর্থতা হিসাবে বিবেচিত হয়।
- হেলথ চেক এপিআই থেকে ত্রুটির প্রতিক্রিয়ার কারণ অনুসন্ধান করার আগে, কেন এজ হেলথ চেক এপিআই-এর জন্য 200 হিসাবে প্রতিক্রিয়া কোড আশা করে তা নির্ধারণ করুন। এর জন্য, টার্গেট এন্ডপয়েন্ট কনফিগারেশনে টার্গেট সার্ভারের জন্য হেলথ মনিটর কনফিগারেশন চেক করুন:
স্বাস্থ্য মনিটর কনফিগারেশন
<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 প্রতিক্রিয়া কোড দিয়ে কনফিগার করা হয়েছে। এর মানে হল যে যদি এজ হেলথ চেক এপিআই থেকে 200 ছাড়া অন্য কোনো রেসপন্স কোড (যেমন 400, 401, 404, 500) পায়, তাহলে এটি একটি ত্রুটি হিসেবে গণ্য হবে এবং ব্যর্থতার সংখ্যা বৃদ্ধি করবে। - এখন, স্বাস্থ্য পরীক্ষা API থেকে ত্রুটির প্রতিক্রিয়ার কারণ অনুসন্ধান করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:
- বার্তা প্রসেসর লগে সতর্কতা বার্তার আগে বার্তাটি দেখুন।
Apigee-Timer-7 INFO SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
এই বার্তা থেকে স্বাস্থ্য পরীক্ষার URL এর একটি নোট করুন।
- আপনি মেসেজ প্রসেসর থেকে এই URL-এ সরাসরি কল করতে পারেন এবং প্রকৃত প্রতিক্রিয়া চেক করতে পারেন
curl -i https://mocktarget.apigee.net:443/status/200
উপরের কলটির প্রতিক্রিয়া 404 দেয় যেমনটি মেসেজ প্রসেসর লগগুলিতে দেখা যায়:
< HTTP/2 404
- এটি দেখায় যে, স্বাস্থ্য পরীক্ষা URL-এ সরাসরি কলও একই প্রতিক্রিয়া কোড 404 দিয়ে ব্যর্থ হয়। এর মানে হল যে স্বাস্থ্য পরীক্ষা URLটি ভুল হতে পারে বা URL-এর অংশ হিসাবে অ্যাক্সেস করা সংস্থানটি আর উপলব্ধ নেই৷
- উপরে প্রদত্ত স্বাস্থ্য পরীক্ষা API-এর উদাহরণে, সমস্যাটি ঘটে কারণ স্বাস্থ্য মনিটর কনফিগারেশনে একটি ভুল URL ব্যবহার করা হয়েছিল। মক টার্গেট এপিআই থেকে সঠিক URLটি
https://mocktarget.apigee.net:443/statuscode/200
বলে পাওয়া গেছে। - আপনি যদি অন্য কোনো ত্রুটির প্রতিক্রিয়া পান, তাহলে উপরের পদক্ষেপগুলি অনুসরণ করে একই কারণ নির্ধারণ করুন। প্রয়োজন হলে, আপনার ব্যাকএন্ড দলের সাথে কাজ করুন।
রেজোলিউশন
- আপনার ব্যাকএন্ড সার্ভারে হেলথ চেক এপিআই দিয়ে সমস্যাটি ঠিক করুন।
- উপরে আলোচিত উদাহরণে সমস্যাটি সমাধান করতে:
- হেলথ মনিটর কনফিগারেশনের
<Path>
উপাদানটিকে নীচের হিসাবে/statuscode/200
এ পরিবর্তন করুন:<Path>/statuscode/200</Path>
- API প্রক্সিতে পরিবর্তনগুলি সংরক্ষণ করুন।
যদি সমস্যাটি এখনও থেকে যায়, তাহলে অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন- এ যান।
API পর্যবেক্ষণ ব্যবহার করে সমস্যা নির্ণয় করুন
API মনিটরিং আপনাকে ত্রুটি, কর্মক্ষমতা, এবং লেটেন্সি সমস্যা এবং তাদের উৎস যেমন ডেভেলপার অ্যাপস, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম নির্ণয় করতে সমস্যা এলাকাগুলিকে দ্রুত বিচ্ছিন্ন করতে সক্ষম করে।
এপিআই মনিটরিং ব্যবহার করে আপনার এপিআইগুলির সাথে 5xx সমস্যাগুলি কীভাবে সমাধান করা যায় তা প্রদর্শন করে এমন একটি নমুনা দৃশ্যের মধ্য দিয়ে যান । উদাহরণস্বরূপ, আপনি একটি সতর্কতা সেট আপ করতে চাইতে পারেন যখন messaging.adaptors.http.flow.NoActiveTargets
ফল্টের সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করে তখন বিজ্ঞপ্তি পাওয়ার জন্য।
ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে
উপরের নির্দেশাবলী অনুসরণ করার পরেও যদি সমস্যাটি থেকে যায়, অনুগ্রহ করে নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন। এপিজি সাপোর্টে যোগাযোগ করুন এবং শেয়ার করুন:
- আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:
- প্রতিষ্ঠানের নাম
- পরিবেশের নাম
- API প্রক্সি নাম
- ত্রুটিটি পুনরুত্পাদন করতে কার্ল কমান্ডটি সম্পূর্ণ করুন
- ত্রুটি কোড NoActiveTargets সহ অনুপলব্ধ 503 পরিষেবা সহ অনুরোধগুলি সমন্বিত ট্রেস ফাইল
- আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন তবে নিম্নলিখিত তথ্য প্রদান করুন:
- সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত
- পরিবেশের নাম
- API প্রক্সি বান্ডেল
- ত্রুটি কোড NoActiveTargets সহ অনুপলব্ধ 503 পরিষেবা সহ অনুরোধগুলি সমন্বিত ট্রেস ফাইল
- NGINX অ্যাক্সেস লগ
(
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
) - বার্তা প্রসেসর লগ
(
/opt/apigee/var/log/edge-message-processor/logs/system.log
)