504 Gateway Timeout

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

علامت

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

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

پیام‌های خطا

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

HTTP/1.1 504 Gateway Timeout

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

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

چه چیزی باعث وقفه‌های دروازه می‌شود؟

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

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

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

وقوع تایم اوت جزئیات
زمان انقضا در پردازشگر پیام رخ می‌دهد
  • سرور Backend در مدت زمان مشخص شده در پردازنده پیام، به پردازنده پیام پاسخ نمی‌دهد.
  • پردازنده پیام مهلتش تمام می‌شود و وضعیت پاسخ را با عنوان 504 Gateway Timeout به روتر ارسال می‌کند.
وقفه زمانی در روتر رخ می‌دهد
  • پردازشگر پیام در مدت زمان مشخص شده در روتر به روتر پاسخ نمی‌دهد.
  • روتر مهلتش تمام می‌شود و وضعیت پاسخ را با عنوان 504 Gateway Timeout به برنامه کلاینت ارسال می‌کند.
وقوع تایم اوت در برنامه کلاینت
  • روتر در مدت زمان مشخص شده در زمان انقضا به برنامه کلاینت پاسخ نمی‌دهد.
  • برنامه کلاینت مهلتش تمام می‌شود و وضعیت پاسخ را با عنوان 504 Gateway Timeout به کاربر نهایی پایان می‌دهد.

علل احتمالی

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

علت جزئیات مراحل داده شده برای
سرور بک‌اند کند سرور بک‌اند که درخواست API را پردازش می‌کند، به دلیل بار زیاد یا عملکرد ضعیف، بسیار کند است. کاربران فضای ابری عمومی و خصوصی
پردازش کند درخواست API توسط Edge به دلیل بار زیاد یا عملکرد ضعیف، Edge زمان زیادی برای پردازش درخواست API صرف می‌کند.

سرور بک‌اند کند

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

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

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

سناریوی شماره ۱: زمان پردازش پیام قبل از پاسخ سرور بک‌اند به پایان می‌رسد

تشخیص

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

روش شماره ۱ با استفاده از ردیابی

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

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

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

در ردیابی بالا، پردازشگر پیام پس از ۵۵۰۰۲ میلی‌ثانیه به دلیل عدم پاسخگویی سرور پشتیبان، دچار وقفه می‌شود.

روش شماره ۲ استفاده از گزارش‌های پردازشگر پیام

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

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

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

    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

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

    این را بررسی کنید: چگونه زمان انقضا در پردازنده پیام کنترل می‌شود؟

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

وضوح تصویر

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

سناریوی شماره ۲ - زمان‌بندی روتر قبل از پاسخ پردازنده پیام/سرور backend به پایان می‌رسد

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

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

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

    زمان انقضا در روتر مهلت زمانی در پردازنده پیام زمان انقضا در پروکسی API
    ۵۷ ثانیه ۵۵ ثانیه ۱۲۰ ثانیه

    اما io.timeout.millis در API Proxy روی ۱۲۰ ثانیه تنظیم شده است:

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

    سپس، پردازنده پیام پس از ۵۵ ثانیه مهلت زمانی خود را از دست نمی‌دهد، حتی اگر مقدار مهلت زمانی آن (۵۵ ثانیه) کمتر از مقدار مهلت زمانی روی روتر (۵۷ ثانیه) باشد. دلیل این امر این است که مقدار مهلت زمانی ۵۵ ثانیه در پردازنده پیام توسط مقدار ۱۲۰ ثانیه‌ای که در پروکسی API تنظیم شده است، لغو می‌شود. بنابراین مقدار مهلت زمانی پردازنده پیام برای این پروکسی API خاص ۱۲۰ ثانیه خواهد بود.

    از آنجایی که روتر مقدار timeout کمتری (57 ثانیه) در مقایسه با 120 ثانیه تعیین شده در API Proxy دارد، اگر سرور backend پس از 57 ثانیه پاسخ ندهد، روتر timeout خواهد شد.

