504 Gateway Timeout

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

علامت

برنامه سرویس گیرنده کد وضعیت HTTP 504 را با پیام Gateway Timeout به عنوان پاسخی برای تماس های API دریافت می کند.

کد وضعیت HTTP - خطای 504 Gateway Timeout نشان می دهد که کلاینت در طول اجرای یک API پاسخی به موقع از Edge Gateway یا سرور باطن دریافت نکرده است.

پیام های خطا

برنامه مشتری کد پاسخ زیر را دریافت می کند:

HTTP/1.1 504 Gateway Timeout

در برخی موارد ممکن است پیغام خطای زیر نیز مشاهده شود:

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

علت تایم اوت دروازه چیست؟

مسیر معمولی برای درخواست API از طریق پلتفرم Edge ، Client -> Router -> Message Processor -> Backend Server خواهد بود که در شکل زیر نشان داده شده است:

برنامه کلاینت، روترها و پردازشگرهای پیام در پلتفرم Edge با مقادیر زمان‌بندی مناسب تنظیم شده‌اند. پلتفرم Edge انتظار دارد برای هر درخواست API بر اساس مقادیر زمان‌بندی، پاسخی در بازه زمانی مشخصی ارسال شود. اگر در بازه زمانی مشخص شده پاسخ را دریافت نکنید، 504 Gateway Timeout Error برگردانده می شود.

جدول زیر جزئیات بیشتری را در مورد زمان رخ دادن وقفه زمانی در Edge ارائه می دهد:

علل احتمالی

در Edge، دلایل معمول برای خطای 504 Gateway Timeout عبارتند از:

سرور باطن آهسته

اگر سرور باطن بسیار کند است یا پردازش درخواست API طول می کشد، با خطای 504 Gateway Timeout مواجه خواهید شد. همانطور که در بخش بالا توضیح داده شد، مهلت زمانی ممکن است تحت یکی از سناریوهای زیر رخ دهد:

1. زمان پردازش پیام قبل از پاسخگویی سرور باطن تمام می شود.
2. زمان روتر قبل از پاسخ دادن به پردازشگر پیام/سرور پشتیبان تمام می شود.
3. زمان برنامه کلاینت قبل از پاسخگویی روتر/پردازنده پیام/سرور پشتیبان به پایان می رسد.

بخش‌های زیر نحوه تشخیص و حل مشکل تحت هر یک از این سناریوها را شرح می‌دهند.

سناریوی شماره 1 زمان پردازشگر پیام قبل از پاسخگویی به سرور به پایان می رسد

تشخیص

می‌توانید از روش‌های زیر برای تشخیص اینکه خطای 504 Gateway Timeout به دلیل کندی سرور backend رخ داده است استفاده کنید.

روش شماره 1 با استفاده از Trace

اگر مشکل همچنان فعال است (خطاهای 504 هنوز در حال رخ دادن هستند)، مراحل زیر را دنبال کنید:

1. API آسیب دیده را در Edge UI ردیابی کنید. یا صبر کنید تا خطا رخ دهد یا اگر تماس API دارید، سپس چند تماس API برقرار کنید و خطای 504 Gateway Timeout را دوباره تولید کنید.
2. هنگامی که خطا رخ داد، درخواست خاصی را بررسی کنید که کد پاسخ را 504 نشان می دهد.
3. زمان سپری شده را در هر مرحله بررسی کنید و مرحله ای را که بیشترین زمان در آن سپری شده را یادداشت کنید.
4. اگر بلافاصله پس از یکی از مراحل زیر خطا را با طولانی‌ترین زمان سپری شده مشاهده کردید، نشان می‌دهد که سرور باطن کند است یا زمان زیادی برای پردازش درخواست نیاز دارد:
   • درخواست به سرور مورد نظر ارسال شد
   • خط مشی ServiceCallout

موارد زیر نمونه‌ای از Trace را ارائه می‌دهند که نشان می‌دهد سرور باطن حتی پس از 55 ثانیه پاسخ نمی‌دهد و منجر به خطای 504 Gateway Timeout می‌شود:

در ردیابی بالا، پردازشگر پیام پس از 55002 میلی ثانیه به پایان می رسد زیرا سرور باطن پاسخ نمی دهد.

روش شماره 2 با استفاده از گزارش های پردازشگر پیام

1. گزارش پردازشگر پیام را بررسی کنید ( /opt/apigee/var/log/edge-message-processor/logs/system.log )

