جلسه ردیابی ایجاد نشد

درحال مشاهده اسناد 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» آمده است:

علل احتمالی

برخی‌از دلایل احتمالی این خطا در زیر فهرست شده است:

مراحل تشخیص خرابی رایج

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. اگر پاسخ موفقیت‌آمیزی دریافت کردید، این نشان می‌دهد که جلسه ردیابی می‌تواند ازطریق «میانای برنامه‌سازی کاربردی مدیریت» ایجاد شود. بااین‌حال، ممکن است مشکلی در «میانای کاربری 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. خطای نمونه بالا نشان می‌دهد که وقتی «سرور مدیریت» سعی می‌کند به «پردازشگر پیام» در درگاه شماره ۸۰۸۲ متصل شود، خطاهای «اتصال رد شد» دریافت می‌کنیم. بنابراین، «سرور مدیریت» نمی‌تواند جلسه ردیابی را ایجاد کند.

3. اگر خطایی مربوط به اتصال‌پذیری شبکه یا خطایی مشابه آنچه در مثال بالا نشان داده شده است مشاهده نمی‌کنید، به محیط در «پردازشگر پیام» بار نشده است بروید.

4. اگر خطایی(هایی) مربوط به اتصال‌پذیری شبکه یا خطایی مشابه با آنچه در مثال بالا نشان داده شده است مشاهده کردید، مراحل زیر را دنبال کنید.

5. بااستفاده از مراحل زیر، اتصال‌پذیری از «سرور مدیریت» به «پردازشگر پیام» در درگاه ۸۰۸۲ را آزمایش کنید:

   1. اگر telnet دردسترس است، از telnet استفاده کنید:

      telnet <MessageProcessor_IP> 8082
      

   2. اگر telnet دردسترس نیست، از netcat برای بررسی اتصال‌پذیری به این روش استفاده کنید:

      nc -vz <MessageProcessor_IP> 8082
      

   3. اگر پاسخ «اتصال رد شد» یا «مهلت اتصال تمام شد» را دریافت کردید، به مرحله بعدی بروید.

6. با نشانی IP مربوطه که خطا را نشان داده است، به هریک از «پردازشگرهای پیام» وارد شوید و مراحل زیر را انجام دهید:

   1. بررسی کنید که «پردازشگر پیام» در درگاه ۸۰۸۲ درحال گوش دادن باشد:

      netstat -an | grep LISTEN | grep 8082
      

   2. اگر «پردازشگر پیام» در درگاه ۸۰۸۲ گوش می‌دهد، به مرحله ۷ بروید.

   3. اگر «پردازشگر پیام» در درگاه ۸۰۸۲ گوش نمی‌دهد، «پردازشگر پیام» را بااستفاده از این فرمان بازراه‌اندازی کنید:

      /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. پس‌از اینکه «پردازشگر پیام» فعال شد، دوباره بررسی کنید که آیا «پردازشگر پیام» در درگاه ۸۰۸۲ گوش می‌دهد یا نه.

   6. اگر «پردازنده پیام» در درگاه ۸۰۸۲ گوش می‌دهد، به مرحله ۷ بروید.

7. بررسی کنید که آیا اکنون می‌توانید جلسه ردیابی را در واسط کاربر شروع کنید. اگر دیگر مشکل مشاهده نشد، از مراحل زیر رد شوید.

8. اگر «پردازشگر پیام» درحال اجرا است و در درگاه ۸۰۸۲ گوش می‌دهد، اما همچنان نمی‌توانید از سرورهای دیگر مثل «سرور مدیریت» متصل شوید، احتمالاً دیوار آتشی وجود دارد که اتصالات خارجی را مسدود می‌کند.

9. برای بررسی قوانین دیوار آتش، از فرمان مناسب استفاده کنید. برای مثال، می‌توانید فرمان iptables را اجرا کنید تا همه قوانین دیوار آتش تعریف‌شده در سیستم خود را فهرست کنید:

   iptables -L -n
   

10. اگر هیچ قانون دیوار آتشی برای درگاه ۸۰۸۲ تنظیم نشده است، به مشکل استفاده زیاد از منابع بروید.

11. اگر قوانین دیوار آتش در درگاه ۸۰۸۲ تنظیم شده است، به بخش «راه‌حل» در زیر بروید.