تشخیص

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

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

    نمونه‌ای از ورودی لاگ NGINX که به دلیل اتمام زمان‌بندی روتر، خطای ۵۰۴ را نشان می‌دهد.

  3. در مثال بالا، به وضعیت 504 در NGINX توجه کنید، شناسه پیام از پردازنده پیام - است و کل زمان سپری شده ۵۷.۰۰۱ ثانیه است. دلیل این امر این است که روتر پس از ۵۷.۰۰۱ ثانیه به پایان رسیده و ما هیچ پاسخی از پردازنده پیام دریافت نکرده‌ایم.
  4. در این حالت، استثنائات Broken Pipe را در گزارش‌های Message Processor ( /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>

این خطا به این دلیل نمایش داده می‌شود که به محض اتمام مهلت زمانی روتر، اتصال با پردازنده پیام (Message Processor) قطع می‌شود. وقتی پردازنده پیام پردازش خود را کامل کرد، سعی می‌کند پاسخ را در روتر بنویسد. از آنجایی که اتصال به روتر از قبل بسته شده است، در پردازنده پیام Broken Pipe exception مواجه می‌شوید.

انتظار می‌رود این استثنا تحت شرایطی که در بالا توضیح داده شد، مشاهده شود. بنابراین علت اصلی خطای 504 Gateway Timeout همچنان زمان طولانی‌تر پاسخگویی سرور backend است و شما باید به این مشکل رسیدگی کنید.

وضوح تصویر

  1. اگر این یک سرور backend سفارشی است، پس
    1. بررسی کنید که چرا سرور backend مدت زمان زیادی طول می‌کشد تا پاسخ دهد و ببینید آیا می‌توان آن را اصلاح/بهینه‌سازی کرد تا سریع‌تر پاسخ دهد.
    2. اگر امکان اصلاح/بهینه‌سازی سرور backend وجود ندارد یا مشخص است که سرور backend زمان زیادی طول می‌کشد، مقدار timeout را در Router و Message Processor افزایش دهید .

      ایده: مقدار زمان انتظار را برای اجزای مختلف به ترتیب زیر تنظیم کنید:

      اتمام زمان در کلاینت > اتمام زمان در روتر > اتمام زمان در پردازنده پیام > اتمام زمان در پروکسی API

  2. اگر یک سرور بک‌اند NodeJS باشد، آنگاه:
    1. بررسی کنید که آیا کد NodeJS با سرورهای backend دیگری تماس برقرار می‌کند یا خیر و آیا زمان زیادی برای بازگشت پاسخ صرف می‌شود. بررسی کنید که چرا سرورهای backend زمان بیشتری صرف می‌کنند و مشکل را به طور مناسب برطرف کنید.
    2. بررسی کنید که آیا پردازنده‌های پیام (Message Processors) مصرف CPU یا حافظه بالایی دارند یا خیر:
      1. اگر هر یک از پردازنده‌های پیام (Message Processor) مصرف CPU بالایی دارند، با استفاده از دستور زیر هر 30 ثانیه سه نسخه از نخ‌ها (Thread dumps) ایجاد کنید: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. اگر هر یک از پردازنده‌های پیام (Message Processor) با مشکل مصرف بالای حافظه مواجه هستند، با استفاده از دستور زیر یک 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 dumps، heap dump و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log) را ارائه دهید تا به بررسی علت استفاده زیاد از CPU/memory کمک شود.

این را بررسی کنید: چگونه زمان انقضا برای سرورهای Backend NodeJS در Message Processor کنترل می‌شود؟

  • سرور بک‌اند NodeJS در داخل فرآیند JVM پردازنده پیام (Message Processor) اجرا می‌شود. مقدار زمان انتظار برای سرورهای بک‌اند NodeJS از طریق ویژگی http.request.timeout.seconds در فایل nodejs.properties کنترل می‌شود. این ویژگی به طور پیش‌فرض روی 0 تنظیم شده است، یعنی زمان انتظار به طور پیش‌فرض برای همه پروکسی‌های API که متعلق به سازمانی هستند که توسط این پردازنده پیام (Message Processor) سرویس‌دهی می‌شود، غیرفعال است. بنابراین حتی اگر یک سرور بک‌اند NodeJS زمان زیادی طول بکشد، پردازنده پیام (Message Processor) زمان انتظار را از دست نخواهد داد.
  • با این حال، اگر سرور بک‌اند NodeJS زمان زیادی طول بکشد و اگر زمان صرف شده توسط درخواست API > 57 ثانیه باشد، روتر دچار timeout می‌شود و خطای 504 Gateway Timeout به کلاینت ارسال می‌کند.

سناریوی شماره ۳ - زمان اجرای برنامه کلاینت قبل از پاسخ روتر/پردازشگر پیام/سرور backend به پایان می‌رسد.

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

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

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

    مهلت زمانی روی کلاینت زمان انقضا در روتر مهلت زمانی در پردازنده پیام
    ۵۰ ثانیه ۵۷ ثانیه ۵۵ ثانیه

    در این حالت، کل زمان موجود برای دریافت پاسخ برای یک درخواست API از طریق Edge کمتر از ۵۰ ثانیه است. این شامل زمان صرف شده برای ارسال یک درخواست API، پردازش درخواست توسط Edge (روتر، پردازنده پیام)، ارسال درخواست به سرور backend (در صورت وجود)، پردازش درخواست توسط backend و ارسال پاسخ، پردازش پاسخ توسط Edge و در نهایت ارسال آن به کلاینت می‌شود.

    اگر روتر ظرف ۵۰ ثانیه به کلاینت پاسخ ندهد، کلاینت دچار timeout شده و ارتباط با روتر را قطع می‌کند. کلاینت کد پاسخ 504 را دریافت خواهد کرد.

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

