500 অভ্যন্তরীণ সার্ভার সমস্যা

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

ভিডিও

500 ইন্টারনাল সার্ভার এরর সমাধান করার বিষয়ে আরও জানতে নিম্নলিখিত ভিডিওগুলো দেখুন।

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি এপিআই কলের প্রতিক্রিয়া হিসাবে "ইন্টারনাল সার্ভার এরর" বার্তা সহ একটি 500 HTTP স্ট্যাটাস কোড পায়। এই 500 ইন্টারনাল সার্ভার এররটি Edge-এর মধ্যে কোনো পলিসি কার্যকর করার সময় ত্রুটির কারণে অথবা টার্গেট/ব্যাকএন্ড সার্ভারের কোনো ত্রুটির কারণে হতে পারে।

HTTP স্ট্যাটাস কোড 500 হলো একটি সাধারণ ত্রুটিপূর্ণ প্রতিক্রিয়া। এর অর্থ হলো, সার্ভার এমন একটি অপ্রত্যাশিত পরিস্থিতির সম্মুখীন হয়েছে যা অনুরোধটি পূরণ করতে বাধা দিয়েছে। সাধারণত যখন অন্য কোনো ত্রুটি কোড উপযুক্ত হয় না, তখন সার্ভার এই ত্রুটিটি ফেরত দেয়।

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

আপনি নিম্নলিখিত ত্রুটি বার্তাটি পেতে পারেন:

HTTP/1.1 500 Internal Server Error

কিছু ক্ষেত্রে, আপনি অন্য একটি ত্রুটি বার্তা দেখতে পারেন যাতে আরও বিস্তারিত তথ্য থাকে। এখানে একটি নমুনা ত্রুটি বার্তা দেওয়া হলো:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

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

500 ইন্টারনাল সার্ভার এরর বিভিন্ন কারণে দেখা দিতে পারে। Edge-এ, এররটি কোথায় ঘটেছে তার উপর ভিত্তি করে কারণগুলোকে দুটি প্রধান ভাগে ভাগ করা যায়:

একটি এজ পলিসিতে এক্সিকিউশন ত্রুটি

এপিআই প্রক্সির অন্তর্ভুক্ত কোনো পলিসি কোনো কারণে ব্যর্থ হতে পারে। কোনো পলিসি কার্যকর করার সময় 500 ইন্টারনাল সার্ভার এরর দেখা দিলে, কীভাবে সমস্যাটির সমাধান করতে হবে, তা এই অংশে ব্যাখ্যা করা হয়েছে।

রোগ নির্ণয়

প্রাইভেট এবং পাবলিক ক্লাউড ব্যবহারকারীদের জন্য রোগ নির্ণয়ের পদক্ষেপ

যদি আপনার কাছে ত্রুটির ট্রেস UI সেশন থাকে, তাহলে:

1. ত্রুটিটি কোনো পলিসি কার্যকর করার কারণে ঘটেছে কিনা তা যাচাই করুন। বিস্তারিত জানতে ‘সমস্যার উৎস নির্ধারণ’ দেখুন।
2. যদি পলিসি কার্যকর করার সময় ত্রুটিটি ঘটে থাকে, তাহলে চালিয়ে যান। যদি ত্রুটিটি ব্যাকএন্ড সার্ভারের কারণে হয়ে থাকে, তাহলে "ব্যাকএন্ড সার্ভারের ত্রুটি" অংশে যান।
3. ট্রেস থেকে সেই API অনুরোধটি নির্বাচন করুন যেটি 500 ইন্টারনাল সার্ভার এরর-এর কারণে ব্যর্থ হচ্ছে।
4. অনুরোধটি পরীক্ষা করুন এবং ব্যর্থ হওয়া নির্দিষ্ট পলিসিটি অথবা ট্রেস-এ ব্যর্থ পলিসিটির ঠিক পরেই থাকা "Error" নামের ফ্লোটি নির্বাচন করুন।
5. ত্রুটি সম্পর্কে আরও বিস্তারিত জানতে প্রোপার্টিজ সেকশনের অধীনে থাকা 'error' ফিল্ডটি অথবা এরর কন্টেন্ট দেখুন।
6. ত্রুটিটি সম্পর্কে আপনার সংগৃহীত তথ্য ব্যবহার করে এর কারণ নির্ণয় করার চেষ্টা করুন।

শুধুমাত্র প্রাইভেট ক্লাউড ব্যবহারকারীদের জন্য রোগ নির্ণয়ের পদক্ষেপ