وضوح

1. با سرپرست شبکه‌تان همکاری کنید تا ترافیک ورودی/خروجی را در درگاه ۸۰۸۲ از سرورهای خارجی مجاز کنید.

اگر مشکل همچنان ادامه داشت، به اطلاعات تشخیصی ضروری بروید.

علت: محیط در «پردازشگر پیام» بار نشده است

تشخیص

1. گزارش‌های «سرور مدیریت» /opt/apigee/var/log/edge-management-server/logs/system.log را بررسی کنید و ببینید آیا درطول ایجاد جلسه ردیابی/اشکال‌زدایی خطایی وجود دارد یا نه.

2. ممکن است درطول ایجاد جلسه ردیابی/اشکال‌زدایی، پیام خطایی مانند «پاسخ معتبری از MP(s) وجود ندارد» را ببینید، همان‌طور که در زیر نشان داده شده است:

   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" ]

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. اگر یکی از خطاهای زیر را در گزارش «پردازشگر پیام» مشاهده کردید، این خطا به‌دلیل مشکلی است که در گواهینامه‌ها/کلیدهایی که به انبار کلید/انبار اعتماد مشخص‌شده در محیط مشخص‌شده اضافه شده‌اند، پیدا شده است.

   خطا شماره ۱: 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
   

   خطا شماره ۲: 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. بااستفاده از فراخوانی مدیریت API زیر، جزئیات keystore/truststore مشخص‌شده در پیام خطای نشان‌داده‌شده در مرحله قبل را دریافت کنید:

   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. برونداد نمونه نشان می‌دهد که دو گواهینامه و یک کلید در truststore myTruststore وجود دارد. «مخزن اعتماد» معمولاً کلیدی ندارد. اگر این‌طور است، بهتر است یک گواهی و یک کلید داشته باشید.

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» حذف کنید.

اگر مشکل همچنان ادامه داشت یا خطایی غیراز خطاهای ذکرشده در «مرحله ۱» بالا مشاهده کردید، به باید اطلاعات تشخیصی را جمع‌آوری کنید بروید.

علت: ورودی‌های پردازنده پیام قدیمی OR پردازنده‌های پیام غیرقابل‌دسترس

تشخیص

1. اگر «واسط کاربر Edge» زمان زیادی طول بکشد و نتواند جلسه ردیابی را ایجاد کند، در اینجا برخی‌از دلایل احتمالی آورده شده است:
   1. «سرور مدیریت» ممکن است به «پردازشگرهای پیام» غیرموجود (قدیمی) ارجاع دهد
   2. «پردازشگر(های) پیام» متوقف شده است یا دردسترس نیست
   3. «پردازنده‌های پیام» با استفاده زیاد از حافظه/واحد پردازش مرکزی مواجه شده‌اند
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. فهرست «پردازشگرهای پیام» را بااستفاده از میانای برنامه‌سازی کاربردی مدیریت زیر دریافت کنید:

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

2. نشانی IP یا نام میزبان مربوط به UUID (های) «پردازنده‌های پیام» ذکرشده در پیام خطا در گزارش‌های «سرور مدیریت» (مرحله ۳ در «تشخیص خرابی» در بالا) را یادداشت کنید. بااستفاده از یکی از روش‌های زیر، بررسی کنید که آیا این «پردازشگران پیام» معتبر هستند یا نه:

   1. جدیدترین نمودار راه‌اندازی توپولوژی «فضای ابری خصوصی»
   2. جدیدترین جدول نگاشت نام میزبان - نشانی IP سرور لبه

   اگر آن‌ها را «پردازشگر پیام» معتبر می‌دانید، به سناریو ۲ : پردازشگر (های) پیام دردسترس نیست بروید.

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. اگر در محیط‌های دیگر سازمانتان با همین مشکل مواجه هستید، «مرحله ۳» را تکرار کنید.

سناریو ۲: «پردازشگر(های) پیام» دردسترس نیست

1. با تعیین نشانی‌های IP/نام‌های میزبان براساس UUIDهای مشاهده‌شده در پیام خطا در گزارش‌های «سرور مدیریت»، به هریک از «پردازشگر(های) پیام» وارد شوید.

2. بازراه‌اندازی «پردازشگر پیام»:

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

