502 খারাপ গেটওয়ে অপ্রত্যাশিত EOF

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

লক্ষণ

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

HTTP স্ট্যাটাস কোড 502 এর অর্থ হলো, ক্লায়েন্ট ব্যাকএন্ড সার্ভারগুলো থেকে কোনো বৈধ প্রতিক্রিয়া পাচ্ছে না, যেগুলোর আসলে অনুরোধটি পূরণ করার কথা।

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

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

HTTP/1.1 502 Bad Gateway

এছাড়াও, আপনি নিম্নলিখিত ত্রুটি বার্তাটি দেখতে পারেন:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

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

502 Bad Gateway Error এর একটি সাধারণ কারণ হলো Unexpected EOF এরর, যা নিম্নলিখিত কারণে ঘটতে পারে:

সাধারণ রোগ নির্ণয়ের পদক্ষেপ

ত্রুটি নির্ণয় করতে আপনি নিম্নলিখিত পদ্ধতিগুলোর যেকোনো একটি ব্যবহার করতে পারেন:

• এপিআই মনিটরিং
• ট্রেস টুল
• NGINX অ্যাক্সেস লগ

কারণ: ভুলভাবে কনফিগার করা টার্গেট সার্ভার

টার্গেট সার্ভারটি TLS/SSL সংযোগ সমর্থন করার জন্য সঠিকভাবে কনফিগার করা নেই।

রোগ নির্ণয়

1. 502 এররের মেসেজ আইডি, ফল্ট কোড এবং ফল্ট সোর্স নির্ধারণ করতে এপিআই মনিটরিং , ট্রেস টুল বা এনজিআইএনএক্স অ্যাক্সেস লগ ব্যবহার করুন।
2. প্রভাবিত API-টির জন্য UI-তে ট্রেস চালু করুন।
3. ব্যর্থ হওয়া এপিআই অনুরোধের ট্রেসে যদি নিম্নলিখিত বিষয়গুলো দেখা যায়:
   1. টার্গেট ফ্লো রিকোয়েস্ট শুরু হওয়ার সাথে সাথেই 502 Bad Gateway এররটি দেখা যায়।
   2. error.class এ messaging.adaptors.http.UnexpectedEOF.

      তাহলে খুব সম্ভবত এই সমস্যাটি টার্গেট সার্ভারের ভুল কনফিগারেশনের কারণে হচ্ছে।

4. Edge ম্যানেজমেন্ট API কল ব্যবহার করে টার্গেট সার্ভারের সংজ্ঞাটি পান:
   1. আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে এই API-টি ব্যবহার করুন:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. আপনি যদি প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে এই API-টি ব্যবহার করুন:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      ত্রুটিপূর্ণ TargetServer সংজ্ঞার নমুনা:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. চিত্রসহ TargetServer সংজ্ঞাটি একটি সাধারণ ভুল কনফিগারেশনের উদাহরণ, যা নিম্নরূপভাবে ব্যাখ্যা করা হলো:

   ধরা যাক, টার্গেট সার্ভার mocktarget.apigee.net পোর্ট 443 এ সুরক্ষিত (HTTPS) সংযোগ গ্রহণ করার জন্য কনফিগার করা আছে। কিন্তু, আপনি যদি টার্গেট সার্ভারের সংজ্ঞাটি দেখেন, সেখানে এমন কোনো অ্যাট্রিবিউট/ফ্ল্যাগ নেই যা নির্দেশ করে যে এটি সুরক্ষিত সংযোগের জন্য তৈরি। এর ফলে Edge নির্দিষ্ট টার্গেট সার্ভারে পাঠানো API অনুরোধগুলোকে HTTP (অসুরক্ষিত) অনুরোধ হিসেবে গণ্য করে। তাই Edge এই টার্গেট সার্ভারের সাথে SSL হ্যান্ডশেক প্রক্রিয়া শুরু করবে না।

   যেহেতু টার্গেট সার্ভারটি শুধুমাত্র 443 পোর্টে HTTPS (SSL) অনুরোধ গ্রহণ করার জন্য কনফিগার করা আছে, তাই এটি Edge থেকে আসা অনুরোধটি প্রত্যাখ্যান করবে অথবা সংযোগটি বন্ধ করে দেবে। এর ফলে, আপনি মেসেজ প্রসেসরে একটি UnexpectedEOFAtTarget ত্রুটি পাবেন। মেসেজ প্রসেসরটি ক্লায়েন্টের কাছে প্রতিক্রিয়া হিসাবে 502 Bad Gateway পাঠাবে।

