تعذَّر إنشاء جلسة تتبُّع.

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

المشكلة

يتعذّر على المستخدم إنشاء جلسة تتبُّع في واجهة مستخدم Edge.

رسالة الخطأ

ستظهر لك رسالة خطأ في واجهة مستخدم Edge كما هو موضح أدناه:

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number>

إليك لقطة شاشة لنموذج لرسالة خطأ تمت ملاحظتها في واجهة مستخدم Edge:

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

في ما يلي بعض الأسباب المحتملة لهذا الخطأ:

السبب الوصف تعليمات تحديد المشاكل وحلّها التي تنطبق على
مشكلة في الاتصال بالشبكة فشل الاتصال بين خادم الإدارة ومعالج الرسائل بسبب مشاكل في الاتصال بالشبكة أو قواعد جدار الحماية. مستخدمو Edge الخاص على السحابة الإلكترونية
عدم تحميل البيئة على معالج الرسائل لم يتم تحميل البيئة الخاصة (التي تحاول تفعيل التتبُّع فيها) على معالِجات الرسائل بسبب حدوث خطأ.
إدخالات معالج الرسائل القديمة يشير خادم الإدارة إلى معالِجات رسائل غير متوفّرة (قديمة).
عدم إمكانية الوصول إلى معالج الرسائل تم إيقاف "معالج الرسائل" أو لا يمكن الوصول إليه.
مشكلة متعلّقة باستخدام عدد كبير من الموارد يواجه معالج (معالجات) الرسائل الاستخدام العالي للموارد (وحدة المعالجة المركزية (CPU) أو الذاكرة أو التحميل).
عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات على معالج رسائل واحد أو أكثر قد لا يتم نشر الخادم الوكيل لواجهة برمجة التطبيقات على معالج رسائل واحد أو أكثر بسبب عدم توفُّر إشعارات الحدث أثناء النشر.
مشكلة في واجهة مستخدم Edge يتعذّر على واجهة مستخدم Edge إنشاء جلسة تتبُّع بسبب حدوث خطأ.

خطوات التشخيص الشائعة

  1. تنفيذ واجهة برمجة تطبيقات الإدارة هذه:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. إذا ظهرت لك أي أخطاء، دوِّنها. انتقِل إلى مشكلة في الاتصال بالشبكة.

  3. في حال تلقّيت ردًّا ناجحًا، يعني ذلك أنّه يمكن إنشاء جلسة التتبُّع من خلال Management API. مع ذلك، قد تكون هناك مشكلة محتملة في واجهة مستخدم Edge، مثل عدم إمكانية إنشاء جلسة تتبُّع في واجهة المستخدم. انتقِل إلى مشكلة في واجهة مستخدم Edge.

السبب: مشكلة في الاتصال بالشبكة

التشخيص

  1. تحقَّق من سجلّ خادم الإدارة /opt/apigee/var/log/edge-management-server/logs/system.log لمعرفة ما إذا كانت هناك أي أخطاء أثناء إنشاء جلسة التتبُّع/تصحيح الأخطاء.

    نموذج خطأ من سجلّ خادم الإدارة

    2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
