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

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

ভিডিও

500টি অভ্যন্তরীণ সার্ভার ত্রুটি সমাধান সম্পর্কে আরও জানতে নিম্নলিখিত ভিডিওগুলি দেখুন৷

উপসর্গ

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

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 অভ্যন্তরীণ সার্ভার ত্রুটি বিভিন্ন কারণে নিক্ষিপ্ত হতে পারে। এজ-এ, যেখানে ত্রুটি ঘটেছে তার উপর ভিত্তি করে কারণগুলিকে দুটি প্রধান বিভাগে শ্রেণীবদ্ধ করা যেতে পারে:

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

API প্রক্সির মধ্যে একটি নীতি কোনো কারণে ব্যর্থ হতে পারে। এই বিভাগটি ব্যাখ্যা করে যে কীভাবে কোনও নীতি কার্যকর করার সময় 500 অভ্যন্তরীণ সার্ভার ত্রুটি দেখা দিলে সমস্যাটির সমাধান করা যায়।

রোগ নির্ণয়

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

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

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

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

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

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

রেজোলিউশন

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

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

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

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

যদি ব্যাকএন্ড সার্ভারে কলটি পরিষেবা কলআউট নীতির মধ্যে 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. এই উদাহরণে, "ত্রুটি" বৈশিষ্ট্যটি পরিষেবা কলআউট নীতি ব্যর্থতার কারণটিকে "ResponseCode 404 কে ত্রুটি হিসাবে বিবেচনা করা হয়" হিসাবে তালিকাভুক্ত করে৷ পরিষেবা কলআউট নীতিতে ব্যাকএন্ড সার্ভার URL-এর মাধ্যমে রিসোর্স অ্যাক্সেস করা না থাকলে এই ত্রুটি ঘটতে পারে৷
4. ব্যাকএন্ড সার্ভারে সম্পদের প্রাপ্যতা পরীক্ষা করুন। এটি সাময়িক/স্থায়ীভাবে উপলব্ধ নাও হতে পারে বা এটি অন্য জায়গায় স্থানান্তরিত হতে পারে।

উদাহরণ 1 রেজোলিউশন

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

উদাহরণ 2: এক্সট্র্যাক্ট ভেরিয়েবল নীতিতে ব্যর্থতা

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

1. এক্সট্র্যাক্ট ভেরিয়েবল নীতিতে একটি ত্রুটির কারণে UI সেশনে নিম্নলিখিত ট্রেসটি 500 স্ট্যাটাস কোড দেখায়:

   

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

   <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 ) দেখুন এবং ধাপ #6 এ উল্লেখিত অনন্য বার্তা আইডি অনুসন্ধান করুন। নির্দিষ্ট 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

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

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

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

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

উদাহরণ 2 রেজোলিউশন

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

উদাহরণ 3: JavaCallout নীতিতে ব্যর্থতা

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

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

   

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

   

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

উদাহরণ 3 রেজোলিউশন

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

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

একটি 500 অভ্যন্তরীণ সার্ভার ত্রুটিও ব্যাকএন্ড সার্ভার থেকে উদ্ভূত হতে পারে। ব্যাকএন্ড সার্ভার থেকে যদি ত্রুটিটি আসে তবে এই বিভাগটি ব্যাখ্যা করে যে কীভাবে সমস্যাটি সমাধান করা যায়।

রোগ নির্ণয়

সমস্ত ব্যবহারকারীর জন্য ডায়গনিস্টিক পদক্ষেপ

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

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

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

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

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

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

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

   

3. ত্রুটি সম্পর্কে বিশদ পেতে "প্রতিক্রিয়া সামগ্রী" বিভাগটি পরীক্ষা করুন৷

   

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

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

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

   এজ UI-তে NodeJS Logs বিকল্প - API প্রক্সির ওভারভিউ ট্যাবে

   

রেজোলিউশন

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

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

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

API প্রক্সির মধ্যে বা ব্যাকএন্ড সার্ভারের দ্বারা একটি নীতি কার্যকর করার সময় 500 অভ্যন্তরীণ সার্ভার ত্রুটি নিক্ষেপ করা হয়েছিল কিনা তা নির্ধারণ করতে নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটি ব্যবহার করুন৷

UI এ ট্রেস ব্যবহার করা

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

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

API মনিটরিং ব্যবহার করে

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

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

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

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

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

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

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

   নমুনা এন্ট্রি একটি নীতি ত্রুটি দেখাচ্ছে

   

   একটি টার্গেট সার্ভার ত্রুটি দেখাচ্ছে নমুনা এন্ট্রি

   

4. এটি একটি নীতি বা লক্ষ্য সার্ভার ত্রুটি কিনা তা আপনি চিহ্নিত করার পরে:
   1. একটি এজ পলিসিতে এক্সিকিউশন ত্রুটিতে এগিয়ে যান যদি এটি একটি নীতি ত্রুটি হয়।
   2. ব্যাকএন্ড সার্ভারে ত্রুটিতে এগিয়ে যান যদি এটি একটি লক্ষ্য সার্ভার ত্রুটি হয়।