504 انتهاء مهلة البوابة

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP 504 مع الرسالة Gateway Timeout كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات.

يشير رمز حالة HTTP للخطأ 504 Gateway Timeout إلى أنّ العميل لم يتلقَّ ردًا في الوقت المناسب من Edge Gateway أو خادم الخلفية أثناء تنفيذ واجهة برمجة تطبيقات.

رسائل الخطأ

يتلقّى تطبيق العميل رمز الاستجابة التالي:

HTTP/1.1 504 Gateway Timeout

في بعض الحالات، قد تظهر أيضًا رسالة الخطأ التالية:

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

ما هي أسباب انتهاء المهلة في البوابة؟

سيكون المسار النموذجي لطلب بيانات من واجهة برمجة التطبيقات من خلال منصة Edge هو العميل -> جهاز التوجيه -> معالج الرسائل -> خادم الخلفية كما هو موضّح في الشكل أدناه:

يتم إعداد تطبيق العميل وأجهزة التوجيه و"معالجات الرسائل" ضمن منصة Edge بقيم مهلة مناسبة. تتوقّع منصة Edge إرسال ردّ خلال فترة زمنية معيّنة لكل طلب بيانات من واجهة برمجة التطبيقات استنادًا إلى قيم المهلة. إذا لم تتلقَّ الردّ خلال الفترة الزمنية المحدّدة، سيتم عرض 504 Gateway Timeout Error.

يقدّم الجدول التالي مزيدًا من التفاصيل حول الحالات التي قد تحدث فيها مهلات في Edge:

الأسباب المحتملة

في Edge، تتضمّن الأسباب الشائعة لظهور الخطأ 504 Gateway Timeout ما يلي:

خادم الخلفية بطيء

إذا كان خادم الخلفية بطيئًا جدًا أو يستغرق وقتًا طويلاً لمعالجة طلب البيانات من واجهة برمجة التطبيقات، سيظهر لك الخطأ 504 Gateway Timeout. كما هو موضّح في القسم أعلاه، يمكن أن يحدث انتهاء المهلة في أحد السيناريوهات التالية:

1. تنتهي مهلة "معالج الرسائل" قبل أن يستجيب خادم الخلفية.
2. تنتهي مهلة جهاز التوجيه قبل أن يستجيب معالج الرسائل/خادم الخلفية.
3. تنتهي مهلة تطبيق العميل قبل أن يستجيب جهاز التوجيه أو معالج الرسائل أو خادم الخلفية.

توضّح الأقسام التالية كيفية تشخيص المشكلة وحلّها في كل سيناريو من هذه السيناريوهات.

السيناريو 1 انتهاء المهلة المحدّدة لمعالج الرسائل قبل أن يستجيب خادم الخلفية

التشخيص

يمكنك اتّباع الإجراءات التالية لتحديد ما إذا كان الخطأ 504 Gateway Timeout قد حدث بسبب بطء خادم الخلفية.

الإجراء 1: استخدام Trace

إذا كانت المشكلة لا تزال نشطة (لا تزال أخطاء 504 تحدث)، اتّبِع الخطوات التالية:

1. تتبُّع واجهة برمجة التطبيقات المتأثّرة في واجهة مستخدم Edge انتظِر حدوث الخطأ، أو إذا كان لديك طلب بيانات من واجهة برمجة التطبيقات، أجرِ بعض طلبات البيانات من واجهة برمجة التطبيقات وأعِد إنتاج الخطأ 504 Gateway Timeout.
2. بعد حدوث الخطأ، افحص الطلب المحدّد الذي يعرض رمز الاستجابة على النحو التالي: 504.
3. تحقَّق من الوقت المنقضي في كل مرحلة، ودوِّن ملاحظة عن المرحلة التي استغرقت معظم الوقت.
4. إذا لاحظت حدوث الخطأ مع أطول وقت منقضي مباشرةً بعد إحدى المراحل التالية، يشير ذلك إلى أنّ خادم الخلفية بطيء أو يستغرق وقتًا طويلاً لمعالجة الطلب:
   • تم إرسال الطلب إلى الخادم المستهدف
   • سياسة ServiceCallout

يوضّح ما يلي نموذجًا لعملية تتبُّع تُظهر أنّ خادم الخلفية لم يستجب حتى بعد 55 ثانية، ما أدّى إلى حدوث الخطأ 504 Gateway Timeout:

