504 গেটওয়ে টাইমআউট

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

লক্ষণ

এপিআই কলগুলোর প্রতিক্রিয়া হিসেবে ক্লায়েন্ট অ্যাপ্লিকেশনটি Gateway Timeout বার্তা সহ একটি 504 HTTP স্ট্যাটাস কোড পায়।

HTTP স্ট্যাটাস কোড - 504 Gateway Timeout ত্রুটিটি নির্দেশ করে যে, একটি API নির্বাহের সময় ক্লায়েন্ট এজ গেটওয়ে বা ব্যাকএন্ড সার্ভার থেকে সময়মতো প্রতিক্রিয়া পায়নি।

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

ক্লায়েন্ট অ্যাপ্লিকেশনটি নিম্নলিখিত প্রতিক্রিয়া কোডটি পায়:

HTTP/1.1 504 Gateway Timeout

কিছু ক্ষেত্রে, নিম্নলিখিত ত্রুটি বার্তাও দেখা যেতে পারে:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

কী কারণে গেটওয়ে টাইমআউট হয়?

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

এজ প্ল্যাটফর্মের মধ্যে থাকা ক্লায়েন্ট অ্যাপ্লিকেশন, রাউটার এবং মেসেজ প্রসেসরগুলো উপযুক্ত টাইমআউট ভ্যালু দিয়ে সেট আপ করা থাকে। এজ প্ল্যাটফর্ম আশা করে যে, টাইমআউট ভ্যালুর উপর ভিত্তি করে প্রতিটি এপিআই (API) অনুরোধের জন্য একটি নির্দিষ্ট সময়ের মধ্যে প্রতিক্রিয়া পাঠানো হবে। যদি নির্দিষ্ট সময়ের মধ্যে প্রতিক্রিয়া না পাওয়া যায়, তাহলে 504 Gateway Timeout Error ফেরত দেওয়া হয়।

নিচের সারণিতে Edge-এ কখন টাইমআউট হতে পারে সে সম্পর্কে আরও বিস্তারিত তথ্য দেওয়া হয়েছে:

টাইমআউট ঘটনা বিস্তারিত
মেসেজ প্রসেসরে টাইমআউট ঘটে।
  • ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরে নির্ধারিত টাইমআউট সময়ের মধ্যে সাড়া দেয় না।
  • মেসেজ প্রসেসর টাইম আউট হয়ে গেলে রাউটারের কাছে 504 Gateway Timeout হিসেবে রেসপন্স স্ট্যাটাস পাঠায়।
রাউটারে টাইমআউট ঘটে
  • মেসেজ প্রসেসর রাউটারে নির্দিষ্ট টাইমআউট সময়ের মধ্যে রাউটারকে সাড়া দেয় না।
  • রাউটারের সময়সীমা শেষ হয়ে গেলে, এটি ক্লায়েন্ট অ্যাপ্লিকেশনকে 504 Gateway Timeout হিসেবে প্রতিক্রিয়া স্ট্যাটাস পাঠায়।
ক্লায়েন্ট অ্যাপ্লিকেশনে টাইমআউট ঘটে।
  • রাউটারটি নির্ধারিত টাইমআউট সময়ের মধ্যে ক্লায়েন্ট অ্যাপ্লিকেশনে সাড়া দেয় না।
  • ক্লায়েন্ট অ্যাপ্লিকেশনটি টাইম আউট হয়ে যায় এবং শেষ ব্যবহারকারীর কাছে প্রতিক্রিয়ার স্ট্যাটাস 504 Gateway Timeout হিসাবে পাঠায়।

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

Edge ব্রাউজারে 504 Gateway Timeout এরর হওয়ার সাধারণ কারণগুলো হলো:

কারণ বিস্তারিত প্রদত্ত পদক্ষেপ
ধীরগতির ব্যাকএন্ড সার্ভার অতিরিক্ত চাপ বা দুর্বল পারফরম্যান্সের কারণে এপিআই অনুরোধটি প্রসেসকারী ব্যাকএন্ড সার্ভারটি খুব ধীরগতির। পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারীরা
Edge দ্বারা API অনুরোধ প্রক্রিয়াকরণ ধীর অতিরিক্ত লোড অথবা দুর্বল পারফরম্যান্সের কারণে Edge এপিআই অনুরোধটি প্রসেস করতে অনেক সময় নেয়।

ধীরগতির ব্যাকএন্ড সার্ভার

