Nie udało się utworzyć sesji śledzenia

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

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

Komunikat o błędzie

W interfejsie użytkownika Edge wyświetli się komunikat o błędzie:

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 z przykładowym komunikatem o błędzie zaobserwowanym w interfejsie Edge:

Możliwe przyczyny

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

Przyczyna Opis Instrukcje dotyczące rozwiązywania problemów
Problem z połączeniem sieciowym Błąd komunikacji między serwerem zarządzania a procesorem wiadomości spowodowany problemami z połączeniem sieciowym lub regułami zapory sieciowej. Użytkownicy chmury Edge Private Cloud
Środowisko nie zostało załadowane w procesorze wiadomości Określone środowisko (w którym próbujesz włączyć log czasu) nie zostało wczytane przez procesory wiadomości z powodu błędu.
Nieaktualne wpisy w procesorze wiadomości Serwer zarządzania ma odwołania do nieistniejących (nieaktualnych) procesorów wiadomości.
Nieosiągalny procesor wiadomości Procesor wiadomości został zatrzymany lub stał się nieosiągalny.
Problem z wysokim wykorzystaniem zasobów Procesory wiadomości wykazują wysokie wykorzystanie zasobów (procesor, pamięć lub obciążenie).
Serwer proxy interfejsu API nie został wdrożony w co najmniej jednym procesorze wiadomości Serwer proxy interfejsu API może nie być wdrożony w co najmniej jednym procesorze wiadomości z powodu braku powiadomienia o zdarzeniu podczas wdrażania.
Problem z interfejsem Edge Interfejs Edge nie może utworzyć sesji śledzenia z powodu 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że jednak występować problem z interfejsem Edge, który uniemożliwia utworzenie sesji śledzenia w interfejsie. Przejdź do sekcji Problem z interfejsem Edge.

Przyczyna: problem z połączeniem sieciowym

Diagnoza

  1. Sprawdź dziennik serwera zarządzania /opt/apigee/var/log/edge-management-server/logs/system.log, aby zobaczyć, czy podczas tworzenia sesji śledzenia lub debugowania 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 przez port nr 8082, otrzymuje błędy „Odmowa połączenia”. Z tego powodu serwer zarządzania nie może utworzyć sesji śledzenia.

  3. Jeśli nie widzisz żadnych błędów związanych z połączeniami sieciowymi lub błędów podobnych do tych powyżej, przejdź do sekcji Środowisko niezaładowane przez procesor wiadomości.

  4. Jeśli zauważysz błędy związane z połączeniami sieciowymi lub błąd podobny do opisanego powyżej, wykonaj czynności opisane poniżej.

  5. Przetestuj połączenie między serwerem zarządzania a procesorem wiadomości na porcie 8082, wykonując te czynności:

    1. Jeśli dostępny jest protokół Telnet, użyj polecenia telnet:

      telnet <MessageProcessor_IP> 8082

    2. Jeśli protokół telnet jest niedostępny, użyj narzędzia netcat, aby sprawdzić połączenie w następujący sposób:

      nc -vz <MessageProcessor_IP> 8082

    3. Jeśli pojawi się odpowiedź „Odmowa połączenia” lub „Upłynął limit czasu połączenia”, przejdź do następnego kroku.

  6. Zaloguj się do każdego podmiotu przetwarzającego wiadomości za pomocą odpowiedniego adresu IP, który spowodował wyświetlenie błędu, i wykonaj następujące 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 go ponownie za pomocą tego polecenia:

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

    4. Poczekaj, aż procesor wiadomości w pełni uruchomi się za pomocą tego polecenia:

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

    5. Po uruchomieniu procesora ponownie sprawdź, czy jest on nasłuchiwany na porcie 8082.

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

  7. Sprawdź, czy możesz teraz uruchomić sesję śledzenia w interfejsie użytkownika. Jeśli problem nie jest już obserwowany, pomiń poniższe czynności.

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

  9. Sprawdź reguły zapory sieciowej za pomocą odpowiedniego polecenia. Możesz na przykład wykonać polecenie iptables, aby wyświetlić listę wszystkich reguł zapory sieciowej zdefiniowanych w systemie:

    iptables -L -n

  10. Jeśli nie ma ustawionych reguł zapory sieciowej dla portu 8082, przejdź do sekcji Problem z wysokim wykorzystaniem zasobów.

  11. Jeśli na porcie 8082 są skonfigurowane jakieś 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 na port 8082 z serwerów zewnętrznych.