...<snipped>
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
...<snipped>

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

  3. إذا لم تظهر لك أي أخطاء متعلقة بالاتصال بالشبكة أو خطأ مشابهًا لما يظهر في المثال أعلاه، انتقِل إلى البيئة لم يتم تحميلها على معالج الرسائل.

  4. إذا لاحظت أخطاءً تتعلق بالاتصال بالشبكة أو خطأ مشابهًا لما هو موضح في المثال أعلاه، اتّبِع الخطوات التالية.

  5. اختبر الاتصال من خادم الإدارة إلى معالج الرسائل على المنفذ 8082 باستخدام الخطوات التالية:

    1. إذا كان telnet متاحًا، فاستخدم إذًا telnet:

      telnet <MessageProcessor_IP> 8082

    2. إذا لم يكن telnet متاحًا، فاستخدم netcat للتحقق من الاتصال على النحو التالي:

      nc -vz <MessageProcessor_IP> 8082

    3. إذا تلقّيت الاستجابة "تم رفض الاتصال" أو "انتهت مهلة الاتصال"، انتقِل إلى الخطوة التالية.

  6. سجِّل الدخول إلى كل معالج من معالجات الرسائل بعنوان IP المقابل الذي عرض الخطأ، ونفذ الخطوات التالية:

    1. تحقق مما إذا كان معالج الرسائل يتلقى بيانات عبر المنفذ 8082:

      netstat -an | grep LISTEN | grep 8082

    2. إذا كان "معالج الرسائل" ينتظر استقبال البيانات على المنفذ 8082، انتقِل إلى الخطوة رقم 7.

    3. إذا كان معالج الرسائل لا يتصل عبر المنفذ 8082، فقم بإعادة تشغيل معالج الرسائل باستخدام هذا الأمر:

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

    4. انتظر حتى يبدأ معالج الرسائل بالكامل باستخدام هذا الأمر:

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

    5. بمجرد إعداد معالج الرسائل، قم بإعادة التحقق مما إذا كان معالج الرسائل يستمع على المنفذ 8082.

    6. إذا كان "معالج الرسائل" ينتظر استقبال البيانات على المنفذ 8082، انتقِل إلى الخطوة رقم 7.

  7. تحقَّق مما إذا كان بإمكانك الآن بدء جلسة التتبُّع في واجهة المستخدم. وإذا لم تعد المشكلة ملحوظة، يمكنك تخطي الخطوات التالية.

  8. إذا كان معالج الرسائل يعمل ويستمع على المنفذ 8082، ولكن لا تزال غير قادر على الاتصال بالخوادم الأخرى مثل Management Server، فمن المحتمل أن يكون هناك جدار حماية يحظر الاتصالات الخارجية.

  9. استخدِم الأمر المناسب للتحقّق من قواعد جدار الحماية. على سبيل المثال، يمكنك تنفيذ الأمر iptables لسرد جميع قواعد جدار الحماية المحددة في نظامك:

    iptables -L -n

  10. إذا لم يتم ضبط قواعد جدار الحماية للمنفذ 8082، انتقِل إلى مشكلة استخدام موارد عالية.

  11. إذا تم إعداد أي قواعد جدار حماية على المنفذ 8082، فانتقل إلى قسم الحل أدناه.

الحلّ

  1. اعمل مع مشرف الشبكة للسماح بحركة المرور الواردة/الصادرة على المنفذ 8082 من الخوادم الخارجية.

في حال استمرار المشكلة، انتقِل إلى ضرورة جمع معلومات التشخيص.

السبب: عدم تحميل البيئة على معالج الرسائل

التشخيص

  1. تحقَّق من سجلّات خادم الإدارة /opt/apigee/var/log/edge-management-server/logs/system.log لمعرفة ما إذا كانت هناك أي أخطاء أثناء إنشاء جلسة التتبُّع/تصحيح الأخطاء.

  2. قد تظهر لك رسالة خطأ مثل "لا توجد ردود صالحة من ملفات MP" أثناء إنشاء جلسة تتبُّع/تصحيح الأخطاء كما هو موضّح أدناه:

    2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}

    يشير هذا الخطأ إلى أن معالجات الرسائل لا تستجيب لخادم الإدارة لسبب ما.

  3. إذا لم يظهر لك خطأ مشابه للخطأ الموضح في المثال أعلاه، يُرجى الانتقال إلى إدخالات معالج الرسائل القديمة.

  4. إذا لاحظت خطأً مشابهًا للخطأ الموضح في المثال أعلاه، فاتبع الخطوات التالية.

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

  6. يُرجى تسجيل الدخول إلى كل معالج من معالجات الرسائل والتحقّق مما إذا كان قد تم تحميل البيئة المحددة التي تحاول إنشاء جلسة التتبع فيها على "معالج الرسائل" باستخدام الأمر أدناه:

    curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments

    مثال على الناتج:

    ستظهر لك قائمة بالبيئات التي تنتمي إلى المؤسسة المحددة التي يتم تحميلها على معالج الرسائل في مخرجات الأمر أعلاه. على سبيل المثال، إذا تم تحميل البيئتين preprod وtest على معالج الرسائل، سيظهر لك الناتج على النحو التالي:

    [ "preprod", "test" ]

  7. إذا كانت البيئة المحددة، على سبيل المثال "dev" التي تحاول إنشاء جلسة تتبُّع فيها، مدرجة كجزء من الأمر أعلاه، ثم انتقِل إلى إدخالات معالج الرسائل القديمة.

  8. إذا كانت البيئة المحدّدة، على سبيل المثال "dev" غير مدرَجة كجزء من الأمر أعلاه، يمكنك التحقّق بعد ذلك من /opt/apigee/var/log/edge-message-processor/logs/system.log و/opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log في معالجات الرسائل بحثًا عن أي أخطاء أثناء تحميل البيئات.

  9. يمكن أن يكون هناك العديد من الأخطاء المختلفة التي يمكن أن تؤدي إلى فشل تحميل بيئة على معالج الرسائل. يعتمد الحل على الخطأ الذي حدث.