সমাধান

সর্বদা নিশ্চিত করুন যে টার্গেট সার্ভারটি আপনার প্রয়োজন অনুযায়ী সঠিকভাবে কনফিগার করা আছে।

উপরে বর্ণিত উদাহরণটির ক্ষেত্রে, আপনি যদি একটি সুরক্ষিত (HTTPS/SSL) টার্গেট সার্ভারে রিকোয়েস্ট পাঠাতে চান, তাহলে আপনাকে enabled ফ্ল্যাগটি ` true সেট করে ` SSLInfo অ্যাট্রিবিউটগুলো অন্তর্ভুক্ত করতে হবে। যদিও টার্গেট এন্ডপয়েন্ট ডেফিনিশনের মধ্যেই টার্গেট সার্ভারের জন্য SSLInfo অ্যাট্রিবিউটগুলো যোগ করার অনুমতি আছে, তবে যেকোনো বিভ্রান্তি এড়ানোর জন্য টার্গেট সার্ভার ডেফিনিশনের অংশ হিসেবেই SSLInfo অ্যাট্রিবিউটগুলো যোগ করার পরামর্শ দেওয়া হয়।

1. যদি ব্যাকএন্ড পরিষেবাটির জন্য একমুখী SSL যোগাযোগের প্রয়োজন হয়, তাহলে:
   1. আপনাকে TargetServer সংজ্ঞায় TLS/SSL সক্রিয় করতে হবে। এর জন্য SSLInfo অ্যাট্রিবিউট অন্তর্ভুক্ত করুন যেখানে enabled ফ্ল্যাগটি true-তে সেট করা থাকবে, যেমনটি নিচে দেখানো হয়েছে:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. আপনি যদি Edge-এ টার্গেট সার্ভারের সার্টিফিকেটটি ভ্যালিডেট করতে চান, তাহলে নিচে দেখানো অনুযায়ী ট্রাস্টস্টোরটিও (যেখানে টার্গেট সার্ভারের সার্টিফিকেটটি রয়েছে) অন্তর্ভুক্ত করতে হবে:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. যদি ব্যাকএন্ড পরিষেবাটির দ্বিমুখী SSL যোগাযোগের প্রয়োজন হয়, তাহলে:
   1. আপনাকে SSLInfo অ্যাট্রিবিউটগুলোতে ClientAuthEnabled , Keystore , KeyAlias , এবং Truststore ফ্ল্যাগগুলো নিচে দেখানো অনুযায়ী যথাযথভাবে সেট করতে হবে:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

তথ্যসূত্র

ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালান্সিং

কারণ: ব্যাকএন্ড সার্ভার থেকে EOFException

ব্যাকএন্ড সার্ভার হঠাৎ করে EOF (এন্ড অফ ফাইল) পাঠাতে পারে।

রোগ নির্ণয়

1. 502 এররের মেসেজ আইডি, ফল্ট কোড এবং ফল্ট সোর্স নির্ধারণ করতে এপিআই মনিটরিং , ট্রেস টুল বা এনজিআইএনএক্স অ্যাক্সেস লগ ব্যবহার করুন।
2. মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) চেক করুন এবং অনুসন্ধান করে দেখুন যে নির্দিষ্ট API-টির জন্য আপনার eof unexpected আছে কিনা, অথবা API অনুরোধটির জন্য আপনার কাছে কোনো অনন্য messageid আছে কিনা, তাহলে আপনি সেটি অনুসন্ধান করতে পারবেন।

   মেসেজ প্রসেসর লগ থেকে প্রাপ্ত নমুনা এক্সেপশন স্ট্যাক ট্রেস

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   উপরের উদাহরণে, আপনি দেখতে পাচ্ছেন যে, মেসেজ প্রসেসর যখন ব্যাকএন্ড সার্ভার থেকে একটি রেসপন্স পড়ার চেষ্টা করছিল, তখন java.io.EOFException: eof unexpected error ঘটেছে। এই এক্সেপশনটি নির্দেশ করে যে ফাইলের শেষ (EOF) বা স্ট্রিমের শেষ প্রান্তে অপ্রত্যাশিতভাবে পৌঁছে যাওয়া হয়েছে।

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