যদি আপনার ট্রেস UI সেশন না থাকে, তাহলে:

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

সমাধান

আপনি যদি পলিসি সংক্রান্ত সমস্যার কারণ নির্ণয় করতে পারেন, তবে পলিসিটি সংশোধন করে এবং প্রক্সিটি পুনরায় স্থাপন করে সমস্যাটি সমাধান করার চেষ্টা করুন।

নিম্নলিখিত উদাহরণগুলো বিভিন্ন ধরনের সমস্যার কারণ ও সমাধান নির্ণয়ের পদ্ধতি ব্যাখ্যা করে।

500 Internal Server Error-এর সমস্যা সমাধানে আপনার যদি আরও সহায়তার প্রয়োজন হয় অথবা আপনার সন্দেহ হয় যে এটি Edge-এর অভ্যন্তরীণ কোনো সমস্যা, তাহলে Apigee Support-এর সাথে যোগাযোগ করুন।

উদাহরণ ১: ব্যাকএন্ড সার্ভারে ত্রুটির কারণে সার্ভিস কলআউট পলিসির ব্যর্থতা

সার্ভিস কলআউট পলিসির আওতায় ব্যাকএন্ড সার্ভারে করা কলটি যদি 4XX বা 5XX-এর মতো কোনো ত্রুটির কারণে ব্যর্থ হয়, তাহলে সেটিকে 500 ইন্টারনাল সার্ভার এরর হিসেবে গণ্য করা হবে।

1. এখানে একটি উদাহরণ দেওয়া হলো যেখানে সার্ভিস কলআউট পলিসির অধীনে ব্যাকএন্ড সার্ভিসটি 404 এরর দিয়ে ব্যর্থ হয়। নিম্নলিখিত এরর মেসেজটি এন্ড ইউজারের কাছে পাঠানো হয়:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. নিম্নলিখিত ট্রেস UI সেশনটি সার্ভিস কলআউট পলিসিতে একটি ত্রুটির কারণে সৃষ্ট 500 স্ট্যাটাস কোড দেখাচ্ছে:

   

3. এই উদাহরণে, "error" প্রপার্টিটি সার্ভিস কলআউট পলিসি ব্যর্থ হওয়ার কারণ হিসেবে "ResponseCode 404 is treated as error" উল্লেখ করেছে। সার্ভিস কলআউট পলিসিতে থাকা ব্যাকএন্ড সার্ভার URL-এর মাধ্যমে অ্যাক্সেস করা রিসোর্সটি উপলব্ধ না থাকলে এই ত্রুটিটি ঘটতে পারে।
4. ব্যাকএন্ড সার্ভারে রিসোর্সটির প্রাপ্যতা যাচাই করুন। এটি সাময়িকভাবে/স্থায়ীভাবে অনুপলব্ধ থাকতে পারে অথবা এটিকে অন্য কোনো স্থানে সরিয়ে নেওয়া হয়ে থাকতে পারে।

উদাহরণ ১ সমাধান

1. ব্যাকএন্ড সার্ভারে রিসোর্সটির প্রাপ্যতা যাচাই করুন। এটি সাময়িকভাবে/স্থায়ীভাবে অনুপলব্ধ থাকতে পারে অথবা এটিকে অন্য কোনো স্থানে সরিয়ে নেওয়া হয়ে থাকতে পারে।
2. সার্ভিস কলআউট পলিসিতে ব্যাকএন্ড সার্ভারের URL-টি একটি বৈধ ও বিদ্যমান রিসোর্সের দিকে নির্দেশ করার জন্য সংশোধন করুন।
3. যদি রিসোর্সটি কেবল সাময়িকভাবে অনুপলব্ধ থাকে, তাহলে রিসোর্সটি উপলব্ধ হলে এপিআই অনুরোধটি করার চেষ্টা করুন।

উদাহরণ ২: ভেরিয়েবল নিষ্কাশন নীতিতে ব্যর্থতা

চলুন এবার আরেকটি উদাহরণ দেখি, যেখানে 'Extract Variables' পলিসির একটি ত্রুটির কারণে 500 Internal Server Error দেখা দিয়েছে এবং সমস্যাটি কীভাবে সমাধান করা যায় তা জেনে নিই।

1. UI সেশনের নিম্নলিখিত ট্রেসটি 'Extract Variables' পলিসিতে একটি ত্রুটির কারণে 500 স্ট্যাটাস কোড দেখাচ্ছে:

   

