এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

500 অভ্যন্তরীণ সার্ভার ত্রুটি - স্ট্রিমিং সক্ষম হয়েছে৷

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

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি এপিআই কলগুলির জন্য 'ইন্টারনাল সার্ভার এরর' বার্তা সহ একটি HTTP প্রতিক্রিয়া স্ট্যাটাস কোড 500 পায়।

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

ক্লায়েন্ট অ্যাপ্লিকেশনগুলি নীচে দেখানো ত্রুটিপূর্ণ প্রতিক্রিয়া পেতে পারে:

HTTP/1.1 500 Internal Server Error

এর পরে এই ধরনের একটি ত্রুটি বার্তা আসতে পারে:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

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

500 ইন্টারনাল সার্ভার এরর বিভিন্ন কারণে ঘটতে পারে। এই প্লেবুকটি স্ট্রিমিং চালু থাকা অবস্থায় রিকোয়েস্ট/রেসপন্স পেলোড অ্যাক্সেস করার কারণে সৃষ্ট 500 ইন্টারনাল সার্ভার এররের উপর আলোকপাত করে।

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

কারণ: স্ট্রিমিং চালু থাকা অবস্থায় পেলোড অ্যাক্সেস করা

রোগ নির্ণয়

পদ্ধতি #১: ট্রেস ব্যবহার করা

ট্রেস সেশনটি চালু করুন এবং সমস্যাটি পুনরুৎপাদন করতে এপিআই কলটি করুন - ৫০০ ইন্টারনাল সার্ভার এরর।
ব্যর্থ হওয়া অনুরোধগুলোর মধ্যে একটি নির্বাচন করুন এবং ট্রেসটি পরীক্ষা করুন।
অনুসন্ধানের বিভিন্ন ধাপ অতিক্রম করে ত্রুটিটি কোথায় ঘটেছে তা খুঁজে বের করুন।
কোনো পলিসি অনুরোধ/প্রতিক্রিয়া পেলোড পার্স করার সময় এই ত্রুটিটি ঘটে থাকতে পারে।
এখানে JSONThreatProtection পলিসিটি দেখানো একটি নমুনা ট্রেস স্ক্রিনশট দেওয়া হলো। "লাইন ১-এ } প্রত্যাশিত" ত্রুটির কারণে ব্যর্থ হচ্ছে:
উপরের স্ক্রিনশটে দেখানো ট্রেস আউটপুট থেকে নিম্নলিখিত তথ্যগুলো নোট করে নিন:
ব্যর্থ নীতি: JSONThreatProtection
প্রবাহ: প্রক্সি অনুরোধ
ব্যর্থ হওয়া পলিসি সংজ্ঞাটি পরীক্ষা করুন এবং যে পেলোডটি পার্স করা হচ্ছে তা যাচাই করুন।
উদাহরণ পরিস্থিতিতে, ব্যর্থ হওয়া JSON-Threat-Protection নামের JSONThreatProtection পলিসিটি পরীক্ষা করুন এবং <Source> এলিমেন্টটি যাচাই করুন।
```
<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>
```
লক্ষ্য করুন যে <Source> এলিমেন্টটি request. এর মানে হলো, request payload পার্স করার সময় ত্রুটিটি ঘটেছে।
এপিআই অনুরোধটি যাচাই করে পার্স করা পেলোডের ধরন নির্ধারণ করুন।

আপনি এপিআই অনুরোধের রিকোয়েস্ট পেলোড এবং Content-Type হেডারের বিষয়বস্তু পরীক্ষা করতে পারেন। নিচের উদাহরণ কার্ল (curl) কমান্ডে একটি JSON পেলোড ব্যবহার করা হয়েছে।

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

আপনি ব্যর্থ হওয়া পলিসিটিও পরীক্ষা করে দেখতে পারেন এবং পার্স করা পেলোডের ধরন নির্ধারণ করতে পারেন। উপরের উদাহরণ পরিস্থিতিতে, JSON-Threat-Protection পলিসিটি ব্যর্থ হচ্ছে। এটি নির্দেশ করে যে পেলোডটি অবশ্যই JSON ফরম্যাটে হতে হবে।