3. আপনার ব্যাকএন্ড সার্ভারের লগ পরীক্ষা করে দেখুন, সেখানে এমন কোনো ত্রুটি বা তথ্য আছে কি না, যার কারণে ব্যাকএন্ড সার্ভারটি হঠাৎ করে সংযোগ বিচ্ছিন্ন করে দিয়েছে। যদি কোনো ত্রুটি বা তথ্য খুঁজে পান, তাহলে 'রেজোলিউশন' (Resolution) অংশে গিয়ে আপনার ব্যাকএন্ড সার্ভারে সমস্যাটি যথাযথভাবে সমাধান করুন।
4. যদি আপনার ব্যাকএন্ড সার্ভারে কোনো ত্রুটি বা তথ্য খুঁজে না পান, তাহলে মেসেজ প্রসেসরগুলো থেকে tcpdump আউটপুট সংগ্রহ করুন:
   1. আপনার ব্যাকএন্ড সার্ভার হোস্টের যদি একটিমাত্র আইপি অ্যাড্রেস থাকে, তাহলে নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. আপনার ব্যাকএন্ড সার্ভার হোস্টের একাধিক আইপি অ্যাড্রেস থাকলে, নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      সাধারণত, এই ত্রুটিটি ঘটে কারণ মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে অনুরোধ পাঠানোর সাথে সাথেই সার্ভারটি [FIN,ACK] দিয়ে সাড়া দেয়।

5. নিম্নলিখিত tcpdump উদাহরণটি বিবেচনা করুন।

   502 Bad Gateway Error ( UnexpectedEOFAtTarget ) ঘটলে নেওয়া tcpdump নমুনা।

   

6. TCPDump আউটপুট থেকে, আপনি নিম্নলিখিত ঘটনাক্রম লক্ষ্য করেন:
   1. প্যাকেট 985 এ, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে এপিআই অনুরোধটি পাঠায়।
   2. প্যাকেট 986 এ, ব্যাকএন্ড সার্ভার অবিলম্বে [FIN,ACK] দিয়ে সাড়া দেয়।
   3. প্যাকেট 987 এ, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারকে [FIN,ACK] দিয়ে সাড়া দেয়।
   4. অবশেষে উভয় দিক থেকে [ACK] এবং [RST] এর মাধ্যমে সংযোগগুলো বন্ধ করা হয়।
   5. যেহেতু ব্যাকএন্ড সার্ভার [FIN,ACK] পাঠায়, তাই আপনি মেসেজ প্রসেসরে java.io.EOFException: eof unexpected exception এই এক্সেপশনটি পান।
7. ব্যাকএন্ড সার্ভারে নেটওয়ার্ক সমস্যা থাকলে এমনটা হতে পারে। বিষয়টি আরও খতিয়ে দেখতে আপনার নেটওয়ার্ক অপারেশনস টিমের সাথে যোগাযোগ করুন।

সমাধান

ব্যাকএন্ড সার্ভারে সমস্যাটি যথাযথভাবে সমাধান করুন।

যদি সমস্যাটি অব্যাহত থাকে এবং 502 Bad Gateway Error সমাধানে আপনার সাহায্যের প্রয়োজন হয় অথবা আপনার সন্দেহ হয় যে এটি Edge-এর অভ্যন্তরীণ কোনো সমস্যা, তাহলে Apigee Edge Support-এর সাথে যোগাযোগ করুন।

কারণ: ভুলভাবে কনফিগার করা কিপ অ্যালাইভ টাইমআউট

502 ত্রুটির কারণ এটি কিনা তা নির্ণয় করার আগে, অনুগ্রহ করে নিম্নলিখিত ধারণাগুলি পড়ে নিন।

Apigee-তে স্থায়ী সংযোগ