যদি ব্যাকএন্ড সার্ভার খুব ধীরগতির হয় অথবা এপিআই অনুরোধটি প্রসেস করতে অনেক সময় নেয়, তাহলে আপনি একটি 504 Gateway Timeout ত্রুটি পাবেন। উপরের অংশে যেমন ব্যাখ্যা করা হয়েছে, নিম্নলিখিত পরিস্থিতিগুলোর যেকোনো একটির কারণে টাইমআউট ঘটতে পারে:

  1. ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই মেসেজ প্রসেসরের সময়সীমা শেষ হয়ে যায়।
  2. মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই রাউটারের টাইমআউট হয়ে যায়।
  3. রাউটার/মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশনটির সময়সীমা শেষ হয়ে যায়।

নিম্নলিখিত বিভাগগুলিতে এই প্রতিটি পরিস্থিতিতে সমস্যাটি কীভাবে নির্ণয় এবং সমাধান করতে হয় তা বর্ণনা করা হয়েছে।

দৃশ্যকল্প #১: ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই মেসেজ প্রসেসরের সময়সীমা শেষ হয়ে যায়

রোগ নির্ণয়

ব্যাকএন্ড সার্ভার ধীরগতির হওয়ার কারণে 504 Gateway Timeout ত্রুটিটি ঘটেছে কিনা, তা নির্ণয় করতে আপনি নিম্নলিখিত পদ্ধতিগুলো ব্যবহার করতে পারেন।

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

যদি সমস্যাটি এখনও বিদ্যমান থাকে (অর্থাৎ এখনও 504 ত্রুটি দেখা দেয়), তাহলে নিচের ধাপগুলো অনুসরণ করুন:

  1. Edge UI-তে প্রভাবিত API-টি ট্রেস করুন। হয় ত্রুটিটি ঘটা পর্যন্ত অপেক্ষা করুন, অথবা যদি আপনার কাছে API কলটি থাকে, তবে কয়েকটি API কল করে 504 Gateway Timeout ত্রুটিটি পুনরায় ঘটান।
  2. ত্রুটিটি ঘটলে, সেই নির্দিষ্ট অনুরোধটি পরীক্ষা করুন যেটিতে প্রতিক্রিয়া কোড 504 দেখাচ্ছে।
  3. প্রতিটি পর্যায়ে অতিবাহিত সময় পরীক্ষা করুন এবং যে পর্যায়ে সবচেয়ে বেশি সময় ব্যয় হয়েছে তা লিখে রাখুন।
  4. যদি আপনি নিম্নলিখিত পর্যায়গুলির কোনো একটির ঠিক পরেই দীর্ঘতম সময়সহ ত্রুটিটি লক্ষ্য করেন, তাহলে এটি নির্দেশ করে যে ব্যাকএন্ড সার্ভারটি ধীরগতির অথবা অনুরোধটি প্রক্রিয়াকরণে দীর্ঘ সময় নিচ্ছে:
    • টার্গেট সার্ভারে অনুরোধ পাঠানো হয়েছে
    • সার্ভিসকলআউট নীতি

নিম্নলিখিতে একটি নমুনা ট্রেস দেওয়া হলো, যেখানে দেখা যাচ্ছে যে ৫৫ সেকেন্ড পরেও ব্যাকএন্ড সার্ভারটি সাড়া না দেওয়ায় একটি 504 Gateway Timeout ত্রুটি দেখা দিয়েছে:

উপরের ট্রেসটিতে দেখা যাচ্ছে, ব্যাকএন্ড সার্ভার সাড়া না দেওয়ায় ৫৫০০২ মিলিসেকেন্ড পর মেসেজ প্রসেসরটির টাইম আউট হয়ে যায়।

