500 ইন্টার্নাল সার্ভার সমস্যা - স্ট্রিমিং চালু করা আছে

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

সমস্যার উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশন, API কলের জন্য 500 HTTP রেসপন্স স্ট্যাটাস কোড সহ ইন্টার্নাল সার্ভার এরর মেসেজ পায়।

সমস্যার মেসেজ

ক্লায়েন্ট অ্যাপ্লিকেশন নিচে দেখানো সমস্যার উত্তর পেতে পারে: 

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 ইন্টার্নাল সার্ভার সমস্যার উপর ফোকাস করে যা স্ট্রিমিং চালু করা থাকলে অনুরোধ/উত্তর পে-লোড অ্যাক্সেস করার কারণে হয়।

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

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

ডায়াগনসিস

পদ্ধতি #১: Trace ব্যবহার করা

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

    alt_text

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

    ব্যর্থ নীতি: 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 অনুরোধ চেক করে পার্স করা হচ্ছে এমন পেলোডের ধরন নির্ধারণ করুন।

    8. আপনি API অনুরোধে অনুরোধ পেলোডের কন্টেন্ট এবং 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 ফর্ম্যাটে থাকতে হবে।

  8. পে-লোড সঠিক ফর্ম্যাটে আছে কিনা তা যাচাই করুন। পে-লোড সঠিক না হলে, আপনি এই সমস্যাটি পেতে পারেন।

  9. পে-লোড সঠিক হলেও, আপনি যদি এখনও সমস্যার মেসেজ বিভাগে তালিকাভুক্ত সমস্যাগুলি দেখতে পান, তাহলে এই সমস্যাগুলির কারণ হল স্ট্রিমিং চালু থাকাকালীন পে-লোড অ্যাক্সেস করা হচ্ছে।

    নীতি (৬ নম্বর ধাপে নির্ধারিত) দ্বারা পার্স করা হচ্ছে এমন পেলোডের উপর নির্ভর করে, উপযুক্ত ধাপে ট্রেস টুলে পেলোড কন্টেন্ট পরীক্ষা করুন।

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

    alt_text

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

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

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

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

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

    <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 চালু করা হয়েছে, যা প্রপার্টি "request.streaming.enabled"-এর মান 'ট্রু' সেট করা থেকে বোঝা যাচ্ছে।

    তাই, API Proxy-তে JSONThreatProtection নীতি ব্যবহার করার কারণে এই সমস্যা হয়েছে যেটি স্ট্রিমিং চালু থাকলে অনুরোধের পেলোড অ্যাক্সেস করে। এর ফলে সমস্যা হয় কারণ এটি API প্রক্সিতে বাফারিং ট্রিগার করে এবং Apigee Edge-এ স্ট্রিমিং ব্যবহার করার উদ্দেশ্য ব্যর্থ করে দেয়।

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

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

      alt_text

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

      alt_text

    3. উপরের ছবিতে দেখানো "X-Apigee-fault-source"-এর ভ্যালু "policy" হলে এটি ইঙ্গিত করে যে স্ট্রিমিং চালু থাকাকালীন নীতি অ্যাক্সেস করার কারণে পেলোড সংক্রান্ত সমস্যা হয়েছে।

রেজোলিউশন

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

  1. আপনি যদি পেলোড প্রসেস করতে চান, তাহলে আপনাকে প্রক্সি/টার্গেট এন্ডপয়েন্টে স্ট্রিমিং বন্ধ করতে হবে, এর জন্য "request.streaming.enabled" and "response.streaming.enabled" নিচে দেখানো উদাহরণ ProxyEndpoint থেকে প্রপার্টি সরিয়ে দিন: 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    অথবা

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

মনে রাখবেন:

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

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

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

API মনিটরিং আপনাকে দ্রুত সমস্যার ক্ষেত্রগুলি আলাদা করতে সাহায্য করে যাতে আপনি ত্রুটি, পারফর্ম্যান্স ও লেটেন্সি সংক্রান্ত সমস্যা এবং সেগুলির সোর্স ডায়াগনসিস করতে পারেন, যেমন ডেভেলপার অ্যাপ, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম।

API মনিটরিং ব্যবহার করে আপনার API-তে 5xx সমস্যা কীভাবে সমাধান করবেন তা ডেমোনস্ট্রেট করে এমন একটি নমুনা পরিস্থিতি দেখুন। যেমন, আপনি এমন একটি সতর্কতা সেট-আপ করতে পারেন যাতে ৫০০ ত্রুটির সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করলে আপনাকে বিজ্ঞপ্তি পাঠানো হয়।

নীতি থেকে 500 সমস্যার উত্তর এলে আপনি যদি বিজ্ঞপ্তি পেতে চান, তাহলে আপনাকে 500 স্ট্যাটাস কোডের জন্য সমস্যার সোর্স হিসেবে প্রক্সি সেট-আপ করতে হবে।

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

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

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

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

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

  • অনুরোধ সম্পূর্ণ না হওয়ার ক্ষেত্রে দেখা সম্পূর্ণ সমস্যার মেসেজ
  • আপনি যে সংস্থার জন্য ৫০০ এরর দেখতে পাচ্ছেন তার নাম, এনভায়রনমেন্টের নাম ও API প্রক্সি নাম
  • 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)
  • ৫০০ সমস্যা হওয়ার সময়সীমা ও টাইমজোন সংক্রান্ত তথ্য।