Apigee ডিফল্টরূপে (এবং HTTP/1.1 স্ট্যান্ডার্ড অনুসরণ করে) টার্গেট ব্যাকএন্ড সার্ভারের সাথে যোগাযোগের জন্য পারসিস্টেন্ট কানেকশন ব্যবহার করে। পারসিস্টেন্ট কানেকশন পারফরম্যান্স বাড়াতে পারে, কারণ এটি আগে থেকে প্রতিষ্ঠিত TCP এবং (প্রযোজ্য ক্ষেত্রে) TLS/SSL কানেকশনকে পুনরায় ব্যবহার করার সুযোগ দেয়, যা ল্যাটেন্সি ওভারহেড কমিয়ে দেয়। একটি কানেকশন কতক্ষণ ধরে পারসিস্টেন্ট থাকবে , তা keep alive timeout ( keepalive.timeout.millis ) নামক একটি প্রপার্টির মাধ্যমে নিয়ন্ত্রণ করা হয়।

ব্যাকএন্ড সার্ভার এবং Apigee মেসেজ প্রসেসর উভয়ই একে অপরের সাথে সংযোগ খোলা রাখতে 'কিপ অ্যালাইভ টাইমআউট' ব্যবহার করে। 'কিপ অ্যালাইভ টাইমআউট'-এর নির্দিষ্ট সময়ের মধ্যে কোনো ডেটা না এলে, ব্যাকএন্ড সার্ভার বা মেসেজ প্রসেসর অপর পক্ষের সাথে সংযোগটি বন্ধ করে দিতে পারে।

Apigee-তে একটি মেসেজ প্রসেসরে ডেপ্লয় করা API প্রক্সিগুলোর জন্য, ডিফল্টরূপে, একটি 'কিপ অ্যালাইভ টাইমআউট' 60s সেট করা থাকে, যদি না তা ওভাররাইড করা হয়। 60s ধরে কোনো ডেটা না পেলে, Apigee ব্যাকএন্ড সার্ভারের সাথে সংযোগটি বন্ধ করে দেবে। ব্যাকএন্ড সার্ভারও একটি 'কিপ অ্যালাইভ টাইমআউট' বজায় রাখবে, এবং এর মেয়াদ শেষ হয়ে গেলে ব্যাকএন্ড সার্ভারটি মেসেজ প্রসেসরের সাথে সংযোগটি বন্ধ করে দেবে।

ভুল কিপ অ্যালাইভ টাইমআউট কনফিগারেশনের প্রভাব

যদি Apigee অথবা ব্যাকএন্ড সার্ভার ভুল কিপ অ্যালাইভ টাইমআউট দিয়ে কনফিগার করা থাকে, তাহলে একটি রেস কন্ডিশন তৈরি হয়, যার ফলে কোনো রিসোর্সের অনুরোধের জবাবে ব্যাকএন্ড সার্ভার একটি অপ্রত্যাশিত End Of File (FIN) পাঠায়।

উদাহরণস্বরূপ, যদি এপিআই প্রক্সি বা মেসেজ প্রসেসরের মধ্যে কিপ অ্যালাইভ টাইমআউট এমন একটি মান দিয়ে কনফিগার করা থাকে যা আপস্ট্রিম ব্যাকএন্ড সার্ভারের টাইমআউটের চেয়ে বেশি বা সমান, তাহলে নিম্নলিখিত রেস কন্ডিশনটি ঘটতে পারে। অর্থাৎ, যদি মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারের কিপ অ্যালাইভ টাইমআউটের থ্রেশহোল্ডের খুব কাছাকাছি সময় পর্যন্ত কোনো ডেটা না পায়, তাহলে একটি রিকোয়েস্ট আসে এবং বিদ্যমান কানেকশনটি ব্যবহার করে ব্যাকএন্ড সার্ভারে পাঠানো হয়। এর ফলে অপ্রত্যাশিত EOF ত্রুটির কারণে 502 Bad Gateway দেখা দিতে পারে, যা নিচে ব্যাখ্যা করা হলো:

1. ধরা যাক, মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভার উভয় স্থানেই কিপ অ্যালাইভ টাইমআউট ৬০ সেকেন্ড সেট করা আছে এবং নির্দিষ্ট মেসেজ প্রসেসরটি দ্বারা পূর্ববর্তী অনুরোধটি পরিবেশিত হওয়ার ৫৯ সেকেন্ড পর পর্যন্ত কোনো নতুন অনুরোধ আসেনি।
2. মেসেজ প্রসেসরটি বিদ্যমান সংযোগটি ব্যবহার করে ৫৯তম সেকেন্ডে আসা অনুরোধটি প্রসেস করে (যেহেতু কিপ অ্যালাইভ টাইমআউট এখনও শেষ হয়নি) এবং অনুরোধটি ব্যাকএন্ড সার্ভারে পাঠিয়ে দেয়।
3. তবে, অনুরোধটি ব্যাকএন্ড সার্ভারে পৌঁছানোর আগেই ব্যাকএন্ড সার্ভারে কিপ অ্যালাইভ টাইমআউটের সীমা অতিক্রম করে গেছে।
4. মেসেজ প্রসেসরের কোনো রিসোর্সের জন্য করা অনুরোধটি প্রক্রিয়াধীন রয়েছে, কিন্তু ব্যাকএন্ড সার্ভারটি মেসেজ প্রসেসরকে একটি FIN প্যাকেট পাঠিয়ে সংযোগটি বন্ধ করার চেষ্টা করছে।
5. মেসেজ প্রসেসর ডেটা পাওয়ার জন্য অপেক্ষা করার সময়, এর পরিবর্তে অপ্রত্যাশিত FIN পায় এবং সংযোগটি বিচ্ছিন্ন হয়ে যায়।
6. এর ফলে একটি Unexpected EOF ঘটে এবং পরবর্তীতে মেসেজ প্রসেসর ক্লায়েন্টের কাছে একটি 502 ফেরত পাঠায়।

এই ক্ষেত্রে, আমরা লক্ষ্য করেছি যে মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভার উভয় স্থানেই ৬০ সেকেন্ডের একই কিপ অ্যালাইভ টাইমআউট মান কনফিগার করা থাকায় 502 ত্রুটিটি ঘটেছে। একইভাবে, ব্যাকএন্ড সার্ভারের চেয়ে মেসেজ প্রসেসরে কিপ অ্যালাইভ টাইমআউটের জন্য উচ্চতর মান কনফিগার করা হলেও এই সমস্যাটি ঘটতে পারে।

রোগ নির্ণয়

1. আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন:
   1. এপিআই মনিটরিং বা ট্রেস টুল ব্যবহার করুন (যেমনটি সাধারণ রোগ নির্ণয়ের ধাপগুলিতে ব্যাখ্যা করা হয়েছে) এবং যাচাই করুন যে আপনার নিম্নলিখিত উভয় সেটিংই রয়েছে:
      • ত্রুটি কোড: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • ত্রুটির উৎস: target
   2. আরও তদন্তের জন্য 'Using tcpdump' অংশে যান।
2. আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন:
   1. 502 এররের জন্য মেসেজ আইডি, ফল্ট কোড এবং ফল্ট সোর্স নির্ধারণ করতে ট্রেস টুল অথবা NGINX অ্যাক্সেস লগ ব্যবহার করুন।
   2. মেসেজ প্রসেসর লগে মেসেজ আইডিটি অনুসন্ধান করুন।
      ( /opt/apigee/var/log/edge-message-processor/logs/system.log )
   3. আপনি নিচে দেখানো java.io.EOFEXception: eof unexpected দেখতে পাবেন:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. java.io.EOFException: eof unexpected ত্রুটিটি নির্দেশ করে যে, মেসেজ প্রসেসরটি ব্যাকএন্ড সার্ভার থেকে একটি প্রতিক্রিয়া পড়ার জন্য অপেক্ষা করার সময় একটি EOF পেয়েছে।
   5. উপরের ত্রুটি বার্তায় useCount=7 অ্যাট্রিবিউটটি নির্দেশ করে যে মেসেজ প্রসেসর এই সংযোগটি প্রায় সাতবার পুনঃব্যবহার করেছিল এবং bytesWritten=159 অ্যাট্রিবিউটটি নির্দেশ করে যে মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে 159 বাইটের অনুরোধ পেলোড পাঠিয়েছিল। কিন্তু অপ্রত্যাশিত EOF ঘটার সময় এটি ফেরতে শূন্য বাইট পেয়েছিল।

   6. এতে বোঝা যায় যে, মেসেজ প্রসেসরটি একই কানেকশন একাধিকবার ব্যবহার করেছিল এবং এইবার এটি ডেটা পাঠালেও, কোনো ডেটা পাওয়ার আগেই অল্প সময়ের মধ্যে একটি EOF এন্ড অফ ফিল্ড) পেয়েছিল। এর মানে হলো, এই সম্ভাবনা খুব বেশি যে ব্যাকএন্ড সার্ভারের কিপ অ্যালাইভ টাইমআউটটি এপিআই প্রক্সিতে সেট করা টাইমআউটের চেয়ে কম বা সমান।

      নিচে বর্ণিত পদ্ধতি অনুযায়ী আপনি tcpdump এর সাহায্যে আরও তদন্ত করতে পারেন।

