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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

المشكلة

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

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

رسائل الخطأ

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

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:

انتهاء المهلة التفاصيل
انتهاء المهلة على معالج الرسائل
  • لا يستجيب خادم الخلفية لمعالج الرسائل خلال فترة المهلة المحددة في معالج الرسائل.
  • تنتهي مهلة "معالج الرسائل" ويرسل حالة الاستجابة "504 Gateway Timeout" إلى جهاز التوجيه.
انتهت المهلة على جهاز التوجيه
  • لا يستجيب معالج الرسائل لجهاز التوجيه خلال فترة المهلة المحددة على جهاز التوجيه.
  • تنتهي مهلة جهاز التوجيه ويرسل حالة الاستجابة 504 Gateway Timeout إلى تطبيق العميل.
انتهاء المهلة في تطبيق العميل
  • لا يستجيب جهاز التوجيه لتطبيق العميل خلال فترة المهلة المحددة على جهاز التوجيه.
  • تنتهي مهلة تطبيق العميل وتنتهي حالة الردّ على 504 Gateway Timeout للمستخدم النهائي.

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

في Edge، الأسباب النموذجية لخطأ 504 Gateway Timeout هي:

السبب التفاصيل الخطوات المقدمة لـ
بطء خادم الخلفية إنّ خادم الخلفية الذي يعالج طلب البيانات من واجهة برمجة التطبيقات بطيء جدًا بسبب التحميل الزائد أو ضعف الأداء. مستخدمو السحابة الإلكترونية العامة والخاصة
معالجة طلبات واجهة برمجة التطبيقات البطيئة بواسطة Edge يستغرق Edge وقتًا طويلاً لمعالجة طلب البيانات من واجهة برمجة التطبيقات بسبب التحميل الزائد أو ضعف الأداء.

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

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

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

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

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

التشخيص

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

الإجراء رقم 1 استخدام التتبع

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

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

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

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

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

  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

    في سجلّ "معالج الرسائل" أعلاه، تلاحظ أنّ خادم الخلفية المُشار إليه بعنوان IP XX.XX.XX.XX لم يستجِب حتى بعد 55 ثانية (lastIO=55000ms). ونتيجةً لذلك، انتهت مهلة "معالج الرسائل" وأرسل خطأ واحد (504 Gateway Timeout).

    راجع هذا: كيف يتم التحكم في المهلة في معالج الرسائل؟

    • كيفية التحكم في المهلة على معالج الرسائل يتم عادةً ضبط معالِجات الرسائل باستخدام قيمة مهلة تلقائية تبلغ 55 ثانية) من خلال السمة HTTPTransport.io.timeout.millis. وتنطبق قيمة المهلة هذه على جميع الخوادم الوكيلة لواجهة برمجة التطبيقات التي تنتمي إلى مؤسسة يعرضها "معالج الرسائل" هذا.
      • إذا لم يستجب الخادم الخلفية خلال 55 ثانية، تنتهي مهلة معالج الرسائل ويرسل خطأ 504 Gateway Timeout إلى العميل.
    • يمكن إلغاء قيمة المهلة المحدّدة في "معالج الرسائل" من خلال السمة io.timeout.millis التي تم تحديدها ضمن الخادم الوكيل لواجهة برمجة التطبيقات. تنطبق قيمة المهلة هذه على خادم وكيل محدد لواجهة برمجة التطبيقات يتم فيه تحديد السمة المذكورة أعلاه. على سبيل المثال، إذا تم ضبط io.timeout.millis على 10 ثوانٍ في الخادم الوكيل لواجهة برمجة التطبيقات، سيتم استخدام قيمة المهلة 10 ثوانٍ لهذا الخادم الوكيل لواجهة برمجة التطبيقات.
      • في حال لم يستجِب الخادم الخلفي في غضون 10 ثوانٍ للخادم الوكيل المحدَّد لواجهة برمجة التطبيقات، تنتهي مهلة "معالج الرسائل" ويرسل الخطأ 504 Gateway Timeout إلى العميل.

درجة الدقّة

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

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

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

  • قيمة المهلة المحددة على جهاز التوجيه أقصر من قيمة المهلة المحددة في معالج الرسائل. على سبيل المثال، لنفترض أنّ المهلة المحدّدة على جهاز التوجيه هي 50 ثانية، وأنّ المهلة المحددة لمعالج الرسائل هي 55 ثانية.
    انتهت مهلة جهاز التوجيه. انتهت المهلة في معالج الرسائل
    ٥۰ ثانية ٥٥ ثانية
  • يتم إلغاء قيمة المهلة في معالج الرسائل باستخدام قيمة مهلة أعلى باستخدام السمة io.timeout.millis التي تم ضبطها ضمن إعداد نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات:

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

    انتهت مهلة جهاز التوجيه. انتهت المهلة في معالج الرسائل مهلة ضمن الخادم الوكيل لواجهة برمجة التطبيقات
    57 ثانية ٥٥ ثانية 120 ثانية

    ولكن تم ضبط مدة io.timeout.millis على 120 ثانية في الخادم الوكيل لواجهة برمجة التطبيقات:

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

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

      الفكرة: اضبط قيمة المهلة على المكوّنات المختلفة بالترتيب التالي:

      المهلة على العميل > المهلة على جهاز التوجيه > المهلة على معالج الرسائل > المهلة ضمن الخادم الوكيل لواجهة برمجة التطبيقات
  2. إذا كان خادم NodeJS خلفي، سيحدث ما يلي:
    1. تحقَّق مما إذا كان رمز NodeJS يُجري استدعاءات إلى أي خوادم خلفية أخرى وما إذا كان عرض الاستجابة يستغرق وقتًا طويلاً. تحقَّق من سبب استغراق الخوادم الخلفية وقتًا أطول وحلّ المشكلة على النحو المناسب.
    2. تأكَّد مما إذا كانت معالِجات الرسائل تستهلك قدرًا كبيرًا من وحدة المعالجة المركزية (CPU) أو الذاكرة:
      1. إذا كان أي من معالجات الرسائل يواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية (CPU)، يمكنك إنشاء ثلاث عمليات تفريغ لسلسلة المحادثات كل 30 ثانية باستخدام الأمر التالي: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. إذا كان أي من معالجات الرسائل يواجه استخدامًا مرتفعًا للذاكرة، يمكنك إنشاء تفريغ ذاكرة التخزين المؤقت باستخدام الأمر التالي: 
        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. راقِب طلبات البيانات من واجهة برمجة التطبيقات للتأكّد مما إذا كانت المشكلة لا تزال قائمة.
      5. يمكنك التواصل مع فريق دعم Apigee Edge وتقديم عمليات تفريغ سلاسل التعليمات ونسخ الذاكرة وسجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log)للمساعدة في استكشاف سبب ارتفاع معدّل استخدام وحدة المعالجة المركزية (CPU)/الذاكرة).