2. اگر خطاهای Gateway Timeout و onTimeoutRead برای درخواست پروکسی API خاص در زمان خاص پیدا کردید، نشان می‌دهد که پردازشگر پیام به پایان رسیده است.

   نمونه گزارش پردازشگر پیام که خطای زمان پایان دروازه را نشان می دهد

   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
   

   در گزارش پردازشگر پیام بالا، متوجه می‌شوید که سرور باطنی که با آدرس IP XX.XX.XX.XX نشان داده شده است، حتی پس از 55 ثانیه پاسخ نداد ( lastIO=55000ms ). در نتیجه، پردازشگر پیام به پایان رسید و خطای 504 Gateway Timeout را ارسال کرد.

   این را بررسی کنید: مهلت زمانی در پردازشگر پیام چگونه کنترل می شود؟ چگونه تایم اوت در پردازشگر پیام کنترل می شود. پردازشگرهای پیام معمولاً با مقدار وقفه پیش‌فرض 55 ثانیه از طریق ویژگی HTTPTransport.io.timeout.millis تنظیم می‌شوند. این مقدار مهلت زمانی برای همه پراکسی‌های API که متعلق به سازمانی است که توسط این پردازشگر پیام ارائه می‌شود، قابل اجرا است. اگر سرور باطن در عرض 55 ثانیه پاسخ ندهد، پردازشگر پیام به پایان می رسد و خطای 504 Gateway Timeout برای مشتری ارسال می کند. مقدار زمان تعیین شده در پردازشگر پیام را می توان با ویژگی io.timeout.millis مشخص شده در پروکسی API لغو کرد . این مقدار وقفه برای یک پروکسی API خاص که در آن ویژگی ذکر شده در بالا مشخص شده است، قابل اعمال است. به عنوان مثال، اگر io.timeout.millis روی 10 ثانیه در پروکسی API تنظیم شده باشد، از مقدار 10 ثانیه برای این پروکسی API خاص استفاده خواهد شد. اگر سرور باطن در عرض 10 ثانیه برای پروکسی API خاص پاسخ ندهد، پردازشگر پیام به پایان می رسد و خطای 504 Gateway Timeout برای مشتری ارسال می کند.

قطعنامه

1. بررسی کنید که چرا سرور بک‌اند بیش از 55 ثانیه طول می‌کشد و ببینید آیا می‌توان آن را برای پاسخگویی سریع‌تر برطرف کرد یا بهینه کرد.
2. اگر امکان تعمیر/بهینه سازی سرور پشتیبان وجود ندارد یا مشخص است که سرور باطن زمان بیشتری نسبت به زمان تنظیم شده زمان می برد، مقدار وقفه را در روتر و پردازشگر پیام به مقدار مناسب افزایش دهید .

سناریوی شماره 2 - زمان روتر قبل از پاسخ دادن به پردازشگر پیام/سرور پشتیبان تمام می شود

اگر تایم روتر قبل از پاسخ دادن به پردازشگر پیام/سرور پشتیبان تمام شود، ممکن است خطاهای 504 Gateway Timeout دریافت کنید. این می تواند تحت یکی از شرایط زیر رخ دهد:

• مقدار زمان تعیین شده روی روتر کوتاهتر از مقدار تعیین شده در پردازشگر پیام است. به عنوان مثال، فرض کنید تایم اوت در روتر 50 ثانیه است، در حالی که پردازشگر پیام 55 ثانیه است.

  وقفه در روتر	وقفه در پردازشگر پیام
  50 ثانیه	55 ثانیه

• با استفاده از ویژگی io.timeout.millis که در پیکربندی نقطه پایانی هدف پروکسی API تنظیم شده است، مقدار مهلت در پردازشگر پیام با مقدار زمان پایان بالاتر لغو می شود:

  به عنوان مثال، اگر مقادیر مهلت زمانی زیر تنظیم شوند:

  وقفه در روتر	وقفه در پردازشگر پیام	مهلت زمانی در پروکسی API
  57 ثانیه	55 ثانیه	120 ثانیه

  اما io.timeout.millis روی 120 ثانیه در پروکسی API تنظیم شده است:

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

  سپس، پردازشگر پیام پس از 55 ثانیه مهلت زمانی را طی نمی کند، حتی اگر مقدار وقفه آن (55 ثانیه) کمتر از مقدار وقفه در روتر (57 ثانیه) باشد. این به این دلیل است که مقدار وقفه 55 ثانیه در پردازشگر پیام با مقدار 120 ثانیه که در پروکسی API تنظیم شده است لغو می شود. بنابراین مقدار زمان وقفه پردازشگر پیام برای این پروکسی API خاص 120 ثانیه خواهد بود.

  از آنجایی که روتر در مقایسه با 120 ثانیه که در پروکسی API تنظیم شده است، مقدار تایم اوت کمتری (57 ثانیه) دارد، در صورتی که سرور باطن پس از 57 ثانیه پاسخ ندهد، روتر مهلت زمانی خواهد داشت.