دوباره بررسی کنید که آیا می‌توانید جلسه ردیابی ایجاد کنید یا نه. اگر مشکل برطرف نشد، به اطلاعات تشخیص خرابی ضروریبروید.

دلیل: مشکل استفاده زیاد از منابع

تشخیص

1. به هریک از «پردازشگر(های) پیام» وارد شوید و بررسی کنید که آیا از منابع - واحد پردازش مرکزی، حافظه، یا بار - استفاده زیادی می‌شود یا نه. می‌توانید از دستور top در سیستم‌عامل‌های مبتنی بر Unix برای دریافت اطلاعات استفاده از منابع فرایند «پردازشگر پیام» استفاده کنید:

   top
   

2. اگر «پردازشگر(های) پیام» از بهره‌گیری بالای منابع برخوردار نیستند، به باید اطلاعات تشخیصی را جمع‌آوری کنید بروید.

3. اگر «پردازشگر(های) پیام» از واحد پردازش مرکزی یا حافظه استفاده زیادی می‌کند، ممکن است همین امر باعث شود «پردازشگر پیام» به‌موقع به «سرور مدیریت» پاسخ ندهد. این کار درنهایت مانع از ایجاد جلسه ردیابی می‌شود.

   1. اگر هریک از «پردازنده‌های پیام» با استفاده بالای CPU مواجه است، هر ۳۰ ثانیه سه thread dumps بااستفاده از فرمان زیر تولید کنید:

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

   2. اگر هریک از «پردازشگرهای پیام» از «حافظه» زیاد استفاده می‌کند، بااستفاده از فرمان زیر heap dump تولید کنید:

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

   3. به «حل‌وفصل» منتقل کنید.

وضوح

1. «پردازشگر پیام» را بااستفاده از فرمان زیر بازراه‌اندازی کنید. این کار باید میزان استفاده از واحد پردازش مرکزی و حافظه را کاهش دهد:

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

2. فراخوان‌های API را پایش کنید و تأیید کنید که مشکل هنوز وجود دارد یا نه.

3. با پشتیبانی Apigee Edge تماس بگیرید و تخلیه‌های رشته، تخلیه پشته، و گزارش‌های «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log)) را ارائه دهید تا به آن‌ها کمک کنید علت استفاده بالای CPU/حافظه را بررسی کنند.

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

به‌ندرت ممکن است «پراکسی API» در یک یا چند «پردازشگر پیام» مستقر نشود. این اتفاق بیشتر به‌دلیل عدم وجود اعلان رویداد از «سرور مدیریت» به «پردازشگر پیام» درطول استقرار «پراکسی API» خاص رخ می‌دهد. در این مورد نیز نمی‌توانید جلسه ردیابی را در «واسط کاربر Edge» ایجاد کنید.

تشخیص

1. به هریک از «پردازشگرهای پیام» وارد شوید و بررسی کنید که آیا نسخه اصلاحی خاص «پراکسی API» بااستفاده از دستور زیر مستقر شده است یا نه:

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

   برونداد نمونه:

   فهرست بازبینی‌ها را به‌عنوان برونداد فرمان بالا خواهید دید. برای مثال، اگر نسخه مرور ۱۲ مستقر شود، برونداد را به‌صورت زیر خواهید دید:

   [ "12" ]

2. اگر نسخه اصلاح‌شده خاص «پراکسی API» به‌عنوان برونداد فرمان ذکرشده در «مرحله ۱» در بالا نشان داده نمی‌شود، «پردازشگر پیام» خاص را همان‌طور که در راه‌حل زیر توضیح داده شده است بازراه‌اندازی کنید.

3. مراحل ۱-۲ را برای همه «پردازشگرهای پیام» تکرار کنید.

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

وضوح

1. «پردازشگر پیام» خاصی را که نسخه اصلاح‌شده خاص «پراکسی API» در آن مستقر نشده است بازراه‌اندازی کنید:

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

علت: مشکل در «میانای کاربر Edge»

تشخیص

1. گزارش‌های Edge UI /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. جزئیاتی درباره اینکه کدام بخش‌های این «کتابچه راهنما» امتحان شده است و هرگونه اطلاعات آماری دیگری که به ما کمک می‌کند حل این مشکل را تسریع کنیم.