Nie udało się utworzyć sesji śledzenia

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Użytkownik nie może utworzyć sesji śledzenia w interfejsie Edge.

Komunikat o błędzie

W interfejsie Edge pojawi się komunikat o błędzie, który widać poniżej:

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

Oto zrzut ekranu przykładowego komunikatu o błędzie zaobserwowanego w interfejsie Edge:

Możliwe przyczyny

Oto kilka możliwych przyczyn tego błędu:

Najczęstsze kroki diagnostyki

1. Uruchom ten interfejs API do zarządzania:

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

2. Jeśli pojawią się błędy, zanotuj je. Przejdź do sekcji Problem z połączeniem sieciowym.

3. Jeśli otrzymasz odpowiedź, oznacza to, że sesję śledzenia można utworzyć za pomocą interfejsu API zarządzania. Możliwe jednak, że w interfejsie Edge występuje problem, który uniemożliwia utworzenie sesji śledzenia w interfejsie. Przejdź do sekcji Problem z interfejsem Edge.

Przyczyna: problem z połączeniem sieciowym

Diagnostyka

1. Sprawdź dziennik serwera zarządzania /opt/apigee/var/log/edge-management-server/logs/system.log i sprawdź, czy podczas tworzenia sesji śledzenia/debugowania nie wystąpiły jakieś błędy.

   Przykładowy błąd z dziennika serwera zarządzania

   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. Przykładowy błąd powyżej pokazuje, że gdy serwer zarządzania próbuje połączyć się z procesorem wiadomości na porcie 8082, występują błędy „Odmowa połączenia”. W związku z tym serwer zarządzania nie może utworzyć sesji śledzenia.

3. Jeśli nie widzisz żadnych błędów związanych z połączeniem sieciowym lub błędu podobnego do pokazanego powyżej, przejdź do sekcji Środowisko niezaładowane w procesorze wiadomości.

4. Jeśli zauważysz błędy związane z połączeniem sieciowym lub błąd podobny do pokazanego w przykładzie powyżej, wykonaj czynności opisane poniżej.

5. Sprawdź połączenie między serwerem zarządzania a procesorem wiadomości na porcie 8082, wykonując następujące czynności:

   1. Jeśli usługa telnet jest dostępna, użyj polecenia telnet:

      telnet <MessageProcessor_IP> 8082
      

   2. Jeśli usługa Telnet jest niedostępna, użyj narzędzia netcat, aby sprawdzić łączność w następujący sposób:

      nc -vz <MessageProcessor_IP> 8082
      

   3. Jeśli pojawi się komunikat „Odmowa połączenia” lub „Osiągnięto limit czasu połączenia”, a następnie przejdź do następnego kroku.

6. Zaloguj się do każdego z procesorów wiadomości przy użyciu odpowiedniego adresu IP, który wyświetlił błąd, i wykonaj te czynności:

   1. Sprawdź, czy procesor wiadomości nasłuchuje na porcie 8082:

      netstat -an | grep LISTEN | grep 8082
      

   2. Jeśli procesor wiadomości nasłuchuje na porcie 8082, przejdź do kroku 7.

   3. Jeśli procesor wiadomości nie nasłuchuje na porcie 8082, uruchom ponownie go, używając tego polecenia:

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

   4. Poczekaj, aż procesor wiadomości w pełni się uruchomi, korzystając z następującego polecenia:

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

   5. Po uruchomieniu procesora wiadomości sprawdź ponownie, czy nasłuchuje on na porcie 8082.

   6. Jeśli procesor wiadomości nasłuchuje na porcie 8082, przejdź do kroku 7.

7. Sprawdź, czy możesz teraz rozpocząć sesję śledzenia w interfejsie użytkownika. Jeśli problem już nie występuje, pomiń poniższe kroki.

8. Jeśli procesor wiadomości jest uruchomiony i nasłuchuje na porcie 8082, ale nadal nie możesz połączyć się z innymi serwerami, takimi jak serwer zarządzania, prawdopodobnie istnieje zapora sieciowa, która blokuje połączenia zewnętrzne.

9. Użyj odpowiedniego polecenia, aby sprawdzić reguły zapory sieciowej. Możesz na przykład uruchomić polecenie iptables, aby wyświetlić listę wszystkich reguł zapory sieciowej zdefiniowanych w Twoim systemie:

   iptables -L -n
   