درجة الدقّة

قد لا يتم تحميل البيئة على معالج الرسائل لعدة أسباب. يوضِّح هذا القسم بعض الأسباب المحتملة التي قد تؤدي إلى حدوث هذه المشكلة، كما يفسّر كيفية حلّها.

  1. إذا ظهر لك أحد الأخطاء التالية في سجلّ معالج الرسائل، يرجع ذلك إلى مشكلة تم رصدها في الشهادات/المفاتيح التي تمت إضافتها إلى ملف تخزين المفاتيح/ملف تخزين المفاتيح المحدّد في البيئة المحدّدة.

    الخطأ رقم 1: java.security.KeyStoreException: لا يمكن استبدال شهادته

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na] 
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na] 
… 
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted
2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    الخطأ رقم 2: java.security.KeyStoreException: لا يمكن استبدال المفتاح السري

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
... 
Caused by: java.security.KeyStoreException: Cannot overwrite secret key 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na] 
... 20 common frames omitted 

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

  2. احصل على تفاصيل ملف تخزين المفاتيح/متجر الثقة المحدّدة في رسالة الخطأ المعروضة في الخطوة السابقة باستخدام طلب واجهة برمجة التطبيقات التالي للإدارة:

    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    مثال على الناتج:

    { 
"certs": [ 
"mycert", 
"mycert-new" 
], 
"keys": [ 
"mycert" 
], 
"name": "myTruststore" 
}

  3. يوضِّح مثال الناتج أنّ هناك شهادتَين ومفتاحًا في myTruststore. لا يحتوي Truststore بشكل عام على أي مفتاح. وإذا كان الأمر كذلك، فمن الأفضل أن يكون لديك شهادة واحدة ومفتاح واحد.

  4. يمكنك الحصول على تفاصيل حول الشهادتَين باستخدام واجهة برمجة التطبيقات التالية:

    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>

  5. تحقق من تاريخ انتهاء صلاحية كل شهادة من الشهادات وحدد الشهادة منتهية الصلاحية/الأقدم.

  6. احذف الشهادة منتهية الصلاحية أو غير المرغوب فيها من Truststore "myTruststore".

في حال استمرار المشكلة أو في حال ظهور أي خطأ غير الأخطاء المذكورة في الخطوة 1 أعلاه، انتقِل إلى ضرورة جمع معلومات التشخيص.

السبب: تعذّر الوصول إلى إدخالات معالج الرسائل القديمة أو معالِجات الرسائل

التشخيص

  1. إذا كانت واجهة مستخدم Edge تستغرق وقتًا طويلاً وتعذّرت إنشاء جلسة التتبُّع، إليك بعض الأسباب المحتملة لذلك:
    1. قد يشير خادم الإدارة إلى معالِجات رسائل غير موجودة (قديمة)
    2. تم إيقاف معالِجات الرسائل أو لا يمكن الوصول إليها.
    3. تعمل معالِجات الرسائل على استخدام ذاكرة عالية أو وحدة المعالجة المركزية (CPU) بشكل كبير.
  2. تحقَّق من سجلات خادم الإدارة /opt/apigee/var/log/edge-management-server/logs/system.log لمعرفة ما إذا كانت هناك أي أخطاء أثناء إنشاء جلسة التتبُّع/تصحيح الأخطاء.

  3. قد تظهر لك رسالة خطأ مثل "الخادم <UUID> إما لا يعمل أو لا يمكن الوصول إليه" أثناء إنشاء جلسة تتبُّع/تصحيح الأخطاء كما هو موضّح أدناه:

    2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server

    قد يتبع ذلك خطأ آخر "انتهت مهلة الاتصال" بعد فترة وجيزة كما هو موضّح أدناه:

    2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