tcpdump ব্যবহার করে

1. নিম্নলিখিত কমান্ড ব্যবহার করে ব্যাকএন্ড সার্ভারে একটি tcpdump ক্যাপচার করুন:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. ক্যাপচার করা tcpdump বিশ্লেষণ করুন:

   এখানে একটি নমুনা tcpdump আউটপুট দেওয়া হলো:

   

   উপরের নমুনা tcpdump টিতে আপনি নিম্নলিখিত বিষয়গুলো দেখতে পাবেন:

   1. প্যাকেট 5992, ব্যাকএন্ড সার্ভার একটি GET অনুরোধ পেয়েছে।
   2. প্যাকেট 6064 এ এটি 200 OK.
   3. প্যাকেট 6084 এ, ব্যাকএন্ড সার্ভার আরেকটি GET অনুরোধ পেয়েছে।
   4. প্যাকেট 6154 তে এটি 200 OK দিয়ে সাড়া দেয়।
   5. প্যাকেট 6228 এ, ব্যাকএন্ড সার্ভার তৃতীয় একটি GET অনুরোধ পেয়েছে।
   6. এইবার, ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরকে একটি FIN, ACK (প্যাকেট 6285 ) ফেরত পাঠায়, যার মাধ্যমে সংযোগটি বন্ধ করার প্রক্রিয়া শুরু হয়।

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

Apigee এবং ব্যাকএন্ড সার্ভারে কিপ অ্যালাইভ টাইমআউট তুলনা করুন

1. ডিফল্টরূপে, Apigee 'keep alive timeout' প্রপার্টির জন্য ৬০ সেকেন্ডের একটি মান ব্যবহার করে।

2. তবে, এমন হতে পারে যে আপনি এপিআই প্রক্সিতে ডিফল্ট মানটি ওভাররাইড করে ফেলেছেন। যে এপিআই প্রক্সিটি 502 এরর দিচ্ছে, সেটির নির্দিষ্ট TargetEndpoint ডেফিনিশনটি পরীক্ষা করে আপনি এটি যাচাই করতে পারেন।

   নমুনা টার্গেটএন্ডপয়েন্ট কনফিগারেশন:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   উপরের উদাহরণে, `keep alive timeout` প্রপার্টিটিকে ৩০ সেকেন্ড ( 30000 মিলিসেকেন্ড) মান দিয়ে ওভাররাইড করা হয়েছে।

3. এরপর, আপনার ব্যাকএন্ড সার্ভারে কনফিগার করা 'keep alive timeout' প্রপার্টিটি পরীক্ষা করুন। ধরা যাক, আপনার ব্যাকএন্ড সার্ভারটি 25 seconds একটি মান দিয়ে কনফিগার করা আছে।
4. যদি আপনি দেখেন যে উপরের উদাহরণের মতো Apigee-এর keep alive timeout প্রপার্টির মান ব্যাকএন্ড সার্ভারের keep alive timeout প্রপার্টির মানের চেয়ে বেশি, তাহলে সেটাই 502 এররের কারণ।

সমাধান

নিশ্চিত করুন যে Apigee-তে (API Proxy এবং Message Processor কম্পোনেন্টে) keep alive timeout প্রপার্টিটি ব্যাকএন্ড সার্ভারের তুলনায় সর্বদা কম থাকে।