10. Jeśli nie masz ustawionych żadnych reguł zapory sieciowej dla portu 8082, przejdź do sekcji Problem wysokiego wykorzystania zasobów.

11. Jeśli na porcie 8082 są skonfigurowane jakiekolwiek reguły zapory sieciowej, przejdź do sekcji Rozwiązanie poniżej.

Rozwiązanie

1. Skontaktuj się z administratorem sieci, aby zezwolić na ruch przychodzący i wychodzący z serwerów zewnętrznych na porcie 8082.

Jeśli problem nadal występuje, przejdź do artykułu Wymagane zbieranie informacji diagnostycznych.

Przyczyna: środowisko nie zostało załadowane na procesorze wiadomości

Diagnostyka

1. Sprawdź w dziennikach serwera zarządzania /opt/apigee/var/log/edge-management-server/logs/system.log, czy podczas tworzenia sesji śledzenia/debugowania nie wystąpiły jakieś błędy.

2. Może pojawić się komunikat o błędzie, taki jak „brak prawidłowych odpowiedzi z pojedynczych członków”. podczas tworzenia sesji śledzenia/debugowania, jak pokazano poniżej:

   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}
   

   Ten błąd oznacza, że z jakiegoś powodu procesory wiadomości nie odpowiadają na serwer zarządzania.

3. Jeśli nie widzisz błędu podobnego do pokazanego w powyższym przykładzie, przejdź do sekcji Nieaktualne wpisy procesora wiadomości.

4. Jeśli zauważysz błąd podobny do pokazanego w przykładzie powyżej, wykonaj poniższe czynności.

5. Jedną z najbardziej prawdopodobnych przyczyn tego błędu jest to, że środowisko, w którym próbujesz utworzyć sesję śledzenia, nie jest wczytywane przez procesory wiadomości.

6. Zaloguj się do każdego z procesorów wiadomości i sprawdź, czy konkretne środowisko, w którym próbujesz utworzyć sesję śledzenia, jest wczytywane w procesorze wiadomości przy użyciu poniższego polecenia:

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

   Przykładowe dane wyjściowe:

   W danych wyjściowych powyższego polecenia zobaczysz listę środowisk należących do określonej organizacji, które zostały wczytane na procesor wiadomości. Jeśli na przykład środowiska preprod i test zostaną wczytane w procesorze wiadomości, dane wyjściowe będą wyglądać tak:

   [ "preprod", "test" ]