…<snipped>
Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
…<snipped>

  4. قد يكون السبب في هذين الخطأين هو معالج(معالِج) رسائل محددون:

    1. قديم (لم يعد موجودًا)
    2. يعود العطل أو لا يمكن الوصول إليه لسبب ما

  5. يرجى اتباع الحل المناسب استنادًا إلى السيناريو الذي واجهته.

درجة الدقّة

السيناريو 1 : معالج(معالجات) الرسائل قديمة (غير موجودة)

  1. احصل على قائمة بمعالجي الرسائل باستخدام واجهة برمجة تطبيقات الإدارة التالية:

    curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"

  2. دوِّن عنوان IP أو اسم المضيف الذي يتوافق مع المعرّفات الفريدة العالمية (UUID) لمعالجات الرسائل المذكورة في رسالة الخطأ في سجلات خادم الإدارة (الخطوة رقم 3 في التشخيص أعلاه). تحقَّق مما إذا كانت هذه معالجات رسائل صالحة باستخدام إحدى الطرق التالية:

    1. أحدث مخطط لإعداد المخطط الخاص بالسحابة الإلكترونية الخاصة
    2. أحدث عنوان IP لخادم Edge - جدول تعيين اسم المضيف

    وإذا وجدتها تعد معالجات رسائل صالحة، فانتقل إلى السيناريو 2 : لا يمكن الوصول إلى معالِجات الرسائل.

  3. حذف معالِجات الرسائل القديمة (غير الموجودة) باستخدام واجهات برمجة تطبيقات الإدارة التالية:

    1. إلغاء تسجيل معالج الرسائل من بيئات المؤسسة: 

      curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove"

    2. إلغاء تسجيل نوع الخادم: 

      curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"

    3. حذف الخادم: 

      curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE

  4. كرِّر الخطوة رقم 3 إذا كنت تواجه المشكلة نفسها في أي بيئات أخرى في مؤسستك.

السيناريو 2: لا يمكن الوصول إلى معالجات الرسائل

  1. قم بتسجيل الدخول إلى كل معالِجات رسائل من خلال تحديد عناوين IP/أسماء المضيفين استنادًا إلى المعرفات الفريدة عالميًا(UUID) التي تظهر في رسالة الخطأ في سجلات خادم الإدارة.

  2. أعِد تشغيل معالج الرسائل:

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

أعِد التحقُّق ممّا إذا كان بإمكانك إنشاء جلسة التتبُّع. إذا استمرت المشكلة، انتقِل إلى القسم ضرورة جمع معلومات التشخيص.

السبب: مشكلة في استخدام الموارد بشكل كبير

التشخيص

  1. يُرجى تسجيل الدخول إلى كل معالج من معالِجات الرسائل، والتحقّق مما إذا كان هناك استفادة كبيرة من أي موارد، مثل وحدة المعالجة المركزية(CPU) أو الذاكرة أو التحميل. يمكنك استخدام الأمر top على أنظمة التشغيل المستندة إلى Unix للحصول على معلومات استخدام الموارد لعملية "معالج الرسائل":

    top

  2. إذا كان معالجي الرسائل لا يستخدمون الموارد بشكلٍ كبير، انتقِل إلى ضرورة جمع معلومات التشخيص.

  3. إذا كانت معالجات الرسائل تواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية(CPU) أو الذاكرة، قد يتسبب ذلك في عدم استجابة معالج الرسائل لخادم الإدارة في الوقت المناسب. وفي نهاية المطاف، سيؤدي هذا الإجراء إلى منعك من إنشاء جلسة تتبُّع.

    1. إذا كان أي من معالجات الرسائل يواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية (CPU)، ثم أنشئ ثلاث عمليات تفريغ لسلسلة المحادثات كل 30 ثانية باستخدام الأمر التالي:

      sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>

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

      sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>

    3. الانتقال إلى درجة الدقة