2. ব্যর্থ হওয়া এক্সট্র্যাক্ট ভ্যারিয়েবলস পলিসিটি নির্বাচন করুন, নিচে স্ক্রল করুন এবং আরও বিস্তারিত তথ্যের জন্য "এরর কন্টেন্ট" সেকশনটি দেখুন:
   
   
3. এরর কন্টেন্ট থেকে বোঝা যাচ্ছে যে 'serviceCallout.oamCookieValidationResponse' ভেরিয়েবলটি এক্সট্র্যাক্ট ভেরিয়েবলস পলিসিতে উপলব্ধ নেই। ভেরিয়েবলটির নাম থেকেই বোঝা যায়, এটিতে পূর্ববর্তী সার্ভিস কলআউট পলিসির রেসপন্স থাকার কথা।
4. ট্রেস-এ সার্ভিস কলআউট পলিসিটি নির্বাচন করলে আপনি দেখতে পারেন যে " serviceCallout.oamCookieValidationResponse " ভেরিয়েবলটি সেট করা হয়নি। এর অর্থ হলো, ব্যাকএন্ড সার্ভিসে করা কলটি ব্যর্থ হয়েছে, যার ফলে রেসপন্স ভেরিয়েবলটি খালি হয়ে গেছে।
5. যদিও সার্ভিস কলআউট পলিসিটি ব্যর্থ হয়েছে, সার্ভিস কলআউট পলিসির পরবর্তী পলিসিগুলোর এক্সিকিউশন চলতে থাকে, কারণ সার্ভিস কলআউট পলিসিতে থাকা "continueOnError" ফ্ল্যাগটি 'true' সেট করা আছে, যেমনটি নিচে দেখানো হয়েছে:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. ট্রেস থেকে এই নির্দিষ্ট API অনুরোধটির জন্য অনন্য মেসেজ আইডি "X-Apigee.Message-ID" নোট করুন, যা নিম্নরূপ:
   1. অনুরোধ থেকে 'অ্যানালিটিক্স ডেটা রেকর্ড করা হয়েছে' পর্যায়টি নির্বাচন করুন।
   2. নিচে স্ক্রল করুন এবং X-Apigee.Message-ID-এর মানটি লক্ষ্য করুন।

   

7. মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/system.log ) দেখুন এবং ধাপ #৬-এ টুকে রাখা অনন্য মেসেজ আইডিটি খুঁজুন। নির্দিষ্ট API অনুরোধটির জন্য নিম্নলিখিত ত্রুটি বার্তাটি দেখা গেছে:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

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

8. কানেকশন টাইমআউট ত্রুটির কারণ নির্ণয় করতে, মেসেজ প্রসেসর(গুলি) থেকে ব্যাকএন্ড সার্ভারে টেলনেট কমান্ডটি চালানো হয়েছিল। টেলনেট কমান্ডটি নিচে দেখানো অনুযায়ী "কানেকশন টাইমড আউট" ত্রুটি দেখিয়েছে:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

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

   • যখন ব্যাকএন্ড সার্ভারটি এজ মেসেজ প্রসেসরগুলো থেকে আসা ট্র্যাফিকের অনুমতি দেওয়ার জন্য কনফিগার করা থাকে না।
   • যদি ব্যাকএন্ড সার্ভারটি নির্দিষ্ট পোর্টে লিসেন না করে।

   উপরে বর্ণিত উদাহরণে, যদিও ‘এক্সট্র্যাক্ট ভ্যারিয়েবলস’ পলিসিটি ব্যর্থ হয়েছিল, আসল কারণ ছিল যে ‘সার্ভিস কলআউট’ পলিসিতে থাকা ব্যাকএন্ড সার্ভারের সাথে Edge সংযোগ স্থাপন করতে পারছিল না। আর এই ব্যর্থতার কারণ ছিল যে, ব্যাকএন্ড সার্ভারটি Edge মেসেজ প্রসেসরগুলো থেকে আসা ট্র্যাফিককে অনুমতি দেওয়ার জন্য কনফিগার করা ছিল না।

   আপনার নিজস্ব এক্সট্র্যাক্ট ভ্যারিয়েবলস পলিসি ভিন্নভাবে কাজ করবে এবং ভিন্ন কারণে ব্যর্থ হতে পারে। এরর প্রপার্টিতে থাকা মেসেজটি পরীক্ষা করে আপনি আপনার এক্সট্র্যাক্ট ভ্যারিয়েবলস পলিসির ব্যর্থতার কারণের উপর নির্ভর করে সমস্যাটির যথাযথ সমাধান করতে পারেন।