تشخیص

1. گزارش دسترسی NGINX را بررسی کنید ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )

2. اگر زمان روتر قبل از پردازشگر پیام تمام شود، وضعیت 504 را در گزارش های دسترسی NGINX برای درخواست API خاص مشاهده خواهید کرد و message id از پردازشگر پیام به صورت - تنظیم می شود. این به این دلیل است که روتر هیچ پاسخی از پردازشگر پیام در مدت زمان تعیین شده روی روتر دریافت نکرد.

   نمونه NGINX Log Entry که 504 را نشان می دهد به دلیل اتمام زمان روتر

   

3. در مثال بالا، به وضعیت 504 در NGINX توجه کنید، شناسه پیام از پردازشگر پیام است - و کل زمان سپری شده 57.001 ثانیه است. این به این دلیل است که زمان روتر پس از 57.001 ثانیه تمام شد و ما هیچ پاسخی از پردازشگر پیام دریافت نکردیم.
4. در این مورد، استثناهای Broken Pipe را در گزارش‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log).

   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. اگر امکان تعمیر/بهینه سازی سرور پشتیبان وجود ندارد یا اینکه یک واقعیت شناخته شده است که سرور باطن زمان زیادی می برد، مقدار وقفه را در روتر و پردازشگر پیام افزایش دهید .

      ایده: مقدار بازه زمانی کامپوننت های مختلف را به ترتیب زیر تنظیم کنید: مهلت زمانی در Client > مهلت زمانی در روتر > مهلت زمانی در پردازشگر پیام > مهلت زمانی در پروکسی API

2. اگر یک سرور پشتیبان NodeJS است، پس:
   1. بررسی کنید که آیا کد NodeJS با سرورهای پشتیبان دیگری تماس برقرار می کند یا خیر و آیا زمان زیادی طول می کشد تا پاسخ داده شود. بررسی کنید که چرا سرورهای پشتیبان زمان بیشتری می برند و مشکل را در صورت لزوم برطرف کنید.
   2. بررسی کنید که آیا پردازنده‌های پیام از CPU یا حافظه بالایی استفاده می‌کنند:
      1. اگر هر یک از پردازشگرهای پیام از CPU بالایی استفاده می کند، با استفاده از دستور زیر، هر 30 ثانیه سه رشته Dump ایجاد کنید:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. اگر هر پردازشگر پیام از حافظه بالایی استفاده می کند، با استفاده از دستور زیر یک heap dump ایجاد کنید:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. با استفاده از دستور زیر، پردازشگر پیام را مجددا راه اندازی کنید. باید CPU و حافظه را پایین بیاورد:

         /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

      4. برای تأیید اینکه آیا مشکل همچنان وجود دارد، تماس‌های API را زیر نظر بگیرید.
      5. با پشتیبانی Apigee Edge تماس بگیرید و گزارش‌های thread dump، heap dump و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log) برای کمک به بررسی علت CPU/حافظه بالا ارائه دهید. استفاده

سناریوی شماره 3 - زمان برنامه کلاینت قبل از پاسخ روتر/پردازنده پیام/سرور پشتیبان تمام می شود

اگر زمان برنامه کلاینت قبل از پاسخگویی سرور باطن تمام شود، ممکن است خطاهای 504 Gateway Timeout دریافت کنید. این وضعیت می تواند اتفاق بیفتد اگر:

1. مقدار زمان تعیین شده در برنامه مشتری کمتر از مقدار زمان تعیین شده در روتر و پردازشگر پیام است:

   به عنوان مثال، اگر مقادیر مهلت زمانی زیر تنظیم شوند:

   مهلت زمانی روی مشتری	وقفه در روتر	وقفه در پردازشگر پیام
   50 ثانیه	57 ثانیه	55 ثانیه

   در این مورد، کل زمان موجود برای دریافت پاسخ برای درخواست API از طریق Edge <= 50 ثانیه است. این شامل زمان صرف شده برای درخواست API، پردازش درخواست توسط Edge (روتر، پردازشگر پیام)، ارسال درخواست به سرور باطن (در صورت وجود)، پردازش درخواست و ارسال پاسخ، Edge پردازش پاسخ است. و در نهایت آن را برای مشتری ارسال می کند.

   اگر روتر ظرف 50 ثانیه به کلاینت پاسخ ندهد، کلاینت تایم اوت می کند و ارتباط با روتر را می بندد. مشتری کد پاسخ 504 را دریافت می کند.

   این باعث می شود NGINX یک کد وضعیت 499 را تنظیم کند که نشان می دهد مشتری اتصال را بسته است.