পদ্ধতি #২ মেসেজ প্রসেসর লগ ব্যবহার করা

  1. মেসেজ প্রসেসরের লগ চেক করুন ( /opt/apigee/var/log/edge-message-processor/logs/system.log )

  2. যদি আপনি নির্দিষ্ট সময়ে নির্দিষ্ট এপিআই প্রক্সি অনুরোধের জন্য Gateway Timeout এবং onTimeoutRead ত্রুটি খুঁজে পান, তাহলে এটি নির্দেশ করে যে মেসেজ প্রসেসরের সময়সীমা শেষ হয়ে গেছে।

    গেটওয়ে টাইমআউট ত্রুটি দেখানো নমুনা মেসেজ প্রসেসর লগ।

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    উপরের মেসেজ প্রসেসর লগে আপনি লক্ষ্য করবেন যে, XX.XX.XX.XX আইপি অ্যাড্রেসযুক্ত ব্যাকএন্ড সার্ভারটি ৫৫ সেকেন্ড পরেও ( lastIO=55000ms ) সাড়া দেয়নি। ফলে, মেসেজ প্রসেসরটি টাইম আউট হয়ে গেছে এবং 504 Gateway Timeout এরর পাঠিয়েছে।

    এটি দেখুন: মেসেজ প্রসেসরে টাইমআউট কীভাবে নিয়ন্ত্রণ করা হয়?

    • মেসেজ প্রসেসরে টাইমআউট কীভাবে নিয়ন্ত্রণ করা হয়? মেসেজ প্রসেসরগুলিতে সাধারণত HTTPTransport.io.timeout.millis প্রপার্টির মাধ্যমে ৫৫ সেকেন্ডের একটি ডিফল্ট টাইমআউট ভ্যালু সেট করা থাকে। এই টাইমআউট ভ্যালুটি সেই সমস্ত এপিআই প্রক্সির জন্য প্রযোজ্য, যেগুলো এই মেসেজ প্রসেসর দ্বারা পরিচালিত কোনো অর্গানাইজেশনের অন্তর্গত।
      • যদি ব্যাকএন্ড সার্ভার ৫৫ সেকেন্ডের মধ্যে সাড়া না দেয়, তাহলে মেসেজ প্রসেসর টাইম আউট হয়ে যায় এবং ক্লায়েন্টের কাছে 504 Gateway Timeout ত্রুটি পাঠায়।
    • মেসেজ প্রসেসরে নির্দিষ্ট করা টাইমআউট ভ্যালুটি এপিআই প্রক্সির মধ্যে নির্দিষ্ট করা io.timeout.millis প্রপার্টি দ্বারা ওভাররাইড করা যেতে পারে। এই টাইমআউট ভ্যালুটি একটি নির্দিষ্ট এপিআই প্রক্সির জন্য প্রযোজ্য, যেখানে উপরোক্ত প্রপার্টিটি নির্দিষ্ট করা আছে। উদাহরণস্বরূপ, যদি এপিআই প্রক্সির মধ্যে io.timeout.millis ১০ সেকেন্ডে সেট করা থাকে, তাহলে এই নির্দিষ্ট এপিআই প্রক্সির জন্য ১০ সেকেন্ডের টাইমআউট ভ্যালুটি ব্যবহৃত হবে।
      • যদি নির্দিষ্ট এপিআই প্রক্সির জন্য ব্যাকএন্ড সার্ভার ১০ সেকেন্ডের মধ্যে সাড়া না দেয়, তাহলে মেসেজ প্রসেসর টাইম আউট হয়ে যায় এবং ক্লায়েন্টের কাছে 504 Gateway Timeout ত্রুটি পাঠায়।

সমাধান

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

দৃশ্যকল্প #২ - মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই রাউটারের টাইমআউট হয়ে যায়

মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই যদি রাউটারের টাইমআউট হয়ে যায়, তাহলে আপনি 504 Gateway Timeout ত্রুটি পেতে পারেন। নিম্নলিখিত পরিস্থিতিগুলোর যেকোনো একটির কারণে এটি ঘটতে পারে:

  • রাউটারে সেট করা টাইমআউট ভ্যালু মেসেজ প্রসেসরে সেট করা টাইমআউট ভ্যালুর চেয়ে কম। উদাহরণস্বরূপ, ধরা যাক রাউটারের টাইমআউট ৫০ সেকেন্ড, আর মেসেজ প্রসেসরের টাইমআউট ৫৫ সেকেন্ড।
    রাউটারে টাইমআউট মেসেজ প্রসেসরে সময়সীমা অতিক্রান্ত
    ৫০ সেকেন্ড ৫৫ সেকেন্ড
  • এপিআই প্রক্সির টার্গেট এন্ডপয়েন্ট কনফিগারেশনের মধ্যে সেট করা io.timeout.millis প্রপার্টি ব্যবহার করে মেসেজ প্রসেসরের টাইমআউট ভ্যালুটি একটি উচ্চতর টাইমআউট ভ্যালু দ্বারা ওভাররাইড করা হয়:

    উদাহরণস্বরূপ, যদি নিম্নলিখিত টাইমআউট মানগুলি সেট করা হয়:

    রাউটারে টাইমআউট মেসেজ প্রসেসরে সময়সীমা অতিক্রান্ত এপিআই প্রক্সির মধ্যে টাইমআউট
    ৫৭ সেকেন্ড ৫৫ সেকেন্ড ১২০ সেকেন্ড

    কিন্তু এপিআই প্রক্সিতে io.timeout.millis ১২০ সেকেন্ডে সেট করা আছে:

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    তাহলে, মেসেজ প্রসেসরটি ৫৫ সেকেন্ড পরে টাইমআউট হবে না, যদিও এর টাইমআউট মান (৫৫ সেকেন্ড) রাউটারের টাইমআউট মানের (৫৭ সেকেন্ড) চেয়ে কম। এর কারণ হলো, মেসেজ প্রসেসরের ৫৫ সেকেন্ডের টাইমআউট মানটি এপিআই প্রক্সির মধ্যে সেট করা ১২০ সেকেন্ডের মান দ্বারা ওভাররাইড হয়ে যায়। সুতরাং, এই নির্দিষ্ট এপিআই প্রক্সির জন্য মেসেজ প্রসেসরের টাইমআউট মান হবে ১২০ সেকেন্ড।

    এপিআই প্রক্সিতে সেট করা ১২০ সেকেন্ডের তুলনায় রাউটারের টাইমআউট মান কম (৫৭ সেকেন্ড) হওয়ায়, ব্যাকএন্ড সার্ভার ৫৭ সেকেন্ড পর সাড়া না দিলে রাউটারটি টাইমআউট হয়ে যাবে।