تشخیص

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

    نمونه‌ای از ورودی لاگ NGINX که کد وضعیت ۴۹۹ را نشان می‌دهد

  2. در مثال بالا، توجه داشته باشید که وضعیت 499 در NGINX و کل زمان سپری شده ۵۰.۰۰۱ ثانیه است. این نشان می‌دهد که کلاینت پس از ۵۰.۰۰۱ ثانیه به پایان زمان خود رسیده است.
  3. در این حالت، خطاهای مربوط به خطاهای Broken Pipe Exceptions) را در لاگ‌های پردازنده پیام ( /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. پس از اتمام مهلت زمانی روتر، اتصال با پردازنده پیام (Message Processor) قطع می‌شود. هنگامی که پردازنده پیام پردازش خود را تکمیل کرد، سعی می‌کند پاسخ را در روتر بنویسد. از آنجایی که اتصال به روتر از قبل بسته شده است، در پردازنده پیام Broken Pipe exception مواجه می‌شوید.
  5. این استثنا تحت شرایطی که در بالا توضیح داده شد، قابل انتظار است. بنابراین علت اصلی خطای 504 Gateway Timeout همچنان این است که سرور backend مدت زمان زیادی برای پاسخگویی نیاز دارد و شما باید به این مشکل رسیدگی کنید.

وضوح تصویر

  1. اگر سرور بک‌اند سفارشی شماست، پس:
    1. سرور بک‌اند را بررسی کنید تا مشخص شود چرا بیش از ۵۷ ثانیه طول می‌کشد و ببینید آیا می‌توان آن را اصلاح/بهینه‌سازی کرد تا سریع‌تر پاسخ دهد.
    2. اگر امکان اصلاح/بهینه‌سازی سرور backend وجود ندارد یا اگر می‌دانید که سرور backend زمان زیادی طول خواهد کشید، مقدار timeout را روی روتر و Message Processor افزایش دهید .

      ایده: مقدار زمان انتظار را برای اجزای مختلف به ترتیب زیر تنظیم کنید:

      اتمام زمان در کلاینت > اتمام زمان در روتر > اتمام زمان در پردازنده پیام > اتمام زمان در پروکسی API

  2. اگر بک‌اند NodeJS باشد، آنگاه:
    1. بررسی کنید که آیا کد NodeJS به سرورهای backend دیگری فراخوانی انجام می‌دهد یا خیر و آیا زمان زیادی برای بازگشت آن طول می‌کشد. بررسی کنید که چرا این سرورهای backend زمان بیشتری طول می‌کشند.
    2. بررسی کنید که آیا پردازنده‌های پیام (Message Processors) مصرف بالای CPU یا حافظه را تجربه می‌کنند یا خیر:
      1. اگر یک پردازنده پیام (Message Processor) مصرف CPU بالایی دارد، با استفاده از دستور زیر هر 30 ثانیه سه نسخه پشتیبان از نخ (thread dump) ایجاد کنید: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. اگر یک پردازنده پیام (Message Processor) با مصرف بالای حافظه مواجه است، با استفاده از دستور زیر یک 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 dumps، heap dumps و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log) را در اختیار آنها قرار دهید تا در بررسی علت استفاده زیاد از CPU/memory به آنها کمک کنید.

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

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

    برای مثال، اگر می‌خواهید مقدار timeout را روی ۱۲۰ ثانیه تنظیم کنید، آن را به صورت زیر تنظیم کنید: 

    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

    برای مثال، اگر می‌خواهید مقدار timeout را روی ۱۲۰ ثانیه تنظیم کنید، آن را به صورت زیر تنظیم کنید: 

    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

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

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

تشخیص

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

  8. در مثال بالا، متوجه می‌شوید که اجرای سیاست جاوا اسکریپت به طور غیرمعمولی حدود ۲۴۵ ثانیه طول می‌کشد.

وضوح تصویر

  1. بررسی کنید که آیا سیاستی که مدت زمان زیادی برای پاسخ دادن طول کشیده است، وجود دارد یا خیر و آیا کد سفارشی وجود دارد که ممکن است پردازش آن به زمان زیادی نیاز داشته باشد. اگر چنین کدی وجود دارد، ببینید آیا می‌توانید کد شناسایی شده را اصلاح/بهینه کنید.
  2. اگر کد سفارشی وجود ندارد که ممکن است باعث زمان پردازش بالا شود، بررسی کنید که آیا پردازنده‌های پیام (Message Processors) مصرف بالای CPU یا حافظه را تجربه می‌کنند یا خیر:
    1. اگر هر یک از پردازنده‌های پیام (Message Processor) مصرف CPU بالایی دارند، با استفاده از دستور زیر هر 30 ثانیه سه نسخه از نخ‌ها (Thread dumps) ایجاد کنید: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. اگر هر یک از پردازنده‌های پیام (Message Processor) از حافظه بالایی استفاده می‌کند، با استفاده از دستور زیر یک 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 dumps، heap dumps و Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log) را در اختیار آنها قرار دهید تا در بررسی علت استفاده زیاد از CPU/memory به آنها کمک کنید.

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

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

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