تشخیص

1. اگر زمان برنامه کلاینت قبل از دریافت پاسخ از روتر تمام شود، ارتباط با روتر را می بندد. در این شرایط، کد وضعیت 499 را در گزارش های دسترسی NGINX برای درخواست API خاص مشاهده خواهید کرد.

   نمونه NGINX Log Entry که کد وضعیت 499 را نشان می دهد
   
   

2. در مثال بالا، توجه داشته باشید که وضعیت 499 در NGINX و کل زمان سپری شده 50.001 ثانیه است. این نشان می دهد که کلاینت پس از 50.001 ثانیه به پایان رسیده است.
3. در این مورد، استثناهای Broken Pipe را در گزارش‌های پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log).
   

   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. سرور پشتیبان را بررسی کنید تا مشخص کنید که چرا بیش از 57 ثانیه طول می کشد و ببینید آیا می توان آن را برای پاسخ سریعتر اصلاح یا بهینه کرد.
   2. اگر امکان تعمیر/بهینه سازی سرور باطن وجود ندارد یا اگر می دانید که سرور باطن زمان زیادی طول می کشد، مقدار وقفه در روتر و پردازشگر پیام را افزایش دهید .
      
      

      ایده: مقدار بازه زمانی کامپوننت های مختلف را به ترتیب زیر تنظیم کنید: مهلت زمانی در Client > مهلت زمانی در روتر > مهلت زمانی در پردازشگر پیام > مهلت زمانی در پروکسی API

2. اگر یک باطن NodeJS است، پس:
   1. بررسی کنید که آیا کد NodeJS با سرورهای پشتیبان دیگری تماس برقرار می کند و آیا بازگشت آن زمان زیادی طول می کشد. بررسی کنید که چرا آن سرورهای پشتیبان زمان بیشتری می گیرند.
   2. بررسی کنید که آیا پردازنده‌های پیام از CPU یا حافظه بالایی استفاده می‌کنند:
      1. اگر یک پردازشگر پیام از CPU بالایی استفاده می کند، با استفاده از دستور زیر، هر 30 ثانیه سه نخ ایجاد کنید:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. اگر یک پردازشگر پیام از حافظه بالایی استفاده می کند، با استفاده از دستور زیر یک heap dump ایجاد کنید:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. با استفاده از دستور زیر، پردازشگر پیام را مجددا راه اندازی کنید. این باید CPU و حافظه را پایین بیاورد:

         /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

      4. برای تأیید اینکه آیا مشکل همچنان وجود دارد، تماس‌های API را زیر نظر بگیرید.
      5. با پشتیبانی Apigee Edge تماس بگیرید و گزارش‌های thread dump، heap dump و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log) برای کمک به آنها در بررسی علت بالا بودن CPU/ فراهم کنید. استفاده از حافظه

مقدار وقفه در روتر و پردازشگر پیام را افزایش دهید

بسته به نیازتان، مقادیر مهلت زمانی را برای تنظیم روی روتر و پردازشگر پیام با دقت انتخاب کنید. مقادیر مهلت زمانی بزرگ را خودسرانه تنظیم نکنید. اگر به کمک نیاز دارید، با پشتیبانی Apigee Edge تماس بگیرید.

روتر

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

   به عنوان مثال، اگر می خواهید مقدار زمان وقفه را 120 ثانیه تنظیم کنید، آن را به صورت زیر تنظیم کنید:

   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 را در دستگاه Message Processor ایجاد کنید، اگر قبلاً وجود نداشته باشد.
2. خط زیر را به این فایل اضافه کنید:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   به عنوان مثال، اگر می خواهید مقدار زمان وقفه را 120 ثانیه تنظیم کنید، آن را به صورت زیر تنظیم کنید:

   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. اگر بیش از یک پردازشگر پیام دارید، مراحل بالا را در همه پردازشگرهای پیام تکرار کنید.

پردازش کند درخواست API توسط Edge

اگر Edge بسیار کند است و/یا پردازش درخواست API زمان زیادی می برد، با خطای 504 Gateway Timeout مواجه خواهید شد.

تشخیص