রোগ নির্ণয়

  1. NGINX অ্যাক্সেস লগ চেক করুন ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )

  2. যদি মেসেজ প্রসেসরের আগে রাউটারের টাইমআউট হয়ে যায়, তাহলে আপনি নির্দিষ্ট API অনুরোধটির জন্য NGINX অ্যাক্সেস লগে 504 স্ট্যাটাস দেখতে পাবেন এবং মেসেজ প্রসেসর থেকে message id - হিসাবে সেট করা থাকবে। এর কারণ হলো, রাউটারে সেট করা টাইমআউট সময়ের মধ্যে রাউটারটি মেসেজ প্রসেসরের কাছ থেকে কোনো প্রতিক্রিয়া পায়নি।

    রাউটার টাইম আউট হওয়ার কারণে 504 ত্রুটি দেখাচ্ছে এমন একটি নমুনা NGINX লগ এন্ট্রি।

  3. উপরের উদাহরণে, NGINX-এর 504 স্ট্যাটাসটি লক্ষ্য করুন, মেসেজ প্রসেসর থেকে প্রাপ্ত মেসেজ আইডিটি হলো - এবং মোট অতিবাহিত সময় হলো ৫৭.০০১ সেকেন্ড। এর কারণ হলো, ৫৭.০০১ সেকেন্ড পর রাউটারটির টাইম আউট হয়ে গেছে এবং আমরা মেসেজ প্রসেসর থেকে কোনো সাড়া পাইনি।
  4. এক্ষেত্রে, আপনি মেসেজ প্রসেসর লগগুলিতে ( /opt/apigee/var/log/edge-message-processor/logs/system.log). Broken Pipe এক্সেপশন দেখতে পাবেন। 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

এই ত্রুটিটি প্রদর্শিত হয় কারণ রাউটারের সময়সীমা শেষ হয়ে গেলে, এটি মেসেজ প্রসেসরের সাথে সংযোগটি বন্ধ করে দেয়। মেসেজ প্রসেসর তার প্রক্রিয়াকরণ সম্পন্ন করার পর, রাউটারে প্রতিক্রিয়াটি লেখার চেষ্টা করে। যেহেতু রাউটারের সাথে সংযোগটি ইতিমধ্যেই বন্ধ হয়ে গেছে, তাই মেসেজ প্রসেসরে Broken Pipe exception দেখা দেয়।

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

