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 الأساسي هو العميل -> الموجه (Router) -> معالج الرسائل -> خادم الخلفية كما هو موضح في الشكل أدناه:

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

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

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

في Edge، تشمل الأسباب الشائعة للخطأ 504 Gateway Timeout ما يلي:

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

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

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

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

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

التشخيص

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

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

إذا كانت المشكلة لا تزال نشطة (لا يزال هناك خطأان (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)، فأنشئ ثلاث معالجات سلسلة محادثات dumps كل 30 ثانية باستخدام الأمر التالي:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. إذا كان أي من معالجي الرسائل يواجه استخدامًا مرتفعًا للذاكرة، فأنشئ كومة من الذاكرة dump باستخدام الأمر التالي:

         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)للمساعدة اكتشف سبب ارتفاع استخدام وحدة المعالجة المركزية (CPU)/الذاكرة.

السيناريو 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) مرتفعًا بالنسبة إلى معالج الرسائل، فأنشئ ثلاثة برامج سلسلة محادثات dumps كل 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)لمساعدتهم اكتشف سبب ارتفاع استخدام وحدة المعالجة المركزية (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)، فأنشئ ثلاث معالجات سلسلة محادثات dumps كل 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)لمساعدتهم اكتشف سبب ارتفاع استخدام وحدة المعالجة المركزية (CPU)/الذاكرة.

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

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

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