1. API آسیب دیده را در Edge UI ردیابی کنید.
2. یا صبر کنید تا خطا رخ دهد یا اگر تماس API دارید، سپس چند تماس API برقرار کنید و خطای 504 Gateway Timeout را دوباره تولید کنید.
3. توجه داشته باشید، در این صورت، ممکن است یک پاسخ موفق در Trace مشاهده کنید.
   1. مدت زمان روتر/کلینت به پایان می رسد زیرا پردازشگر پیام در بازه زمانی مشخص شده روی روتر/کلینت (هر کدام کمترین مدت زمان خروج را داشته باشد) پاسخ نمی دهد. با این حال، پردازشگر پیام به پردازش درخواست ادامه می دهد و ممکن است با موفقیت تکمیل شود.
   2. علاوه بر این، مقدار HTTPTransport.io.timeout.millis تنظیم شده در پردازشگر پیام تنها در صورتی فعال می شود که پردازشگر پیام با یک سرور پشتیبان HTTP/HTTPS ارتباط برقرار کند. به عبارت دیگر، زمانی که هر خط‌مشی (غیر از خط‌مشی ServiceCallout) در API Proxy زمان زیادی طول بکشد، این مهلت زمانی فعال نمی‌شود.
4. پس از رخ دادن خطا، درخواست خاصی را که بیشترین زمان سپری شده را دارد بررسی کنید.
5. زمان سپری شده را در هر مرحله بررسی کنید و مرحله ای را که بیشترین زمان صرف شده است را یادداشت کنید.
6. اگر طولانی‌ترین زمان سپری شده را در هر یک از خط‌مشی‌های غیر از خط‌مشی Callout Service مشاهده کنید، این نشان می‌دهد که Edge برای پردازش درخواست زمان زیادی می‌برد.
7. در اینجا یک نمونه ردیابی رابط کاربری وجود دارد که زمان سپری شده بسیار زیاد در خط مشی جاوا اسکریپت را نشان می دهد:

   

8. در مثال بالا، متوجه می‌شوید که خط‌مشی جاوا اسکریپت مدت زمان غیرعادی طولانی 245 ثانیه طول می‌کشد.

قطعنامه

1. بررسی کنید که آیا این خط‌مشی پاسخگویی به آن زمان زیادی طول کشیده است و آیا کد سفارشی وجود دارد که ممکن است پردازش آن به زمان طولانی نیاز داشته باشد. اگر چنین کدی وجود دارد، ببینید آیا می توانید کد شناسایی شده را اصلاح یا بهینه کنید.
2. اگر کد سفارشی وجود ندارد که ممکن است باعث افزایش زمان پردازش شود، بررسی کنید که آیا پردازنده‌های پیام از CPU یا حافظه بالایی استفاده می‌کنند یا خیر:
   1. اگر هر یک از پردازشگرهای پیام از CPU بالایی استفاده می کند، با استفاده از دستور زیر، هر 30 ثانیه سه رشته Dump ایجاد کنید:

      JAVA_HOME/bin/jstack -l PID > FILENAME

   2. اگر هر یک از پردازشگرهای پیام از حافظه بالایی استفاده می کند، با استفاده از دستور زیر یک heap dump ایجاد کنید:

      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

   3. با استفاده از دستور زیر، پردازشگر پیام را مجددا راه اندازی کنید. این باید CPU و حافظه را پایین بیاورد.

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

   4. تماس‌های API را زیر نظر بگیرید و تأیید کنید که آیا مشکل همچنان وجود دارد.
   5. با پشتیبانی Apigee Edge تماس بگیرید و گزارش‌های thread dump، heap dump و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log) برای کمک به آنها در بررسی علت بالا بودن CPU/ فراهم کنید. استفاده از حافظه

با استفاده از API Monitoring مشکلات را تشخیص دهید

API Monitoring شما را قادر می‌سازد تا مناطق مشکل‌دار را به سرعت جدا کنید تا خطاها، عملکرد، و مشکلات تأخیر و منبع آنها، مانند برنامه‌های توسعه‌دهنده، پراکسی‌های API، اهداف باطنی یا پلتفرم API را تشخیص دهید.

یک سناریوی نمونه را طی کنید که نحوه عیب‌یابی مشکلات 5xx با APIهای خود را با استفاده از API Monitoring نشان می‌دهد. برای مثال، ممکن است بخواهید هشداری تنظیم کنید تا زمانی که تعداد 504 کد وضعیت از یک آستانه خاص فراتر رفت، به شما اطلاع داده شود.