সমাধান

  1. যদি এটি একটি কাস্টম ব্যাকএন্ড সার্ভার হয়, তাহলে
    1. ব্যাকএন্ড সার্ভারটি কেন সাড়া দিতে বেশি সময় নিচ্ছে তা খতিয়ে দেখুন এবং এটিকে আরও দ্রুত সাড়া দেওয়ার জন্য ঠিক বা অপ্টিমাইজ করা যায় কিনা তা দেখুন।
    2. যদি ব্যাকএন্ড সার্ভারটি ঠিক করা বা অপ্টিমাইজ করা সম্ভব না হয়, অথবা এটি জানা থাকে যে ব্যাকএন্ড সার্ভারটি অনেক বেশি সময় নেয়, তাহলে রাউটার এবং মেসেজ প্রসেসরের টাইমআউট ভ্যালু বাড়িয়ে দিন ।

      ধারণা: বিভিন্ন কম্পোনেন্টগুলিতে নিম্নলিখিত ক্রমে টাইমআউট মান সেট করুন:

      ক্লায়েন্টে টাইমআউট > রাউটারে টাইমআউট > মেসেজ প্রসেসরে টাইমআউট > এপিআই প্রক্সির মধ্যে টাইমআউট

  2. যদি এটি একটি NodeJS ব্যাকএন্ড সার্ভার হয়, তাহলে:
    1. NodeJS কোডটি অন্য কোনো ব্যাকএন্ড সার্ভারে কল করছে কিনা এবং প্রতিক্রিয়া জানাতে বেশি সময় নিচ্ছে কিনা তা পরীক্ষা করুন। ব্যাকএন্ড সার্ভারগুলো কেন বেশি সময় নিচ্ছে তা খতিয়ে দেখুন এবং যথাযথভাবে সমস্যাটি সমাধান করুন।
    2. মেসেজ প্রসেসরগুলোতে অতিরিক্ত সিপিইউ বা মেমরি ব্যবহার হচ্ছে কিনা তা পরীক্ষা করুন:
      1. যদি কোনো মেসেজ প্রসেসরের সিপিইউ ব্যবহার বেড়ে যায়, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি থ্রেড ডাম্প তৈরি করুন: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. যদি কোনো মেসেজ প্রসেসরের মেমরি ব্যবহার বেড়ে যায়, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করে একটি হিপ ডাম্প তৈরি করুন: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. নিচের কমান্ডটি ব্যবহার করে মেসেজ প্রসেসরটি রিস্টার্ট করুন। এতে সিপিইউ এবং মেমরি ডাউন হয়ে আসবে: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. সমস্যাটি এখনও বিদ্যমান কিনা তা নিশ্চিত করতে এপিআই কলগুলো পর্যবেক্ষণ করুন।
      5. উচ্চ সিপিইউ/মেমরি ব্যবহারের কারণ অনুসন্ধানে সহায়তার জন্য Apigee Edge Support-এর সাথে যোগাযোগ করুন এবং থ্রেড ডাম্প, হিপ ডাম্প, ও মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log) প্রদান করুন।

এটি দেখুন: মেসেজ প্রসেসরে NodeJS ব্যাকএন্ড সার্ভারের টাইমআউট কীভাবে নিয়ন্ত্রণ করা হয়

  • NodeJS ব্যাকএন্ড সার্ভারটি মেসেজ প্রসেসরের JVM প্রসেসের মধ্যে চলে। NodeJS ব্যাকএন্ড সার্ভারগুলোর টাইমআউট ভ্যালু nodejs.properties ফাইলের http.request.timeout.seconds প্রপার্টির মাধ্যমে নিয়ন্ত্রণ করা হয়। এই প্রপার্টিটি ডিফল্টভাবে ০-তে সেট করা থাকে, অর্থাৎ, এই মেসেজ প্রসেসর দ্বারা পরিচালিত কোনো অর্গানাইজেশনের অন্তর্গত সমস্ত এপিআই প্রক্সির জন্য টাইমআউট ডিফল্টভাবে নিষ্ক্রিয় থাকে। তাই কোনো NodeJS ব্যাকএন্ড সার্ভার বেশি সময় নিলেও মেসেজ প্রসেসরটি টাইমআউট হবে না।
  • তবে, যদি NodeJS ব্যাকএন্ড সার্ভারটি বেশি সময় নেয় এবং API অনুরোধটি সম্পন্ন হতে ৫৭ সেকেন্ডের বেশি সময় লাগে, তাহলে রাউটারটি টাইমআউট হয়ে যাবে এবং ক্লায়েন্টের কাছে 504 Gateway Timeout ত্রুটি পাঠাবে।