راجع هذا: كيف يتم التحكم في مهلة خوادم NodeJS الخلفية في معالج الرسائل

  • يعمل خادم الواجهة الخلفية لـ NodeJS ضمن عملية JVM في معالج الرسائل. ويتم التحكّم في قيمة المهلة لخوادم NodeJS الخلفية من خلال السمة http.request.timeout.seconds في ملف nodejs.properties. يتم ضبط هذه السمة على 0 تلقائيًا، بمعنى أنّه يتم إيقاف المهلة تلقائيًا لجميع الخوادم الوكيلة لواجهة برمجة التطبيقات التي تنتمي إلى مؤسسة يعرضها معالج الرسائل هذا. ولذلك حتى إذا استغرق خادم الواجهة الخلفية لـ NodeJS وقتًا طويلاً، لن تنتهي مهلة معالج الرسائل.
  • مع ذلك، إذا استغرق خادم الواجهة الخلفية لـ NodeJS وقتًا طويلاً وكان الوقت الذي يستغرقه طلب واجهة برمجة التطبيقات أكثر من 57 ثانية، ستنتهي مهلة جهاز التوجيه ويرسل الخطأ 504 Gateway Timeout إلى العميل.

السيناريو 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. تحقَّق مما إذا كانت معالِجات الرسائل تستهلك قدرًا كبيرًا من وحدة المعالجة المركزية (CPU) أو الذاكرة:
      1. إذا كان "معالج الرسائل" يواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية (CPU)، يجب إنشاء ثلاث عمليات تفريغ لسلسلة المحادثات كل 30 ثانية باستخدام الأمر التالي: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. إذا كان "معالج الرسائل" يواجه استخدامًا مرتفعًا للذاكرة، يمكنك إنشاء تفريغ للذاكرة باستخدام الأمر التالي: 
        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. راقِب طلبات البيانات من واجهة برمجة التطبيقات للتأكّد مما إذا كانت المشكلة لا تزال قائمة.
      5. يمكنك التواصل مع فريق دعم Apigee Edge وتوفير عمليات تفريغ سلاسل التعليمات ونسخ الذاكرة وسجلات معالج الرسائل (/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 على جهاز معالجة الرسائل، إذا لم يكن متوفرًا من قبل.
  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) ضمن الخادم الوكيل لواجهة برمجة التطبيقات وقتًا طويلاً.
  4. بعد حدوث الخطأ، تحقَّق من الطلب المحدّد الذي سجّل أطول مدة المنقضية.
  5. تحقَّق من الوقت المنقضي في كل مرحلة، وودوِّن المرحلة التي يتم قضاء معظم الوقت فيها.
  6. إذا لاحظت أطول فترة انقضت في أي من السياسات غير سياسة وسائل شرح الخدمة، هذا يعني أنّ Edge يستغرق وقتًا طويلاً لمعالجة الطلب.
  7. في ما يلي نموذج لتتبُّع واجهة مستخدم يعرض مقدارًا كبيرًا من الوقت المنقضي في سياسة JavaScript:

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

درجة الدقّة

  1. تحقَّق مما إذا كانت السياسة قد استغرقت وقتًا طويلاً للاستجابة لها وما إذا كانت هناك أي رموز مخصّصة قد تتطلّب معالجتها وقتًا طويلاً. في حال العثور على أي رمز من هذا القبيل، يمكنك التحقق مما إذا كان بإمكانك إصلاح/تحسين الرمز الذي تم تحديده.
  2. إذا لم يكن هناك رمز مخصّص قد يؤدي إلى وقت معالجة طويل، تحقَّق مما إذا كانت معالِجات الرسائل تستخدم وحدة معالجة مركزية (CPU) أو ذاكرة مرتفعًا مما يلي:
    1. إذا كان أي من معالجات الرسائل يواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية (CPU)، يمكنك إنشاء ثلاث عمليات تفريغ لسلسلة المحادثات كل 30 ثانية باستخدام الأمر التالي: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. في حال استخدام أي معالج رسائل للذاكرة بشكل كبير، يجب إنشاء تفريغ للذاكرة باستخدام الأمر التالي: 
      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. راقِب طلبات البيانات من واجهة برمجة التطبيقات وتأكَّد مما إذا كانت المشكلة لا تزال قائمة.
    5. يمكنك التواصل مع فريق دعم Apigee Edge وتوفير عمليات تفريغ سلاسل التعليمات ونسخ الذاكرة وسجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log)لمساعدتهم في التحقّق من سبب ارتفاع نسبة استخدام وحدة المعالجة المركزية (CPU)/الذاكرة.

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

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

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