درجة الدقّة

  1. أعِد تشغيل معالج الرسائل باستخدام الأمر أدناه. من المفترض أن يؤدي هذا إلى الحد من استخدام وحدة المعالجة المركزية (CPU) والذاكرة:

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

  2. راقِب طلبات البيانات من واجهة برمجة التطبيقات وتأكَّد مما إذا كانت المشكلة لا تزال قائمة.

  3. يمكنك التواصل مع فريق دعم Apigee Edge وتقديم عمليات تفريغ سلاسل المحادثات ونَسْخ الذاكرة وسجلّات "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log) لمساعدتهم في التحقيق في سبب ارتفاع معدّل استخدام وحدة المعالجة المركزية (CPU)/الذاكرة).

السبب: عدم نشر الخادم الوكيل لواجهة برمجة التطبيقات في معالج رسائل واحد أو أكثر

في حالات نادرة لا يمكن تفعيل خادم وكيل لواجهة برمجة التطبيقات على واحد أو أكثر من معالجات الرسائل. ويحدث هذا غالبًا بسبب فقدان إشعار الحدث من "خادم الإدارة" إلى "معالج الرسائل" أثناء نشر خادم وكيل محدد لواجهة برمجة التطبيقات. في هذه الحالة أيضًا، لن تتمكن من إنشاء جلسة التتبع في واجهة مستخدم Edge.

التشخيص

  1. قم بتسجيل الدخول إلى كل من معالجات الرسائل وتحقق مما إذا كان قد تم نشر النسخة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات باستخدام الأمر التالي:

    curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions

    مثال على الناتج:

    ستظهر لك قائمة النُسخ السابقة كنتيجة للأمر أعلاه. على سبيل المثال، إذا تم نشر النسخة 12، فستظهر لك النتيجة على النحو التالي:

    [ "12" ]

  2. إذا لم تظهر النسخة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات كنتيجة للأمر المذكور في الخطوة رقم 1 أعلاه، فأعد تشغيل معالج الرسائل المحدد كما هو موضح في الحل أدناه.

  3. كرِّر الخطوات من 1 إلى 2 لجميع معالجات الرسائل.

  4. إذا تم نشر النسخة المحددة من الخادم الوكيل لواجهة برمجة التطبيقات على جميع معالجات الرسائل، فلن يكون هذا هو سبب هذه المشكلة. انتقِل إلى ضرورة جمع معلومات التشخيص.

درجة الدقّة

  1. أعِد تشغيل معالجات الرسائل المحدّدة التي لم يتم نشر النسخة المحدّدة من الخادم الوكيل لواجهة برمجة التطبيقات عليها:

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

السبب: مشكلة في واجهة مستخدم Edge

التشخيص

  1. تحقَّق من سجلّات واجهة مستخدم Edge /opt/apigee/var/log/edge-ui/application.log و/opt/apigee/var/log/edge-ui/edge-ui.log لمعرفة ما إذا كانت هناك أي أخطاء.
  2. يُرجى التواصل مع فريق دعم Apigee Edge ومشاركة هذه الملفات لإجراء مزيد من التحقيقات.

ضرورة جمع معلومات التشخيص

إذا استمرت المشكلة حتى بعد اتباع التعليمات المذكورة أعلاه، يُرجى جمع معلومات التشخيص التالية. يمكنك التواصل مع فريق دعم Apigee Edge ومشاركته:

  1. ناتج الأمر:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. سجلّ خادم الإدارة 

    /opt/apigee/var/log/edge-management-server/logs/system.log.

  3. سجلّات "معالج الرسائل"

    /opt/apigee/var/log/edge-message-processor/logs/system.log.

  4. إخراج أوامر telnet/nc من خادم الإدارة إلى معالج الرسائل:

    telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082

  5. ناتج الأمر netstat أدناه في معالجات الرسائل:

    netstat -an > netstat.txt

  6. إذا تبيّن أنّ هناك مشكلة في واجهة مستخدم Edge، يجب تقديم سجلَّي واجهة مستخدم Edge /opt/apigee/var/log/edge-ui/application.log و/opt/apigee/var/log/edge-ui/edge-ui.log.

  7. تتوفّر تفاصيل حول الأقسام التي تمت تجربتها في هذا "الدليل الإرشادي" وأي إحصاءات أخرى ستساعدنا في حلّ هذه المشكلة بسرعة.