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

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

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি API কলগুলির জন্য অভ্যন্তরীণ সার্ভার ত্রুটি বার্তা সহ একটি 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টি অভ্যন্তরীণ সার্ভার ত্রুটির উপর ফোকাস করে৷

কারণ: স্ট্রিমিং সক্ষম সহ পেলোড অ্যাক্সেস করা

রোগ নির্ণয়

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

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

   

   উপরের স্ক্রিনশটে দেখানো হিসাবে ট্রেস আউটপুট থেকে নিম্নলিখিত তথ্যের একটি নোট করুন:
   

   ব্যর্থ নীতি: JSONThreatProtection

   প্রবাহ: প্রক্সি অনুরোধ

6. ব্যর্থ নীতি সংজ্ঞা পরীক্ষা করুন এবং পার্স করা হচ্ছে পেলোড পরীক্ষা করুন.

   উদাহরণের ক্ষেত্রে, 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. এর মানে হল অনুরোধ পেলোড পার্স করার সময় ত্রুটি ঘটেছে।

7. API অনুরোধ চেক করে পার্স করা হচ্ছে পেলোডের ধরন নির্ধারণ করুন।

আপনি API অনুরোধে অনুরোধের পেলোড এবং Content-Type শিরোনামের বিষয়বস্তু পরীক্ষা করতে পারেন। নিম্নলিখিত উদাহরণে কার্ল কমান্ড, একটি JSON পেলোড ব্যবহার করা হয়।

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

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

8. পেলোড সঠিক বিন্যাসে হলে যাচাই করুন। যদি পেলোড বৈধ না হয়, তাহলে আপনি এই ত্রুটি পেতে পারেন।