উদাহরণ ২ সমাধান

1. এক্সট্র্যাক্ট ভ্যারিয়েবলস পলিসিতে ত্রুটি বা ব্যর্থতার কারণটি যথাযথভাবে সমাধান করুন।
2. উপরে চিত্রিত উদাহরণে, সমাধানটি ছিল এজ মেসেজ প্রসেসর থেকে আপনার ব্যাকএন্ড সার্ভারে ট্র্যাফিকের অনুমতি দেওয়ার জন্য নেটওয়ার্ক কনফিগারেশন সংশোধন করা। এটি নির্দিষ্ট ব্যাকএন্ড সার্ভারে মেসেজ প্রসেসরগুলোর আইপি অ্যাড্রেসগুলোকে allowlist করার মাধ্যমে করা হয়েছিল। উদাহরণস্বরূপ, লিনাক্সে, আপনি ব্যাকএন্ড সার্ভারে মেসেজ প্রসেসরের আইপি অ্যাড্রেসগুলো থেকে আসা ট্র্যাফিকের অনুমতি দেওয়ার জন্য iptables ব্যবহার করতে পারেন।

উদাহরণ ৩: JavaCallout পলিসিতে ব্যর্থতা

চলুন এখন আরও একটি উদাহরণ দেখি, যেখানে জাভা কলআউট পলিসির একটি ত্রুটির কারণে 500 ইন্টারনাল সার্ভার এরর দেখা দিয়েছে এবং দেখি কীভাবে সমস্যাটির ট্রাবলশুটিং ও সমাধান করা যায়।

1. নিম্নলিখিত UI ট্রেসটি জাভা কলআউট পলিসিতে একটি ত্রুটির কারণে 500 স্ট্যাটাস কোড দেখাচ্ছে:

   

2. নিচের চিত্রে দেখানো অনুযায়ী ত্রুটির বিবরণ পেতে, "Error" নামের ফ্লো-টি নির্বাচন করুন এবং তারপরে ব্যর্থ জাভা কলআউট পলিসিটি নির্বাচন করুন:

   

3. এই উদাহরণে, Properties সেকশনের অধীনে থাকা "error" প্রপার্টিটি থেকে বোঝা যায় যে, JavaCallout পলিসির ভেতর থেকে Oracle Database-এ সংযোগ করার সময় মেয়াদোত্তীর্ণ পাসওয়ার্ড ব্যবহার করার কারণে এই ব্যর্থতা ঘটেছে। আপনার নিজের Java callout-এর আচরণ ভিন্ন হবে এবং error প্রপার্টিতে একটি ভিন্ন বার্তা প্রদর্শিত হবে।
4. JavaCallout পলিসি কোডটি পরীক্ষা করুন এবং ব্যবহারযোগ্য সঠিক কনফিগারেশনটি নিশ্চিত করুন।

উদাহরণ ৩ সমাধান

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

ব্যাকএন্ড সার্ভারে ত্রুটি

একটি 500 ইন্টারনাল সার্ভার এরর ব্যাকএন্ড সার্ভার থেকেও আসতে পারে। যদি এররটি ব্যাকএন্ড সার্ভার থেকে আসে, তবে সমস্যাটি কীভাবে সমাধান করতে হবে তা এই অংশে ব্যাখ্যা করা হয়েছে।

রোগ নির্ণয়

সকল ব্যবহারকারীর জন্য রোগ নির্ণয়ের পদক্ষেপ

অন্যান্য ব্যাকএন্ড ত্রুটির কারণ ব্যাপকভাবে ভিন্ন হতে পারে। আপনাকে প্রতিটি পরিস্থিতি আলাদাভাবে নির্ণয় করতে হবে।

1. ত্রুটিটি ব্যাকএন্ড সার্ভারের কারণে হয়েছে কিনা তা যাচাই করুন। বিস্তারিত জানতে ‘সমস্যার উৎস নির্ধারণ’ দেখুন।
2. যদি ত্রুটিটি ব্যাকএন্ড সার্ভারের কারণে হয়ে থাকে, তবে চালিয়ে যান। যদি ত্রুটিটি পলিসি কার্যকর করার সময় ঘটে থাকে, তাহলে Edge Policy-এর Execution Error- এ যান।
3. ব্যর্থ হওয়া API-টির জন্য আপনার কাছে ট্রেস সেশন অ্যাক্সেস আছে কি না, অথবা ব্যাকএন্ডটি একটি Node.js সার্ভার কি না, তার উপর নির্ভর করে নিচের ধাপগুলো অনুসরণ করুন:

ব্যর্থ API কলটির জন্য যদি আপনার কোনো ট্রেস সেশন না থাকে :

1. ব্যর্থ হওয়া অনুরোধটির জন্য যদি UI ট্রেস পাওয়া না যায়, তাহলে ত্রুটি সম্পর্কে বিস্তারিত জানতে ব্যাকএন্ড সার্ভার লগ পরীক্ষা করুন।
2. সম্ভব হলে, ত্রুটি এবং এর কারণ সম্পর্কে আরও বিস্তারিত জানতে ব্যাকএন্ড সার্ভারে ডিবাগ মোড চালু করুন।

ব্যর্থ API কলটির জন্য যদি আপনার কাছে একটি ট্রেস সেশন থাকে :

আপনার যদি একটি ট্রেস সেশন থাকে, তাহলে নিম্নলিখিত ধাপগুলো আপনাকে সমস্যাটি নির্ণয় করতে সাহায্য করবে।

1. ট্রেস টুলে, 500 ইন্টারনাল সার্ভার এরর-এর কারণে ব্যর্থ হওয়া API রিকোয়েস্টটি সিলেক্ট করুন।
2. নিচের চিত্রে দেখানো অনুযায়ী, ব্যর্থ হওয়া এপিআই অনুরোধটি থেকে "টার্গেট সার্ভার থেকে প্রাপ্ত প্রতিক্রিয়া" পর্যায়টি নির্বাচন করুন:

   

3. ত্রুটি সম্পর্কে বিস্তারিত জানতে "Response Content" বিভাগটি দেখুন।

   

4. এই উদাহরণে, রেসপন্স কন্টেন্ট (যা একটি SOAP এনভেলপ), "Not Authorized" মেসেজটি ফল্ট স্ট্রিং হিসেবে দেখাচ্ছে । এই সমস্যার সবচেয়ে সম্ভাব্য কারণ হলো, ব্যবহারকারী ব্যাকএন্ড সার্ভারে সঠিক ক্রেডেনশিয়াল (ইউজারনেম/পাসওয়ার্ড, অ্যাক্সেস টোকেন, ইত্যাদি) পাঠাননি। ব্যাকএন্ড সার্ভারে সঠিক ক্রেডেনশিয়াল পাঠানোর মাধ্যমে এই সমস্যাটি সমাধান করা যেতে পারে।

যদি ব্যাকএন্ডটি একটি Node.js সার্ভার হয়:

1. যদি ব্যাকএন্ডটি একটি Node.js ব্যাকএন্ড সার্ভার হয়, তাহলে Edge UI-তে নির্দিষ্ট API প্রক্সির জন্য Node.js লগগুলি পরীক্ষা করুন ( পাবলিক এবং প্রাইভেট ক্লাউড উভয় ব্যবহারকারীই Node.js লগগুলি পরীক্ষা করতে পারেন )। আপনি যদি একজন Edge প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে ত্রুটি সম্পর্কে আরও বিস্তারিত জানতে আপনার মেসেজ প্রসেসর লগগুলিও ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) পরীক্ষা করতে পারেন।
   
   

   Edge UI-এর API Proxy-এর Overview ট্যাবে NodeJS Logs অপশন

   

সমাধান

1. ত্রুটির কারণ শনাক্ত করার পর, আপনার ব্যাকএন্ড সার্ভারে সমস্যাটি সমাধান করুন।
2. যদি এটি একটি Node.js ব্যাকএন্ড সার্ভার হয়:
   1. ত্রুটিটি আপনার কাস্টম কোড থেকে আসছে কিনা তা পরীক্ষা করুন এবং সম্ভব হলে সমস্যাটি সমাধান করুন।
   2. যদি ত্রুটিটি আপনার কাস্টম কোড থেকে না আসে অথবা আপনার সাহায্যের প্রয়োজন হয়, তাহলে Apigee Support-এর সাথে যোগাযোগ করুন।