Jeśli problem nadal występuje, przejdź do artykułu Must Gather Diagnostic Information (Wymagane zbieranie informacji diagnostycznych).

Przyczyna: nie załadowano środowiska w procesorze wiadomości

Diagnoza

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

  2. Podczas tworzenia sesji śledzenia/debugowania może się pojawić komunikat o błędzie w rodzaju brak poprawnych odpowiedzi z 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}

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

  3. Jeśli nie widzisz błędu podobnego do opisanego w powyższym przykładzie, przejdź do sekcji Artykuły o nieaktualnym przetwarzaniu wiadomości.

  4. Jeśli zauważysz błąd podobny do opisanego powyżej, wykonaj te 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 załadowane przez procesory wiadomości.

  6. Zaloguj się do każdego podmiotu przetwarzającego wiadomości i sprawdź, czy środowisko, w którym próbujesz utworzyć sesję śledzenia, jest w nim wczytane za pomocą tego 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 przez procesor wiadomości. Jeśli na przykład przez procesor wiadomości załadowano środowiska preprod i test, dane wyjściowe wyglądają tak:

    [ "preprod", "test" ]

  7. Jeśli określone środowisko, np. "dev",, w którym próbujesz utworzyć sesję śledzenia, jest wymienione jako część powyższego polecenia, przejdź do sekcji Stale Message Processor IDs.

  8. Jeśli dane środowisko (np. "dev", nie jest wymienione w powyższym poleceniu, sprawdź, czy podczas wczytywania środowisk nie występują błędy /opt/apigee/var/log/edge-message-processor/logs/system.log i /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log na procesorach wiadomości.

  9. Może być wiele różnych błędów, które mogą doprowadzić do niepowodzenia wczytania środowiska w procesorze wiadomości. Rozwiązanie zależy od wystąpienia błędu.

Rozdzielczość

Środowisko może nie być załadowane w procesorze wiadomości z wielu powodów. W tej sekcji wymieniono kilka możliwych przyczyn tego problemu i wyjaśniliśmy, jak go rozwiązać.

  1. Jeśli w dzienniku procesora wiadomości występuje jeden z wymienionych niżej błędów, jest to spowodowane problemem z certyfikatami lub kluczami dodanymi do określonego magazynu kluczy/magazynu zaufania w określonym środowisku.

    Błąd 1: java.security.KeyStoreWyjątek: 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.KeyStoreWyjątek: Nie można zastąpić tajnego klucza

    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. Uzyskaj szczegółowe informacje o magazynie kluczy/magazynie zaufania określonych w komunikacie o błędzie wyświetlanym w poprzednim kroku, korzystając z tego wywołania interfejsu Management 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 wskazują, że w magazynie zaufania myTruststore są 2 certyfikaty i klucz. Magazyn zaufania zwykle nie zawiera klucza. Jeśli tak, lepiej jest mieć 1 certyfikat i 1 klucz.

  4. Uzyskaj szczegółowe informacje o 2 certyfikatach przy użyciu 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 z certyfikatów i ustal datę ważności każdego z nich.

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

Jeśli problem nadal występuje lub widzisz błędy inne niż wymienione w kroku 1, przejdź do artykułu Wymagane jest zbieranie informacji diagnostycznych.

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

Diagnostyka

  1. Jeśli interfejs Edge zajmuje dużo czasu i nie udaje się utworzyć sesji śledzenia, oto kilka możliwych przyczyn:
    1. Serwer zarządzania może wskazywać nieistniejące (nieaktualne) procesory wiadomości
    2. Procesory wiadomości zostały zatrzymane lub stały się nieosiągalne
    3. Procesory wiadomości mocno wykorzystują pamięć/procesor
  2. Sprawdź dzienniki serwera zarządzania /opt/apigee/var/log/edge-management-server/logs/system.log i zobacz, czy podczas tworzenia sesji śledzenia/debugowania wystąpiły jakieś błędy.

  3. Podczas tworzenia sesji śledzenia/debugowania możesz zobaczyć komunikat o błędzie w rodzaju „Serwer <UUID> nie jest dostępny lub osiągalny”:

    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

    Po pewnym czasie może to spowodować jeszcze jeden błąd „Upłynął limit czasu połączenia”, jak pokazano 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 2 błędy mogą być spowodowane przez konkretne procesory wiadomości:

    1. jest nieaktualny (już nie istnieje),
    2. Jest niedostępny lub z jakiegoś powodu nieosiągalny

  5. Zastosuj odpowiednie rozwiązanie w zależności od sytuacji.

Rozdzielczość

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

  1. Pobierz listę procesorów wiadomości przy użyciu tego interfejsu API:

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

  2. Zapisz adres IP lub nazwę hosta, która odpowiada identyfikatorom UUID procesorów wiadomości wymienionych w komunikacie o błędzie w dziennikach serwera zarządzania (krok 3 w sekcji Diagnostyka powyżej). Sprawdź, czy są to prawidłowe procesory wiadomości, korzystając z jednego z tych sposobów:

    1. Najnowszy diagram konfiguracji topologii chmury prywatnej
    2. Najnowszy adres IP serwera granicznego – tabela mapowania nazw hosta

    Jeśli uznasz, że podmioty przetwarzające wiadomości są prawidłowe, 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:

    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 podmiotu przetwarzającego wiadomości, określając adresy IP lub nazwy 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

Ponownie sprawdź, czy możesz utworzyć sesję śledzenia. Jeśli problem nie ustąpi, przejdź do Must Gather diagnostic Information.

Przyczyna: problem z dużym wykorzystaniem zasobów

Diagnostyka

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

    top

  2. Jeśli wykorzystanie zasobów przez procesory wiadomości nie jest wysokie, przejdź do etapu Musisz zbierać informacje diagnostyczne.

  3. Jeśli procesor wiadomości intensywnie korzysta z procesora lub pamięci, może to być przyczyną braku odpowiedzi na serwer zarządzania na czas. Z czasem uniemożliwi to utworzenie sesji śledzenia.

    1. Jeśli którykolwiek z procesorów wiadomości uzyskuje duże obciążenie, wygeneruj 3 zrzuty wątków co 30 sekund przy użyciu tego polecenia:

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

    2. Jeśli którykolwiek podmiot przetwarzający wiadomości ma duże wykorzystanie pamięci, wygeneruj zrzut stosu za pomocą tego polecenia:

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

    3. Przenieś do rozdzielczości.

Rozdzielczość

  1. Ponownie uruchom procesor wiadomości przy użyciu tego polecenia. Powinno to 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 dużego wykorzystania procesora lub pamięci).

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