9. যদি পেলোডটি বৈধ হয়, কিন্তু আপনি এখনও ত্রুটি বার্তা বিভাগে তালিকাভুক্ত ত্রুটিগুলি পেয়ে থাকেন, তাহলে এই ত্রুটিগুলির কারণ হল যে স্ট্রিমিং সক্ষম করার সময় পেলোডটি অ্যাক্সেস করা হচ্ছে৷

   পলিসি দ্বারা পার্স করা পেলোডের উপর নির্ভর করে (ধাপ #6 এ নির্ধারিত), উপযুক্ত পর্যায়ে ট্রেস টুলে পেলোড সামগ্রী পরীক্ষা করুন।

   উদাহরণের পরিস্থিতিতে, অনুরোধ পেলোড পার্স করা হচ্ছে, তাই ট্রেসে "ক্লায়েন্টের কাছ থেকে প্রাপ্ত অনুরোধ" পর্বটি পরীক্ষা করুন এবং অনুরোধের বিষয়বস্তু পরীক্ষা করুন।

   

   যদি অনুরোধের বিষয়বস্তু উপরের স্ক্রিনশটে দেখানো হিসাবে খালি পাওয়া যায়, যদিও আপনি একটি বৈধ পেলোড পাঠিয়েছেন, তাহলে এটি নির্দেশ করে যে এই সমস্যার সম্ভাব্য কারণ হল অনুরোধ স্ট্রিমিং সক্ষম করা হয়েছে।

   এর কারণ হল যখন স্ট্রিমিং সক্ষম করা থাকে, অনুরোধের পেলোড ট্রেসে প্রদর্শিত হবে না৷

   একইভাবে, যদি রেসপন্স পেলোড পার্স করা হয় যখন ত্রুটি ঘটে, তাহলে "টার্গেট সার্ভার থেকে প্রাপ্ত প্রতিক্রিয়া" পর্যায়ে প্রতিক্রিয়া বিষয়বস্তু পরীক্ষা করুন।

10. এরপরে, API প্রক্সি ফ্লোতে ব্যর্থ নীতি কোথায় ব্যবহৃত হয় তার উপর নির্ভর করে প্রক্সি এবং টার্গেট এন্ডপয়েন্ট সংজ্ঞা পরীক্ষা করুন। স্ট্রিমিং সক্ষম করা হয়েছে কিনা তা যাচাই করুন।

    উদাহরণের পরিস্থিতিতে, ব্যর্থ নীতিটি প্রক্সি অনুরোধ প্রবাহে কার্যকর করা হয়েছিল (উপরের ধাপ #5 এ নির্ধারিত); অতএব, প্রক্সি এন্ডপয়েন্ট পরীক্ষা করুন:

    <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" প্রপার্টি দ্বারা নির্দেশিত হিসাবে অনুরোধ স্ট্রিমিং সক্ষম করা হয়েছে।

    অতএব, ত্রুটির কারণ হল API প্রক্সিতে JSONThreatProtection নীতি ব্যবহার করা যা স্ট্রিমিং সক্ষম হলে অনুরোধ পেলোড অ্যাক্সেস করে। এটি ত্রুটি সৃষ্টি করে কারণ এটি এপিআই প্রক্সিতে বাফারিং ট্রিগার করে এবং এপিজি এজ-এ স্ট্রিমিং ব্যবহারের উদ্দেশ্যকে হারায়।

    এই ত্রুটিটি ছোট পেলোডের সাথে দেখা নাও যেতে পারে, কিন্তু আপনি যখন বড় পেলোড ব্যবহার করেন, তখন আপনি এই ত্রুটিগুলি দেখতে পারেন৷

11. আপনি নীচের প্রদত্ত পদক্ষেপগুলি ব্যবহার করে ট্রেসে "AX" (Analytics Data Recorded) পর্যায়ে "X-Apigee-fault-source" এর মান পরীক্ষা করে নীতির কারণে 500 ত্রুটিটি ঘটেছে তা যাচাই করতে পারেন:
    1. নীচের স্ক্রিনশটে দেখানো হিসাবে " AX " (Analytics Data Recorded) পর্যায়ে ক্লিক করুন:

       

    2. "ত্রুটির শিরোনাম" বিভাগে ফেজ বিবরণ নিচে স্ক্রোল করুন এবং নীচে দেখানো হিসাবে "X-Apigee-fault-code" , "X-Apigee-fault-source" এবং "X-Apigee-fault-policy" এর মান নির্ধারণ করুন:

       

    3. যদি উপরের ছবিতে দেখানো "X-Apigee-fault-source"- এর মান "নীতি" হয়, তাহলে এটি নির্দেশ করে যে স্ট্রিমিং সক্ষম করার সময় পেলোড অ্যাক্সেস করার নীতির কারণে ত্রুটি ঘটেছে।

রেজোলিউশন

স্ট্রিমিং সক্ষম করে পেলোড অ্যাক্সেস করা একটি অ্যান্টিপ্যাটার্ন যা অ্যান্টিপ্যাটার্নে ব্যাখ্যা করা হয়েছে: স্ট্রিমিং সক্ষম হলে অনুরোধ/প্রতিক্রিয়া পেলোড অ্যাক্সেস করুন ।

1. আপনি যদি পেলোড প্রক্রিয়া করতে চান, তাহলে আপনাকে প্রক্সি/টার্গেট এন্ডপয়েন্টে " request.streaming.enabled" and " response.streaming.enabled" বৈশিষ্ট্যগুলি সরিয়ে প্রক্সিএন্ডপয়েন্টের উদাহরণে স্ট্রিমিং অক্ষম করতে হবে:

   <ProxyEndpoint name="default">
   ...
     <HTTPProxyConnection>
       <BasePath>/v1/weather</BasePath>
       <VirtualHost>secure</VirtualHost>
     </HTTPProxyConnection>
   </ProxyEndpoint>

   বা

2. আপনি যদি আপনার API প্রক্সি(ies) এর জন্য স্ট্রিমিং ব্যবহার করতে চান, তাহলে API প্রক্সিতে অনুরোধ/প্রতিক্রিয়া পেলোড অ্যাক্সেস করে এমন কোনো নীতি ব্যবহার করবেন না।

দ্রষ্টব্য:

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

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

আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন তবে এই পদ্ধতিটি এড়িয়ে যান।

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

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

নীতি থেকে একটি 500 ত্রুটির প্রতিক্রিয়া ছুঁড়ে দিলে আপনি যদি বিজ্ঞপ্তি পেতে চান, তাহলে আপনাকে প্রক্সি হিসাবে ত্রুটির উত্স সহ 500 স্ট্যাটাস কোডের জন্য সতর্কতা সেট আপ করতে হবে৷

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

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

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

• প্রতিষ্ঠানের নাম
• পরিবেশের নাম
• API প্রক্সি নাম
• 500 ত্রুটি পুনরুত্পাদন করতে অনুরোধ পেলোড সহ সম্পূর্ণ কার্ল কমান্ড (যদি থাকে)
• 500 অভ্যন্তরীণ সার্ভার ত্রুটি সহ অনুরোধ ধারণকারী ট্রেস ফাইল
• যদি বর্তমানে 500টি ত্রুটি না ঘটছে তবে অতীতে 500টি ত্রুটি ঘটেছে এমন সময় অঞ্চলের তথ্য সহ সময়কাল প্রদান করুন।

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

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