দৃশ্যকল্প #৩ - রাউটার/মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশন টাইম আউট হয়ে যায়

ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগেই যদি ক্লায়েন্ট অ্যাপ্লিকেশনটির সময়সীমা শেষ হয়ে যায়, তাহলে আপনি 504 Gateway Timeout ত্রুটি পেতে পারেন। এই পরিস্থিতিটি ঘটতে পারে যদি:

  1. ক্লায়েন্ট অ্যাপ্লিকেশনে সেট করা টাইমআউট মানটি রাউটার এবং মেসেজ প্রসেসরে সেট করা টাইমআউট মানের চেয়ে কম:

    উদাহরণস্বরূপ, যদি নিম্নলিখিত টাইমআউট মানগুলি সেট করা হয়:

    ক্লায়েন্টে সময়সীমা শেষ রাউটারে টাইমআউট মেসেজ প্রসেসরে সময়সীমা অতিক্রান্ত
    ৫০ সেকেন্ড ৫৭ সেকেন্ড ৫৫ সেকেন্ড

    এই ক্ষেত্রে, Edge-এর মাধ্যমে একটি API অনুরোধের প্রতিক্রিয়া পেতে মোট উপলব্ধ সময় ৫০ সেকেন্ড বা তার কম। এর মধ্যে অন্তর্ভুক্ত রয়েছে একটি API অনুরোধ করার সময়, Edge দ্বারা অনুরোধটি প্রক্রিয়াকরণ (রাউটার, মেসেজ প্রসেসর), ব্যাকএন্ড সার্ভারে অনুরোধটি পাঠানো (যদি প্রযোজ্য হয়), ব্যাকএন্ড দ্বারা অনুরোধটি প্রক্রিয়াকরণ এবং প্রতিক্রিয়া পাঠানো, Edge দ্বারা প্রতিক্রিয়াটি প্রক্রিয়াকরণ এবং অবশেষে ক্লায়েন্টের কাছে তা ফেরত পাঠানো।

    যদি রাউটার ৫০ সেকেন্ডের মধ্যে ক্লায়েন্টকে সাড়া না দেয়, তাহলে ক্লায়েন্টের টাইমআউট হয়ে যাবে এবং রাউটারের সাথে সংযোগটি বন্ধ করে দেবে। ক্লায়েন্ট 504 রেসপন্স কোডটি পাবে।

    এর ফলে NGINX একটি 499 স্ট্যাটাস কোড সেট করবে, যা নির্দেশ করে যে ক্লায়েন্ট সংযোগটি বন্ধ করে দিয়েছে।

রোগ নির্ণয়

  1. যদি ক্লায়েন্ট অ্যাপ্লিকেশনটি রাউটার থেকে প্রতিক্রিয়া পাওয়ার আগেই টাইম আউট হয়ে যায়, তাহলে এটি রাউটারের সাথে সংযোগটি বন্ধ করে দেবে। এই পরিস্থিতিতে, আপনি নির্দিষ্ট API অনুরোধটির জন্য NGINX অ্যাক্সেস লগগুলিতে 499 স্ট্যাটাস কোডটি দেখতে পাবেন।

    স্ট্যাটাস কোড 499 দেখানো একটি নমুনা NGINX লগ এন্ট্রি।

  2. উপরের উদাহরণে, লক্ষ্য করুন যে NGINX-এর স্ট্যাটাস 499 এবং মোট অতিবাহিত সময় 50.001 সেকেন্ড। এটি নির্দেশ করে যে ক্লায়েন্টটি 50.001 সেকেন্ড পরে টাইম আউট হয়ে গেছে।
  3. এক্ষেত্রে, আপনি মেসেজ প্রসেসর লগ-এ ( /opt/apigee/var/log/edge-message-processor/logs/system.log). Broken Pipe এক্সেপশন দেখতে পাবেন।
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
  4. রাউটারের সময়সীমা শেষ হয়ে গেলে, এটি মেসেজ প্রসেসরের সাথে সংযোগটি বন্ধ করে দেয়। মেসেজ প্রসেসর তার প্রক্রিয়াকরণ সম্পন্ন করলে, এটি রাউটারে প্রতিক্রিয়াটি লেখার চেষ্টা করে। যেহেতু রাউটারের সাথে সংযোগটি ইতিমধ্যেই বন্ধ হয়ে গেছে, তাই মেসেজ প্রসেসরে Broken Pipe exception দেখা দেয়।
  5. উপরে বর্ণিত পরিস্থিতিতে এই ব্যতিক্রমটি প্রত্যাশিত। সুতরাং, 504 Gateway Timeout ত্রুটির আসল কারণ হলো ব্যাকএন্ড সার্ভারের সাড়া দিতে দীর্ঘ সময় নেওয়া এবং আপনাকে সেই সমস্যাটির সমাধান করতে হবে।