في عملية التتبُّع أعلاه، تنتهي مهلة "معالج الرسائل" بعد 55002 ملي ثانية لأنّ خادم الخلفية لا يستجيب.

الإجراء رقم 2: استخدام سجلّات "معالج الرسائل"

1. مراجعة سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log)

2. إذا ظهرت لك الأخطاء Gateway Timeout وonTimeoutRead لطلب وكيل واجهة برمجة التطبيقات المحدّد في الوقت المحدّد، يشير ذلك إلى أنّ مهلة "معالج الرسائل" قد انتهت.

   نموذج لسجلّ "معالج الرسائل" يعرض الخطأ Gateway Timeout Error

   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. تنطبق قيمة المهلة هذه على جميع خوادم وكيل واجهة برمجة التطبيقات التي تنتمي إلى مؤسسة يخدمها معالج الرسائل هذا. إذا لم يستجب خادم الخلفية في غضون 55 ثانية، سيحدث مهلة لمعالج الرسائل وسيتم إرسال الخطأ 504 Gateway Timeout إلى العميل. يمكن تجاوز قيمة المهلة المحدّدة في "معالج الرسائل" من خلال السمة io.timeout.millis المحدّدة ضمن خادم وكيل واجهة برمجة التطبيقات. تنطبق قيمة المهلة هذه على خادم وكيل API معيّن تم تحديد السمة المذكورة أعلاه فيه. على سبيل المثال، إذا تم ضبط io.timeout.millis على 10 ثوانٍ في خادم وكيل واجهة برمجة التطبيقات، سيتم استخدام قيمة المهلة البالغة 10 ثوانٍ لخادم وكيل واجهة برمجة التطبيقات المحدّد هذا. إذا لم يستجب خادم الخلفية في غضون 10 ثوانٍ لوكيل API المحدّد، ستنتهي مهلة "معالج الرسائل" وسيتم إرسال الخطأ 504 Gateway Timeout إلى العميل.

الدقة

1. تحقَّق من سبب استغراق خادم الخلفية أكثر من 55 ثانية، واعرف ما إذا كان يمكن إصلاحه أو تحسينه للاستجابة بشكل أسرع.
2. إذا لم يكن من الممكن إصلاح/تحسين خادم الخلفية أو كان معروفًا أنّ خادم الخلفية يستغرق وقتًا أطول من المهلة التي تم ضبطها، عليك زيادة قيمة المهلة في "الموجّه" و"معالج الرسائل" إلى قيمة مناسبة.

السيناريو ‫2 - انتهاء مهلة جهاز التوجيه قبل أن يستجيب معالج الرسائل/خادم الخلفية

قد تظهر لك أخطاء 504 Gateway Timeout إذا انتهت مهلة جهاز التوجيه قبل أن يستجيب خادم معالج الرسائل أو خادم الخلفية. يمكن أن يحدث ذلك في إحدى الحالات التالية:

• قيمة المهلة المضبوطة على جهاز التوجيه أقصر من قيمة المهلة المضبوطة على معالج الرسائل. على سبيل المثال، لنفترض أنّ المهلة المحدّدة في جهاز التوجيه هي 50 ثانية، بينما المهلة المحدّدة في "معالج الرسائل" هي 55 ثانية.

  انتهاء المهلة على جهاز التوجيه	انتهاء مهلة "معالج الرسائل"
  ٥۰ ثانية	٥٥ ثانية

• يتم تجاهل قيمة المهلة في "معالج الرسائل" واستخدام قيمة مهلة أعلى باستخدام الخاصية io.timeout.millis التي تم ضبطها ضمن إعدادات نقطة النهاية المستهدَفة لخادم وكيل واجهة برمجة التطبيقات:

  على سبيل المثال، إذا تم ضبط قيم المهلة التالية:

  انتهاء المهلة على جهاز التوجيه	انتهاء مهلة "معالج الرسائل"	انتهاء المهلة في خادم API الوكيل
  ‫57 ثانية	٥٥ ثانية	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 ثانية التي تم ضبطها في خادم وكيل واجهة برمجة التطبيقات. وبالتالي، ستكون قيمة المهلة الخاصة بـ Message Processor لخادم وكيل واجهة برمجة التطبيقات المحدّد هذا هي 120 ثانية.

  بما أنّ جهاز التوجيه لديه قيمة مهلة أقل (57 ثانية) مقارنةً بـ 120 ثانية تم ضبطها في خادم الخلفية، ستنتهي مهلة جهاز التوجيه إذا لم يستجب خادم الخلفية بعد 57 ثانية.