7. Jeśli określone środowisko ("dev", w którym próbujesz utworzyć sesję śledzenia, jest wymienione w ramach powyższego polecenia, przejdź do sekcji Nieaktualne wpisy procesora wiadomości.

8. Jeśli konkretnego środowiska, na przykład "dev", nie ma na liście powyższego polecenia, sprawdź /opt/apigee/var/log/edge-message-processor/logs/system.log i /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log w procesorach wiadomości pod kątem błędów podczas wczytywania środowisk.

9. Może istnieć wiele różnych błędów, które mogą prowadzić do niepowodzenia wczytywania środowiska w procesorze wiadomości. Rozwiązanie zależy od rodzaju błędu.

Rozdzielczość

Środowisko może nie być wczytane w procesorze wiadomości z wielu powodów. Ta sekcja zawiera kilka możliwych przyczyn tego problemu i wyjaśnia, jak go rozwiązać.

1. Jeśli w dzienniku procesora wiadomości zobaczysz jeden z poniższych błędów, jest to spowodowane problemem z certyfikatami/kluczami dodanymi do określonego magazynu kluczy/magazynu zaufania w określonym środowisku.

   Błąd 1: java.security.KeyStoreException: Nie można zastąpić własnego certyfikatu

   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
   

   Błąd 2: java.security.KeyStoreException: Nie można zastąpić klucza obiektu tajnego

   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. Aby uzyskać informacje o magazynie kluczy/magazynie zaufania określonym w komunikacie o błędzie wyświetlanym w poprzednim kroku, użyj tego wywołania interfejsu zarządzania API:

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

   Przykładowe dane wyjściowe:

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

3. Przykładowe dane wyjściowe pokazują, że w magazynie zaufania myTruststore są 2 certyfikaty i klucz. Magazyn zaufania zwykle nie zawiera klucza. Jeśli tak, lepiej mieć 1 certyfikat i 1 klucz.

4. Aby uzyskać szczegółowe informacje o 2 certyfikatach, użyj tego interfejsu API:

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

5. Sprawdź datę ważności każdego certyfikatu i określ, który certyfikat stracił ważność lub jest starszy.

6. Usuń wygasły lub niechciany certyfikat z magazynu zaufania „myTruststore”.

Jeśli problem nie ustąpi lub zobaczysz błąd inny niż wspomniany w kroku 1 powyżej, przejdź do sekcji Wymagane zbieranie informacji diagnostycznych.

Przyczyna: nieaktualne wpisy procesora wiadomości LUB nieosiągalne procesory wiadomości

Diagnostyka

1. Jeśli interfejs Edge będzie długo działać i nie uda się utworzyć sesji śledzenia, oto kilka możliwych przyczyn:
   1. Serwer zarządzania może odnosić się do nieistniejących (nieaktualnych) procesorów wiadomości
   2. Procesory wiadomości zostały zatrzymane lub są nieosiągalne
   3. Procesory wiadomości używają dużo pamięci/procesora
2. Sprawdź w dziennikach serwera zarządzania /opt/apigee/var/log/edge-management-server/logs/system.log, czy podczas tworzenia sesji śledzenia/debugowania nie wystąpiły jakieś błędy.

3. Może pojawić się komunikat o błędzie, taki jak „serwer <UUID>”. jest niemożliwe lub osiągalne” podczas tworzenia sesji śledzenia/debugowania, jak w tym przykładzie:

   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
   

   Może występować jeszcze jeden błąd „Osiągnięto limit czasu połączenia” za chwilę, jak widać poniżej:

   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. Te dwa błędy mogą być spowodowane przez określone procesory wiadomości:

   1. nieaktualne (już nie istnieją),
   2. Usługa jest niedostępna lub nieosiągalna z jakiegoś powodu

5. Wybierz rozwiązanie odpowiednie do sytuacji.

Rozdzielczość

Scenariusz 1 : procesory wiadomości są nieaktualne (nie istnieją)

1. Pobierz listę procesorów wiadomości przy użyciu poniższego interfejsu API do zarządzania:

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

2. Zanotuj adres IP lub nazwę hosta odpowiadające identyfikatorom UUID procesorów wiadomości wymienionym w komunikacie o błędzie w dziennikach serwera zarządzania (krok 3 w sekcji Diagnoza). Sprawdź, czy są to prawidłowe firmy przetwarzające wiadomości, korzystając z jednego z tych sposobów:

   1. Diagram konfiguracji najnowszej topologii chmury prywatnej
   2. Najnowszy adres IP serwera granicznego – tabela mapowania nazw hostów

   Jeśli uznasz, że są to prawidłowe procesory wiadomości, przejdź do scenariusza 2. Procesory wiadomości są nieosiągalne.

3. Usuń nieaktualne (nieistniejące) procesory wiadomości za pomocą poniższych interfejsów API do zarządzania:

   1. Wyrejestruj procesor wiadomości ze środowisk organizacji:

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

   2. Wyrejestruj typ serwera:

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

   3. Usuń serwer:

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

4. Powtórz krok 3, jeśli ten sam problem występuje w innych środowiskach w organizacji.

Scenariusz 2. Procesory wiadomości są nieosiągalne

1. Zaloguj się do każdego z procesorów wiadomości przez określenie adresów IP/nazw hostów na podstawie identyfikatorów UUID zaobserwowanych w komunikacie o błędzie w dziennikach serwera zarządzania.

2. Ponownie uruchom procesor wiadomości:

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

Sprawdź ponownie, czy możesz utworzyć sesję śledzenia. Jeśli problem nie ustąpi, przejdź do artykułu Wymagane zbieranie informacji diagnostycznych.

Przyczyna: problem z dużym wykorzystaniem zasobów

Diagnostyka

1. Zaloguj się do każdego z procesorów wiadomości i sprawdź, czy występuje wysokie wykorzystanie zasobów – procesora, pamięci lub obciążenia. W systemach operacyjnych typu Unix możesz użyć polecenia top, aby uzyskać informacje o wykorzystaniu zasobów w procesie procesora wiadomości:

   top
   

2. Jeśli procesory wiadomości nie wykorzystują zasobów w wysokim stopniu, przejdź do sekcji Wymagane zbieranie informacji diagnostycznych.

3. Jeśli procesory wiadomości wykazują duże obciążenie procesora lub pamięci, może to być przyczyną braku odpowiedzi przez procesor wiadomości na serwer zarządzania w odpowiednim czasie. W końcu nie będzie można utworzyć sesji śledzenia.

   1. Jeśli dowolny procesor wiadomości notorycznie obciąża procesor, generuj 3 zrzuty wątków co 30 sekund za pomocą tego polecenia:

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

   2. Jeśli dowolny procesor wiadomości wykorzystuje dużo pamięci, wygeneruj zrzut stosu za pomocą tego polecenia:

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

   3. Przesuń do rozdzielczości.

Rozdzielczość

1. Ponownie uruchom procesor wiadomości, korzystając z poniższego polecenia. To powinno zmniejszyć wykorzystanie procesora i pamięci:

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

2. Monitoruj wywołania interfejsu API i sprawdź, czy problem nadal występuje.

3. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij zrzuty wątków, zrzut stosu oraz logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby pomóc w zbadaniu przyczyny wysokiego wykorzystania procesora/pamięci).