1. ব্যাকএন্ড সার্ভারে কিপ অ্যালাইভ টাইমআউটের জন্য নির্ধারিত মানটি নির্ধারণ করুন।
2. " মেসেজ প্রসেসরে কিপ অ্যালাইভ টাইমআউট কনফিগার করা" অংশে বর্ণিত ধাপগুলো অনুসরণ করে, এপিআই প্রক্সি বা মেসেজ প্রসেসরে কিপ অ্যালাইভ টাইমআউট প্রপার্টির জন্য একটি উপযুক্ত মান কনফিগার করুন, যাতে এই মানটি ব্যাকএন্ড সার্ভারে সেট করা মানের চেয়ে কম হয়।

যদি সমস্যাটি এখনও থেকে যায়, তাহলে 'অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করুন' অংশে যান।

সর্বোত্তম অনুশীলন

এই ধরনের রেস কন্ডিশন এবং 502 এরর এড়ানোর জন্য, ডাউনস্ট্রিম কম্পোনেন্টগুলোতে আপস্ট্রিম সার্ভারগুলোতে কনফিগার করা কিপ অ্যালাইভ টাইমআউট থ্রেশহোল্ডের চেয়ে সর্বদা কম রাখার জন্য দৃঢ়ভাবে পরামর্শ দেওয়া হয়। প্রতিটি ডাউনস্ট্রিম হপ প্রতিটি আপস্ট্রিম হপের চেয়ে কম হওয়া উচিত। Apigee Edge-এ, নিম্নলিখিত নির্দেশিকাগুলো ব্যবহার করা একটি ভালো অভ্যাস:

1. ক্লায়েন্ট কিপ অ্যালাইভ টাইমআউট এজ রাউটার কিপ অ্যালাইভ টাইমআউটের চেয়ে কম হওয়া উচিত।
2. এজ রাউটারের কিপ অ্যালাইভ টাইমআউট মেসেজ প্রসেসরের কিপ অ্যালাইভ টাইমআউটের চেয়ে কম হওয়া উচিত।
3. মেসেজ প্রসেসরের কিপ অ্যালাইভ টাইমআউট টার্গেট সার্ভারের কিপ অ্যালাইভ টাইমআউটের চেয়ে কম হওয়া উচিত।
4. Apigee-এর আগে বা পরে যদি অন্য কোনো হপ থাকে, তাহলেও একই নিয়ম প্রযোজ্য হবে। আপস্ট্রিমের সাথে সংযোগ বিচ্ছিন্ন করার দায়িত্ব সবসময় ডাউনস্ট্রিম ক্লায়েন্টের ওপরই ছেড়ে দেওয়া উচিত।

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

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

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

• সংস্থার নাম
• পরিবেশের নাম
• এপিআই প্রক্সি নাম
• 502 ত্রুটিটি পুনরুৎপাদন করার জন্য সম্পূর্ণ curl কমান্ডটি ব্যবহার করুন।
• 502 Bad Gateway - Unexpected EOF ত্রুটিযুক্ত অনুরোধগুলি ধারণকারী ট্রেস ফাইল
• যদি বর্তমানে 502 ত্রুটি না ঘটে থাকে, তাহলে অতীতে যখন 502 ত্রুটি ঘটেছিল সেই সময়কাল এবং টাইমজোনের তথ্য প্রদান করুন।

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

• ব্যর্থ অনুরোধগুলির জন্য সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে।
• যেসব সংস্থা, পরিবেশের নাম এবং এপিআই প্রক্সি নামের ক্ষেত্রে আপনি 502 ত্রুটি দেখতে পাচ্ছেন
• এপিআই প্রক্সি বান্ডেল
• 502 Bad Gateway - Unexpected EOF ত্রুটিযুক্ত অনুরোধগুলি ধারণকারী ট্রেস ফাইল
• NGINX অ্যাক্সেস লগ
  /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
• মেসেজ প্রসেসর লগ
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• টাইমজোন তথ্যসহ সেই সময়কাল যখন 502 ত্রুটিগুলো ঘটেছিল।
• ত্রুটি ঘটার সময় মেসেজ প্রসেসর বা ব্যাকএন্ড সার্ভার, অথবা উভয় স্থান থেকে Tcpdumps সংগ্রহ করা হয়েছিল।