التشخيص

1. مراجعة سجلّ الوصول إلى NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. إذا انتهت مهلة جهاز التوجيه قبل انتهاء مهلة "معالج الرسائل"، ستظهر لك الحالة 504 في سجلات الوصول إلى NGINX لطلب بيانات من واجهة برمجة التطبيقات المحدّد، وسيتم ضبط message id من "معالج الرسائل" على -. ويرجع ذلك إلى أنّ الموجه لم يتلقَّ أي رد من "معالج الرسائل" خلال فترة المهلة المحدّدة على الموجه.

   نموذج لإدخال سجلّ NGINX يعرض الخطأ 504 بسبب انتهاء مهلة جهاز التوجيه

   

3. في المثال أعلاه، لاحظ حالة 504 على NGINX، ومعرّف الرسالة من Message Processor هو -، وإجمالي الوقت المنقضي هو 57.001 ثانية. ويرجع ذلك إلى انتهاء مهلة جهاز التوجيه بعد 57.001 ثانية، ولم نتلقَّ أي رد من "معالج الرسائل".
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>

يظهر هذا الخطأ لأنّه بمجرد انتهاء مهلة جهاز التوجيه، يتم إغلاق الاتصال مع "معالج الرسائل". عندما يكمل "معالج الرسائل" عملية المعالجة، يحاول كتابة الردّ إلى جهاز التوجيه. بما أنّ الاتصال بجهاز التوجيه مغلق، سيظهر الرمز Broken Pipe exception في "معالج الرسائل".

من المتوقّع أن يظهر هذا الاستثناء في الظروف الموضّحة أعلاه. لذا، السبب الفعلي لظهور الخطأ 504 Gateway Timeout هو أنّ الخادم الخلفي يستغرق وقتًا أطول للاستجابة، وعليك معالجة هذه المشكلة.

الدقة

1. إذا كان خادمًا خلفيًا مخصّصًا، اتّبِع الخطوات التالية:
   1. تحقَّق من سبب استغراق خادم الخلفية وقتًا طويلاً للاستجابة، واعرف ما إذا كان يمكن إصلاحه أو تحسينه للاستجابة بشكل أسرع.
   2. إذا لم يكن من الممكن إصلاح/تحسين خادم الخلفية أو كان من المعروف أنّ خادم الخلفية يستغرق وقتًا طويلاً، عليك زيادة قيمة المهلة في "جهاز التوجيه" و"معالج الرسائل".

      الفكرة: اضبط قيمة المهلة على المكوّنات المختلفة بالترتيب التالي: انتهاء المهلة على العميل > انتهاء المهلة على جهاز التوجيه > انتهاء المهلة على معالج الرسائل > انتهاء المهلة في خادم وكيل واجهة برمجة التطبيقات

2. إذا كان خادمًا خلفيًا يستند إلى NodeJS، اتّبِع الخطوات التالية:
   1. تحقَّق مما إذا كان رمز NodeJS يطلب بيانات من أي خوادم خلفية أخرى وما إذا كان يستغرق وقتًا طويلاً لعرض رد. تحقَّق من سبب استغراق خوادم الخلفية وقتًا أطول، ثم عالِج المشكلة حسب الاقتضاء.
   2. تحقَّق مما إذا كانت "معالجات الرسائل" تشهد معدل استخدام مرتفعًا لوحدة المعالجة المركزية أو الذاكرة:
      1. إذا كان أي من "معالجات الرسائل" يعاني من ارتفاع في استخدام وحدة المعالجة المركزية، أنشئ ثلاث عمليات تفريغ كل 30 ثانية باستخدام الأمر التالي:

         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 وتقديم تفريغات مؤشرات الترابط وتفريغ الذاكرة الرئيسية وسجلات "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log)للمساعدة في التحقيق في سبب ارتفاع معدل استخدام وحدة المعالجة المركزية/الذاكرة.

السيناريو 3: انتهاء مهلة تطبيق العميل قبل أن يستجيب جهاز التوجيه أو معالج الرسائل أو خادم الخلفية

قد تظهر لك أخطاء 504 Gateway Timeout إذا انتهت مهلة تطبيق العميل قبل أن يستجيب خادم الخلفية. يمكن أن يحدث هذا الموقف في الحالات التالية:

1. قيمة المهلة المضبوطة في تطبيق العميل أقل من قيمة المهلة المضبوطة في جهاز التوجيه و"معالج الرسائل":

   على سبيل المثال، إذا تم ضبط قيم المهلة التالية:

   انتهاء المهلة على العميل	انتهاء المهلة على جهاز التوجيه	انتهاء مهلة "معالج الرسائل"
   ٥۰ ثانية	‫57 ثانية	٥٥ ثانية

   في هذه الحالة، يكون إجمالي الوقت المتاح للحصول على ردّ على طلب بيانات من واجهة برمجة التطبيقات من خلال Edge أقل من أو يساوي 50 ثانية. ويشمل ذلك الوقت المستغرَق في تقديم طلب بيانات من واجهة برمجة التطبيقات، ومعالجة الطلب من خلال Edge (الموجّه، معالج الرسائل)، وإرسال الطلب إلى خادم الخلفية (إذا كان ذلك منطبقًا)، ومعالجة الخلفية للطلب وإرسال الردّ، ومعالجة Edge للردّ وإرساله أخيرًا إلى العميل.

   إذا لم يستجب جهاز التوجيه للعميل في غضون 50 ثانية، سيتم قطع الاتصال بين العميل وجهاز التوجيه. سيتلقّى العميل رمز الاستجابة 504.

   سيؤدي ذلك إلى أن يضبط NGINX رمز الحالة على 499، ما يشير إلى أنّ العميل أغلق الاتصال.

التشخيص

1. إذا انتهت مهلة تطبيق العميل قبل تلقّي رد من جهاز التوجيه، سيتم إغلاق الاتصال بجهاز التوجيه. في هذه الحالة، سيظهر لك رمز الحالة 499 في سجلات الوصول إلى NGINX لطلب بيانات من واجهة برمجة التطبيقات المحدّد.

   نموذج إدخال سجلّ NGINX يعرض رمز الحالة 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. إذا لم يكن من الممكن إصلاح خادم الخلفية أو تحسينه، أو إذا كنت تعلم أنّ خادم الخلفية سيستغرق وقتًا طويلاً، عليك زيادة قيمة المهلة على جهاز التوجيه و"معالج الرسائل".
      
      

      الفكرة: اضبط قيمة المهلة على المكوّنات المختلفة بالترتيب التالي: انتهاء المهلة على العميل > انتهاء المهلة على جهاز التوجيه > انتهاء المهلة على معالج الرسائل > انتهاء المهلة في خادم وكيل واجهة برمجة التطبيقات

2. إذا كانت الخلفية NodeJS، عليك اتّباع الخطوات التالية:
   1. تحقَّق مما إذا كان رمز NodeJS يطلب بيانات من أي خوادم خلفية أخرى وما إذا كان يستغرق وقتًا طويلاً لعرض النتائج. تحقَّق من سبب استغراق خوادم الخلفية هذه وقتًا أطول.
   2. تحقَّق مما إذا كانت "معالجات الرسائل" تشهد معدل استخدام مرتفع لوحدة المعالجة المركزية أو الذاكرة:
      1. إذا كان "معالج الرسائل" يعاني من ارتفاع في نسبة استخدام وحدة المعالجة المركزية، أنشئ ثلاث عمليات تفريغ للملفات المؤقتة كل 30 ثانية باستخدام الأمر التالي:

         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 وقدِّم له عمليات تفريغ الذاكرة المؤقتة وعمليات تفريغ الذاكرة الرئيسية وسجلات "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log)لمساعدته في التحقيق في سبب ارتفاع معدّل استخدام وحدة المعالجة المركزية/الذاكرة.

زيادة قيمة المهلة على جهاز التوجيه ومعالج الرسائل

اختَر قيم المهلة التي سيتم ضبطها على "الموجّه" و"معالج الرسائل" بعناية وفقًا لمتطلباتك. لا تحدّد قيم مهلة كبيرة بشكل عشوائي. إذا كنت بحاجة إلى المساعدة، يُرجى التواصل مع فريق دعم 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. إذا كان لديك أكثر من "معالج رسائل" واحد، كرِّر الخطوات أعلاه على جميع "معالجات الرسائل".

بطء معالجة طلبات البيانات من واجهة برمجة التطبيقات بواسطة Edge