Przyczyna: serwer proxy API nie został wdrożony w co najmniej jednym procesorze wiadomości

W rzadkich przypadkach serwera proxy interfejsu API nie można wdrożyć w co najmniej jednym procesorze wiadomości. Dzieje się tak głównie z powodu braku powiadomień o zdarzeniach z serwera zarządzania do procesora wiadomości podczas wdrażania określonego serwera proxy interfejsu API. W tym przypadku nie będziesz też mieć możliwości utworzenia sesji śledzenia w interfejsie Edge.

Diagnostyka

1. Zaloguj się do każdego z procesorów wiadomości i sprawdź, czy określona wersja serwera proxy interfejsu API została wdrożona przy użyciu następującego polecenia:

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

   Przykładowe dane wyjściowe:

   W wynikach powyższego polecenia wyświetli się lista wersji. Jeśli na przykład wdrożono wersję 12, dane wyjściowe będą wyglądać tak:

   [ "12" ]

2. Jeśli konkretna wersja serwera proxy interfejsu API nie jest wyświetlana jako dane wyjściowe polecenia wymienionego w kroku 1 powyżej, uruchom ponownie dany procesor wiadomości zgodnie z opisem w rozwiązaniu poniżej.

3. Powtórz kroki 1–2 dla wszystkich procesorów wiadomości.

4. Jeśli określona wersja serwera proxy interfejsu API jest wdrożona we wszystkich procesorach wiadomości, nie jest to przyczyna tego problemu. Przejdź do sekcji Wymagane jest zbieranie informacji diagnostycznych.

Rozdzielczość

1. Uruchom ponownie konkretne procesory wiadomości, w których nie wdrożono określonej wersji serwera proxy interfejsu API:

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

Przyczyna: problem z interfejsem Edge

Diagnostyka

1. Sprawdź w dziennikach interfejsu Edge /opt/apigee/var/log/edge-ui/application.log i /opt/apigee/var/log/edge-ui/edge-ui.log, czy nie ma błędów.
2. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij te pliki do dalszej analizy.

Wymagane jest zbieranie informacji diagnostycznych

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zbierz poniższe informacje diagnostyczne. Skontaktuj się z nimi i udostępnij je zespołowi pomocy Apigee Edge:

1. Dane wyjściowe polecenia:

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

2. Dziennik serwera zarządzania

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

3. Logi procesora wiadomości

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

4. Dane wyjściowe poleceń telnet/nc z serwera zarządzania do procesora wiadomości:

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

5. Dane wyjściowe poniższego polecenia netstat w procesorach wiadomości:

   netstat -an > netstat.txt
   

6. Jeśli problem dotyczy interfejsu Edge, prześlij dzienniki interfejsu Edge /opt/apigee/var/log/edge-ui/application.log i /opt/apigee/var/log/edge-ui/edge-ui.log..

7. Szczegółowe informacje o wypróbowanych sekcjach tego Poradnika oraz inne informacje, które pomogą nam szybciej rozwiązać ten problem.