পেলোডটি সঠিক ফরম্যাটে আছে কিনা তা যাচাই করুন। পেলোডটি বৈধ না হলে আপনি এই ত্রুটিটি পেতে পারেন।
দ্রষ্টব্য: পেলোডটি বড় হলে, আপনি যেকোনো অনলাইন ফরম্যাটার ব্যবহার করে এর ফরম্যাট যাচাই করে নিতে পারেন।
যদি পেলোডটি বৈধ হয়, কিন্তু তারপরেও আপনি 'ত্রুটির বার্তা' বিভাগে তালিকাভুক্ত ত্রুটিগুলি পান, তাহলে এই ত্রুটিগুলির কারণ হলো স্ট্রিমিং সক্রিয় থাকা অবস্থায় পেলোডটি অ্যাক্সেস করা হচ্ছে।
পলিসি দ্বারা পার্স করা পেলোডের উপর নির্ভর করে (যা ধাপ #৬-এ নির্ধারিত হয়েছে), উপযুক্ত পর্যায়ে ট্রেস টুলে পেলোডের বিষয়বস্তু পরীক্ষা করুন।
উদাহরণ পরিস্থিতিতে, অনুরোধের পেলোডটি পার্স করা হচ্ছে, তাই ট্রেস-এর "ক্লায়েন্টের কাছ থেকে অনুরোধ প্রাপ্ত" পর্যায়টি পরীক্ষা করুন এবং অনুরোধের বিষয়বস্তু যাচাই করুন।
উপরের স্ক্রিনশটে দেখানো অনুযায়ী, আপনি একটি বৈধ পেলোড পাঠানোর পরেও যদি রিকোয়েস্ট কন্টেন্ট খালি পাওয়া যায়, তাহলে এটি নির্দেশ করে যে এই সমস্যার সম্ভাব্য কারণ হলো রিকোয়েস্ট স্ট্রিমিং চালু থাকা।
এর কারণ হলো, যখন স্ট্রিমিং চালু থাকে, তখন রিকোয়েস্ট পেলোড ট্রেসে দেখা যায় না।
একইভাবে, ত্রুটি ঘটার সময় যদি রেসপন্স পেলোড পার্স করা হয়, তাহলে "টার্গেট সার্ভার থেকে প্রাপ্ত রেসপন্স" পর্যায়ে রেসপন্সের বিষয়বস্তু পরীক্ষা করুন।
এরপরে, এপিআই প্রক্সি ফ্লোতে ব্যর্থ পলিসিটি কোথায় ব্যবহৃত হচ্ছে তার উপর নির্ভর করে প্রক্সি এবং টার্গেট এন্ডপয়েন্ট ডেফিনিশনগুলো পরীক্ষা করুন। স্ট্রিমিং সক্রিয় করা হয়েছে কিনা তা যাচাই করুন।
উদাহরণ পরিস্থিতিতে, ব্যর্থ পলিসিটি প্রক্সি রিকোয়েস্ট ফ্লো-তে কার্যকর করা হয়েছিল (যেমনটি উপরের ধাপ #৫-এ নির্ধারণ করা হয়েছে); অতএব, প্রক্সি এন্ডপয়েন্টটি পরীক্ষা করুন:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
উপরের উদাহরণে যেমন দেখা যাচ্ছে, " request.streaming.enabled" প্রপার্টিটির মান 'true' সেট করার মাধ্যমে রিকোয়েস্ট স্ট্রিমিং সক্রিয় করা হয়েছে।
সুতরাং, ত্রুটির কারণ হলো স্ট্রিমিং চালু থাকা অবস্থায় রিকোয়েস্ট পেলোড অ্যাক্সেসকারী এপিআই প্রক্সিতে JSONThreatProtection পলিসি ব্যবহার করা। এর ফলে ত্রুটি ঘটে, কারণ এটি এপিআই প্রক্সিতে বাফারিং চালু করে এবং Apigee Edge-এ স্ট্রিমিং ব্যবহারের উদ্দেশ্যকে ব্যর্থ করে দেয়।
ছোট পেলোডের ক্ষেত্রে এই ত্রুটি দেখা নাও যেতে পারে, কিন্তু বড় পেলোড ব্যবহার করলে এই ত্রুটিগুলো দেখা যেতে পারে।
নিচে দেওয়া ধাপগুলো অনুসরণ করে ট্রেসের "AX" (অ্যানালিটিক্স ডেটা রেকর্ডেড) ফেজে "X-Apigee-fault-source"- এর মান পরীক্ষা করার মাধ্যমে আপনি যাচাই করতে পারেন যে ৫০০ এররটি পলিসির কারণেই ঘটছে:
1. নিচের স্ক্রিনশটে দেখানো অনুযায়ী " AX " (অ্যানালিটিক্স ডেটা রেকর্ড করা) পর্যায়ে ক্লিক করুন:
2. ফেজ ডিটেইলস-এর নিচে স্ক্রল করে 'এরর হেডারস' সেকশনে যান এবং নিচে দেখানো অনুযায়ী 'X-Apigee-fault-code' , 'X-Apigee-fault-source' এবং 'X-Apigee-fault-policy'- এর মান নির্ধারণ করুন:
3. উপরের ছবিতে দেখানো অনুযায়ী যদি "X-Apigee-fault-source"- এর মান "policy" হয়, তাহলে এটি নির্দেশ করে যে স্ট্রিমিং চালু থাকা অবস্থায় পলিসি পেলোড অ্যাক্সেস করার কারণে ত্রুটিটি ঘটেছে।

সমাধান

স্ট্রিমিং চালু থাকা অবস্থায় পেলোড অ্যাক্সেস করা একটি অ্যান্টিপ্যাটার্ন, যেমনটি "অ্যান্টিপ্যাটার্ন: স্ট্রিমিং চালু থাকা অবস্থায় রিকোয়েস্ট/রেসপন্স পেলোড অ্যাক্সেস করা" শীর্ষক লেখায় ব্যাখ্যা করা হয়েছে।

আপনি যদি পেলোডটি প্রসেস করতে চান, তাহলে নিচের উদাহরণ ProxyEndpoint-এ দেখানো অনুযায়ী Proxy/Target Endpoint থেকে " request.streaming.enabled" and " response.streaming.enabled" প্রপার্টিগুলো মুছে দিয়ে স্ট্রিমিং নিষ্ক্রিয় করতে হবে:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
অথবা
আপনি যদি আপনার এপিআই প্রক্সিতে স্ট্রিমিং ব্যবহার করতে চান, তাহলে এপিআই প্রক্সিতে এমন কোনো পলিসি ব্যবহার করবেন না যা রিকোয়েস্ট/রেসপন্স পেলোড অ্যাক্সেস করে।

দ্রষ্টব্য:

এই প্লেবুকে, উদাহরণ সিনারিওতে স্ট্রিমিং সক্রিয় রেখে রিকোয়েস্ট পেলোড প্রসেস করার জন্য JSONThreatProtection পলিসি ব্যবহার করা হয়েছিল। এর ফলে বিভিন্ন ত্রুটিসহ 500 Internal Server Error দেখা দেয়।
JSONToXML এবং XMLToJSON-এর মতো পলিসিগুলোর ক্ষেত্রেও এই ত্রুটিগুলো দেখা যেতে পারে, যেগুলো স্ট্রিমিং চালু থাকলে রিকোয়েস্ট বা রেসপন্স পেলোড প্রসেস করে।
স্ট্রিমিং চালু থাকা অবস্থায় যেসব প্রক্সির পেলোড অ্যাক্সেসের প্রয়োজন হয়, সেগুলিতে এই ধরনের কোনো পলিসি ব্যবহার না করার জন্য আমরা দৃঢ়ভাবে সুপারিশ করছি।
এমনটা করা একটি অ্যান্টিপ্যাটার্ন, যেমনটি "অ্যান্টিপ্যাটার্ন: স্ট্রিমিং সক্রিয় থাকাকালীন অনুরোধ/প্রতিক্রিয়া পেলোড অ্যাক্সেস করুন" শীর্ষক লেখায় নথিভুক্ত করা হয়েছে।

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

আপনি যদি প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে এই পদ্ধতিটি অনুসরণ করার প্রয়োজন নেই।

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

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

পলিসি থেকে 500 এরর রেসপন্স এলে যদি আপনি নোটিফিকেশন পেতে চান, তাহলে আপনাকে ফল্ট সোর্স হিসেবে প্রক্সি সহ 500 স্ট্যাটাস কোডের জন্য অ্যালার্ট সেট আপ করতে হবে।

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

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

আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:

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

আপনি যদি প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিত তথ্য প্রদান করুন:

ব্যর্থ অনুরোধগুলির জন্য সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে।
সংস্থা, পরিবেশের নাম এবং এপিআই প্রক্সির নাম, যেগুলোর জন্য আপনি 500 ত্রুটি দেখতে পাচ্ছেন
এপিআই প্রক্সি বান্ডেল
অনুরোধে ব্যবহৃত পেলোড (যদি থাকে)
500 ইন্টারনাল সার্ভার এরর সহ অনুরোধগুলি ধারণকারী ট্রেস ফাইল
NGINX অ্যাক্সেস লগ ( /opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log )
মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log )
টাইমজোন তথ্যসহ সেই সময়কাল, যখন ৫০০ ত্রুটিগুলো ঘটেছিল।