إذا كان Edge بطيئًا جدًا و/أو يستغرق وقتًا طويلاً لمعالجة طلب البيانات من واجهة برمجة التطبيقات، سيظهر لك الخطأ 504 Gateway Timeout.

التشخيص

1. تتبُّع واجهة برمجة التطبيقات المتأثّرة في واجهة مستخدم Edge
2. انتظِر إلى أن يحدث الخطأ، أو إذا كان لديك طلب البيانات من واجهة برمجة التطبيقات، أرسِل بعض طلبات البيانات من واجهة برمجة التطبيقات وأعِد إنتاج الخطأ 504 Gateway Timeout.
3. ملاحظة: في هذه الحالة، قد يظهر لك ردّ ناجح في "التتبُّع".
   1. تنتهي مهلة جهاز التوجيه/العميل لأنّ "معالج الرسائل" لا يستجيب خلال فترة المهلة المحدّدة على جهاز التوجيه/العميل (أيهما لديه أقصر فترة مهلة). ومع ذلك، يواصل "معالج الرسائل" معالجة الطلب وقد يكتمل بنجاح.
   2. بالإضافة إلى ذلك، لا يتم تفعيل قيمة HTTPTransport.io.timeout.millis التي تم ضبطها في "معالج الرسائل" إلا إذا كان "معالج الرسائل" يتواصل مع خادم خلفي HTTP/HTTPS. بعبارة أخرى، لن يتم تشغيل مهلة الانتظار هذه عندما تستغرق أي سياسة (غير سياسة ServiceCallout) ضِمن خادم API الوكيل وقتًا طويلاً.
4. بعد حدوث الخطأ، افحص الطلب المحدّد الذي استغرق أطول وقت منذ إرساله.
5. تحقَّق من الوقت المنقضي في كل مرحلة، ودوِّن ملاحظة عن المرحلة التي استغرقت أكبر وقت.
6. إذا لاحظت أطول وقت منقضي في أي من السياسات الأخرى غير سياسة Service Callout، يشير ذلك إلى أنّ Edge يستغرق وقتًا طويلاً لمعالجة الطلب.
7. في ما يلي نموذج لتتبُّع واجهة المستخدم يعرض وقتًا منقضيًا مرتفعًا جدًا في سياسة JavaScript:

   

8. في المثال أعلاه، تلاحظ أنّ سياسة JavaScript تستغرق وقتًا طويلاً بشكل غير طبيعي يبلغ حوالي 245 ثانية.

الدقة

1. تحقَّق ممّا إذا كانت السياسة التي استغرقت وقتًا طويلاً للردّ تتضمّن أي رمز مخصّص قد يستغرق وقتًا طويلاً للمعالجة. إذا كان هناك أي رمز من هذا النوع، حاوِل إصلاح/تحسين الرمز الذي تم تحديده.
2. إذا لم يكن هناك رمز مخصّص قد يتسبّب في ارتفاع وقت المعالجة، تحقَّق مما إذا كانت "معالجات الرسائل" تعاني من ارتفاع في استخدام وحدة المعالجة المركزية أو الذاكرة:
   1. إذا كان أي من "معالجات الرسائل" يعاني من ارتفاع في استخدام وحدة المعالجة المركزية، أنشئ ثلاث عمليات تفريغ للملفات كل 30 ثانية باستخدام الأمر التالي:

      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 وقدِّم له عمليات تفريغ السلاسل، وعمليات تفريغ الذاكرة المخصّصة، وسجلات "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log)لمساعدته في التحقيق في سبب ارتفاع معدّل استخدام وحدة المعالجة المركزية/الذاكرة.

تشخيص المشاكل باستخدام رصد واجهة برمجة التطبيقات

تتيح لك ميزة مراقبة واجهة برمجة التطبيقات عزل مناطق المشاكل بسرعة لتشخيص الأخطاء ومشاكل الأداء ووقت الاستجابة ومصدرها، مثل تطبيقات المطوّرين أو خوادم وكيل واجهة برمجة التطبيقات أو خوادم الخلفية المستهدَفة أو منصة واجهة برمجة التطبيقات.

تتبُّع سيناريو نموذجي يوضّح كيفية تحديد المشاكل من فئة 5xx في واجهات برمجة التطبيقات وحلّها باستخدام "مراقبة واجهة برمجة التطبيقات" على سبيل المثال، قد تريد إعداد تنبيه لتلقّي إشعار عندما يتجاوز عدد رموز الحالة 504 حدًا معيّنًا.