সমাধান

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

      ধারণা: বিভিন্ন কম্পোনেন্টগুলিতে নিম্নলিখিত ক্রমে টাইমআউট মান সেট করুন:

      ক্লায়েন্টে টাইমআউট > রাউটারে টাইমআউট > মেসেজ প্রসেসরে টাইমআউট > এপিআই প্রক্সির মধ্যে টাইমআউট

  2. যদি ব্যাকএন্ডটি NodeJS হয়, তাহলে:
    1. NodeJS কোডটি অন্য কোনো ব্যাকএন্ড সার্ভারে কল করছে কিনা এবং সেই কলগুলো ফেরত আসতে বেশি সময় নিচ্ছে কিনা তা পরীক্ষা করুন। ঐ ব্যাকএন্ড সার্ভারগুলো কেন বেশি সময় নিচ্ছে, তা খতিয়ে দেখুন।
    2. মেসেজ প্রসেসরগুলোতে অতিরিক্ত সিপিইউ বা মেমরি ব্যবহার হচ্ছে কিনা তা পরীক্ষা করুন:
      1. যদি কোনো মেসেজ প্রসেসরের সিপিইউ ব্যবহার বেড়ে যায়, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি থ্রেড ডাম্প তৈরি করুন: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. যদি কোনো মেসেজ প্রসেসরের মেমরি ব্যবহার বেড়ে যায়, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করে একটি হিপ ডাম্প তৈরি করুন: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. নিচের কমান্ডটি ব্যবহার করে মেসেজ প্রসেসরটি রিস্টার্ট করুন। এতে সিপিইউ এবং মেমরি ডাউন হয়ে যাবে: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. সমস্যাটি এখনও বিদ্যমান কিনা তা নিশ্চিত করতে এপিআই কলগুলো পর্যবেক্ষণ করুন।
      5. উচ্চ সিপিইউ/মেমরি ব্যবহারের কারণ অনুসন্ধানে সাহায্য করার জন্য Apigee Edge Support-এর সাথে যোগাযোগ করুন এবং থ্রেড ডাম্প, হিপ ডাম্প, ও মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log) প্রদান করুন।

রাউটার এবং মেসেজ প্রসেসরের টাইমআউট মান বৃদ্ধি করুন।

আপনার প্রয়োজন অনুযায়ী রাউটার এবং মেসেজ প্রসেসরে সেট করার জন্য টাইমআউট মানগুলি সাবধানে বেছে নিন। যথেচ্ছভাবে বড় টাইমআউট মান সেট করবেন না। আপনার সাহায্যের প্রয়োজন হলে, Apigee Edge Support-এর সাথে যোগাযোগ করুন।

রাউটার 

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. রাউটার মেশিনে /opt/apigee/customer/application/router.properties ফাইলটি তৈরি করুন, যদি এটি আগে থেকে বিদ্যমান না থাকে।
  2. এই ফাইলে নিম্নলিখিত লাইনটি যোগ করুন:
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    উদাহরণস্বরূপ, যদি আপনি টাইমআউটের মান ১২০ সেকেন্ড নির্ধারণ করতে চান, তাহলে তা নিম্নরূপে নির্ধারণ করুন: 

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. নিশ্চিত করুন এই ফাইলটির মালিক apigee:
  4. রাউটারটি পুনরায় চালু করুন: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. আপনার যদি একাধিক রাউটার থাকে, তাহলে সব রাউটারে উপরের ধাপগুলো পুনরাবৃত্তি করুন।

বার্তা প্রসেসর

  1. মেসেজ প্রসেসর মেশিনে /opt/apigee/customer/application/message-processor.properties ফাইলটি তৈরি করুন, যদি এটি আগে থেকে বিদ্যমান না থাকে।
  2. এই ফাইলে নিম্নলিখিত লাইনটি যোগ করুন:
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    উদাহরণস্বরূপ, যদি আপনি টাইমআউটের মান ১২০ সেকেন্ড নির্ধারণ করতে চান, তাহলে তা নিম্নরূপে নির্ধারণ করুন: 

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. নিশ্চিত করুন এই ফাইলটির মালিক apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. মেসেজ প্রসেসরটি পুনরায় চালু করুন: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. আপনার যদি একাধিক মেসেজ প্রসেসর থাকে, তাহলে সবগুলো মেসেজ প্রসেসরের ক্ষেত্রে উপরের ধাপগুলো পুনরাবৃত্তি করুন।

ধারণা: বিভিন্ন কম্পোনেন্টগুলিতে নিম্নলিখিত ক্রমে টাইমআউট মান সেট করুন:

ক্লায়েন্টে টাইমআউট > রাউটারে টাইমআউট > মেসেজ প্রসেসরে টাইমআউট > এপিআই প্রক্সির মধ্যে টাইমআউট

Edge দ্বারা API অনুরোধ প্রক্রিয়াকরণ ধীর

যদি Edge খুব ধীরগতির হয় এবং/অথবা API অনুরোধটি প্রক্রিয়া করতে দীর্ঘ সময় নেয়, তাহলে আপনি একটি 504 Gateway Timeout ত্রুটি পাবেন।