500 Internal Server Error-এর সমস্যা সমাধানে আপনার যদি আরও সহায়তার প্রয়োজন হয় অথবা আপনার সন্দেহ হয় যে এটি Edge-এর অভ্যন্তরীণ কোনো সমস্যা, তাহলে Apigee Support-এর সাথে যোগাযোগ করুন।

সমস্যার উৎস নির্ধারণ করা

500 ইন্টারনাল সার্ভার এররটি এপিআই প্রক্সির মধ্যে কোনো পলিসি কার্যকর করার সময় নাকি ব্যাকএন্ড সার্ভার দ্বারা উদ্ভূত হয়েছে, তা নির্ধারণ করতে নিম্নলিখিত পদ্ধতিগুলোর মধ্যে একটি ব্যবহার করুন।

UI-তে ট্রেস ব্যবহার করা

দ্রষ্টব্য: এই বিভাগের ধাপগুলো পাবলিক এবং প্রাইভেট ক্লাউড উভয় ব্যবহারকারীই সম্পাদন করতে পারবেন।

1. যদি সমস্যাটি এখনও সক্রিয় থাকে, তাহলে প্রভাবিত API-টির জন্য UI-তে ট্রেস চালু করুন।
2. একবার ট্রেসটি ক্যাপচার করা হয়ে গেলে, সেই API অনুরোধটি নির্বাচন করুন যেটির প্রতিক্রিয়া কোড 500 দেখাচ্ছে।
3. ব্যর্থ হওয়া এপিআই অনুরোধের সমস্ত ধাপগুলো অতিক্রম করুন এবং পরীক্ষা করে দেখুন কোন ধাপে 500 ইন্টারনাল সার্ভার এরর (500 Internal Server Error) আসছে:
   1. যদি কোনো পলিসি কার্যকর করার সময় ত্রুটি দেখা দেয়, তাহলে "এজ পলিসিতে কার্যকর করার ত্রুটি" অংশে যান।
   2. যদি ব্যাকএন্ড সার্ভার 500 Internal Server কোড দিয়ে সাড়া দেয়, তাহলে "ব্যাকএন্ড সার্ভারের ত্রুটি" অংশে যান।

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

দ্রষ্টব্য: এই বিভাগের ধাপগুলো শুধুমাত্র পাবলিক ক্লাউড ব্যবহারকারীরাই সম্পাদন করতে পারবেন।

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

এপিআই মনিটরিং ব্যবহার করে আপনার এপিআই-এর 5xx সমস্যাগুলো কীভাবে সমাধান করবেন, তা দেখানোর জন্য একটি নমুনা সিনারিও ধাপে ধাপে অনুসরণ করুন । উদাহরণস্বরূপ, আপনি হয়তো এমন একটি অ্যালার্ট সেট আপ করতে চাইতে পারেন, যার মাধ্যমে 500 স্ট্যাটাস কোড বা steps.servicecallout.ExecutionFailed ফল্টের সংখ্যা একটি নির্দিষ্ট সীমা অতিক্রম করলে আপনাকে জানানো হবে।

NGINX অ্যাক্সেস লগ ব্যবহার করে

দ্রষ্টব্য: এই বিভাগের ধাপগুলো শুধুমাত্র এজ প্রাইভেট ক্লাউড ব্যবহারকারীদের জন্য প্রযোজ্য।

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

1. NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন ( /opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log )।
2. নির্দিষ্ট সময়কালে নির্দিষ্ট এপিআই প্রক্সির জন্য কোনো 500 এরর আছে কিনা তা অনুসন্ধান করুন।
3. যদি কোনো 500 Error থাকে, তাহলে নিচে দেখানো অনুযায়ী পরীক্ষা করে দেখুন যে ত্রুটিটি পলিসি জনিত নাকি টার্গেট সার্ভার জনিত।

   পলিসি ত্রুটি প্রদর্শনকারী একটি নমুনা এন্ট্রি।

   

   টার্গেট সার্ভার ত্রুটি প্রদর্শনকারী একটি নমুনা এন্ট্রি।

   

4. একবার আপনি শনাক্ত করে ফেললে যে এটি পলিসি ত্রুটি নাকি টার্গেট সার্ভার ত্রুটি:
   1. কোনো এজ পলিসিতে পলিসি ত্রুটি থাকলে, সেটির এক্সিকিউশন এরর (Execution Error) অনুসরণ করুন।
   2. যদি এটি টার্গেট সার্ভারের ত্রুটি হয়, তবে ব্যাকএন্ড সার্ভারের ত্রুটি বিভাগে যান।