W rzadkich przypadkach serwer proxy interfejsu API może nie być wdrożony w co najmniej jednym procesorze wiadomości. Dzieje się tak głównie z powodu braku powiadomienia o zdarzeniu z serwera zarządzania wysyłanego do podmiotu przetwarzającego wiadomości podczas wdrażania określonego serwera proxy interfejsu API. W tym przypadku również nie będzie można utworzyć sesji śledzenia w interfejsie użytkownika Edge.

Diagnostyka

  1. Zaloguj się do każdego podmiotu przetwarzającego wiadomości i sprawdź, czy określona wersja serwera proxy interfejsu API została wdrożona za pomocą tego polecenia:

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

    Przykładowe dane wyjściowe:

    W danych wyjściowych powyższego polecenia zobaczysz listę wersji. Jeśli na przykład wdrożona jest wersja 12, dane wyjściowe będą takie:

    [ "12" ]

  2. Jeśli określona wersja serwera proxy interfejsu API nie wyświetla się jako dane wyjściowe polecenia opisanego w kroku 1, ponownie uruchom ten procesor wiadomości zgodnie z opisem w sekcji Rozwiązanie 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 przyczyną tego problemu. Przejdź do sekcji Musi zbierać informacje diagnostyczne.

Rozdzielczość

  1. Ponownie uruchom określone procesory wiadomości, w przypadku których konkretna wersja serwera proxy interfejsu API nie jest wdrożona:

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

Przyczyna: problem z interfejsem użytkownika Edge

Diagnostyka

  1. Sprawdź dzienniki /opt/apigee/var/log/edge-ui/application.log i /opt/apigee/var/log/edge-ui/edge-ui.log interfejsu Edge i zobacz, czy nie wystąpiły błędy.
  2. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij te pliki do dalszej analizy.

Gromadzenie informacji diagnostycznych

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij je:

  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 podmiotu przetwarzającego 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 użytkownika Edge, prześlij logi tego interfejsu użytkownika Edge /opt/apigee/var/log/edge-ui/application.log i /opt/apigee/var/log/edge-ui/edge-ui.log.

  7. Szczegółowe informacje o tym, jakie sekcje tego poradnika zostały już wypróbowane, oraz o innych danych, które pomogą nam przyspieszyć rozwiązanie tego problemu.