রোগ নির্ণয়

  1. Edge UI-তে প্রভাবিত API-টি ট্রেস করুন।
  2. হয় ত্রুটিটি ঘটার জন্য অপেক্ষা করুন, অথবা আপনার কাছে এপিআই কলটি থাকলে, কয়েকটি এপিআই কল করে 504 Gateway Timeout ত্রুটিটি পুনরায় ঘটান।
  3. উল্লেখ্য, এক্ষেত্রে আপনি ট্রেস-এ একটি সফল প্রতিক্রিয়া দেখতে পারেন।
    1. রাউটার/ক্লায়েন্টে (যেটির টাইমআউট পিরিয়ড সবচেয়ে কম) নির্দিষ্ট টাইমআউট পিরিয়ডের মধ্যে মেসেজ প্রসেসর সাড়া না দেওয়ায় রাউটার/ক্লায়েন্টটি টাইমআউট হয়ে যায়। তবে, মেসেজ প্রসেসর অনুরোধটি প্রক্রিয়া করা চালিয়ে যায় এবং সফলভাবে সম্পন্ন হতে পারে।
    2. এছাড়াও, মেসেজ প্রসেসরে সেট করা HTTPTransport.io.timeout.millis ভ্যালুটি কেবল তখনই ট্রিগার হয়, যখন মেসেজ প্রসেসরটি কোনো HTTP/HTTPS ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করে। অন্য কথায়, এপিআই প্রক্সির মধ্যে থাকা কোনো পলিসি (সার্ভিসকলআউট পলিসি ছাড়া) দীর্ঘ সময় নিলে এই টাইমআউটটি ট্রিগার হবে না।
  4. ত্রুটি ঘটার পর, যে নির্দিষ্ট অনুরোধটির জন্য সবচেয়ে বেশি সময় অতিবাহিত হয়েছে, সেটি পরীক্ষা করুন।
  5. প্রতিটি পর্যায়ে অতিবাহিত সময় পরীক্ষা করুন এবং যে পর্যায়ে সবচেয়ে বেশি সময় ব্যয় হয়েছে তা লিখে রাখুন।
  6. সার্ভিস কলআউট পলিসি ছাড়া অন্য কোনো পলিসিতে যদি সবচেয়ে বেশি সময় অতিবাহিত হতে দেখা যায়, তাহলে বুঝতে হবে যে Edge অনুরোধটি প্রসেস করতে দীর্ঘ সময় নিচ্ছে।
  7. এখানে একটি নমুনা UI ট্রেস দেওয়া হলো, যেখানে জাভাস্ক্রিপ্ট পলিসিতে অতিবাহিত সময় অনেক বেশি দেখাচ্ছে:

  8. উপরের উদাহরণে, আপনি লক্ষ্য করবেন যে জাভাস্ক্রিপ্ট পলিসিটি সম্পন্ন হতে অস্বাভাবিকভাবে দীর্ঘ সময়, প্রায় ২৪৫ সেকেন্ড, লাগছে।

সমাধান

  1. যে পলিসিটি সাড়া দিতে দীর্ঘ সময় নিচ্ছে, সেটি পরীক্ষা করুন এবং এমন কোনো কাস্টম কোড আছে কিনা যা প্রসেস হতে দীর্ঘ সময় নিতে পারে, তা দেখুন। যদি এমন কোনো কোড থাকে, তাহলে চিহ্নিত কোডটি ঠিক বা অপ্টিমাইজ করা যায় কিনা তা দেখুন।
  2. যদি এমন কোনো কাস্টম কোড না থাকে যা বেশি প্রসেসিং সময়ের কারণ হতে পারে, তাহলে পরীক্ষা করে দেখুন মেসেজ প্রসেসরগুলোতে অতিরিক্ত সিপিইউ বা মেমরি ব্যবহার হচ্ছে কিনা:
    1. যদি কোনো মেসেজ প্রসেসরের সিপিইউ ব্যবহার বেড়ে যায়, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি থ্রেড ডাম্প তৈরি করুন: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. যদি কোনো মেসেজ প্রসেসরের মেমরি ব্যবহার বেশি হয়, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করে একটি হিপ ডাম্প তৈরি করুন: 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. নিচের কমান্ডটি ব্যবহার করে মেসেজ প্রসেসরটি রিস্টার্ট করুন। এতে সিপিইউ এবং মেমরি ডাউন হয়ে আসবে। 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. এপিআই কলগুলো পর্যবেক্ষণ করুন এবং সমস্যাটি এখনও বিদ্যমান কিনা তা নিশ্চিত করুন।
    5. উচ্চ সিপিইউ/মেমরি ব্যবহারের কারণ অনুসন্ধানে সাহায্য করার জন্য Apigee Edge Support-এর সাথে যোগাযোগ করুন এবং থ্রেড ডাম্প, হিপ ডাম্প, ও মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log) প্রদান করুন।

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

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

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