404 Nie można zidentyfikować serwera proxy dla hosta: <nazwa hosta wirtualnego i url: <ścieżka>

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

Krótki opis problemu

W odpowiedzi na wywołania interfejsu API aplikacja kliencka otrzymuje kod stanu HTTP 404 z komunikatem Not Found i komunikatem o błędzie Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Ten błąd oznacza, że Edge nie udało się znaleźć serwera proxy interfejsu API dla określonego hosta wirtualnego i ścieżki.

Komunikat o błędzie

Otrzymasz taki kod stanu HTTP:

HTTP/1.1 404 Not Found

Zobaczysz też komunikat o błędzie podobny do tego:

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Powyższy komunikat o błędzie oznacza, że Edge nie udało się znaleźć serwera proxy interfejsu API dla hosta wirtualnego default i ścieżki /oauth2/token.

Możliwe przyczyny

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

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Serwer proxy interfejsu API nie jest powiązany z konkretnym hostem wirtualnym	Serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań z hosta wirtualnego określonego w komunikacie o błędzie.	Użytkownicy chmury publicznej i prywatnej usługi Edge
Host wirtualny został usunięty z nowo wdrożonej wersji serwera proxy interfejsu API	Ten problem może spowodować usunięcie hosta wirtualnego z nowo wdrożonej wersji, gdy klient nadal korzysta z określonego hosta wirtualnego.	Użytkownicy chmury publicznej i prywatnej usługi Edge
Ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API	Serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań z ścieżki podanej w komunikacie o błędzie.	Użytkownicy chmury publicznej i prywatnej usługi Edge
Serwer proxy interfejsu API nie został wdrożony w środowisku	Określony serwer proxy interfejsu API nie jest wdrożony w konkretnym środowisku, w którym próbujesz wysyłać żądania do interfejsu API.	Użytkownicy chmury publicznej i prywatnej usługi Edge
Środowisko nie zostało załadowane w procesorze wiadomości	Określone środowisko (w którym próbujesz wysyłać żądania do interfejsu API) nie zostało wczytane przez procesory wiadomości z powodu błędu.	Użytkownicy chmury Private Cloud
W co najmniej jednym procesorze wiadomości nie wdrożono serwera proxy interfejsu API	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.	Użytkownicy chmury Private Cloud

Najczęstsze kroki diagnostyki

Logi NGINX i procesora wiadomości pomogą Ci rozwiązać problem z błędem 404. Aby sprawdzić dzienniki, wykonaj te czynności:

1. Wyświetl logi NGINX za pomocą tego polecenia:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. Sprawdź, czy we wpisach logu nie występują te pola:

   Pole	Wartość
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Zanotuj identyfikator wiadomości w dziennikach.

3. Sprawdź logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby sprawdzić, czy masz messaging.adaptors.http.flow.ApplicationNotFound dla konkretnego interfejsu API, czy masz unikalny identyfikator wiadomości z kroku 2 dla żądania do interfejsu API.

   Przykładowy komunikat o błędzie z dziennika procesora wiadomości

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

Powyższy dziennik zawiera kod błędu, a ten komunikat o błędzie:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Przyczyna: serwer proxy interfejsu API nie jest powiązany z konkretnym hostem wirtualnym

Jeśli serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań konkretnego hosta wirtualnego, możemy otrzymać odpowiedź 404 Not Found z komunikatem o błędzie Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnostyka

1. Sprawdź konfigurację punktu końcowego serwera proxy dla serwera proxy interfejsu API i zobacz, czy serwer proxy interfejsu API jest skonfigurowany tak, aby przyjmować żądania od hosta wirtualnego określonego w błędzie. Wskazuje to element VirtualHost. Przeanalizujmy przykładową konfigurację ProxyEndpoint, aby lepiej to zrozumieć.

   Przykładowa konfiguracja punktu końcowego serwera proxy pokazująca, że serwer proxy interfejsu API akceptuje żądania od bezpiecznego hosta wirtualnego

   

2. Załóżmy, że hosty wirtualne są zdefiniowane w konkretnym środowisku w następujący sposób:

   Nazwa	Port	Alias hosta
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Wysyłasz żądanie API do default VirtualHost przy użyciu adresu URL http://myorg-prod.apigee.net/weather
4. Ponieważ ProxyEndpoint nie ma default VirtualHost, jak pokazano w przykładzie powyżej, otrzymasz kod odpowiedzi 404 z tym komunikatem o błędzie:

   {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

5. Aby rozwiązać ten problem, przejdź do sekcji Rozwiązanie poniżej.
6. Jeśli konfiguracja ProxyEndpoint jest skonfigurowana tak, aby akceptować żądania z default VirtualHost, przejdź do następnej przyczyny – Ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API.

Rozdzielczość

1. Aby rozwiązać ten problem, dodaj brakujące elementy VirtualHost do konfiguracji ProxyEndpoint. W przykładzie powyżej możesz dodać domyślną wartość VirtualHost do konfiguracji ProxyEndpoint w ten sposób:

   <VirtualHost>default</VirtualHost>

   Przykładowa konfiguracja punktu końcowego serwera proxy z dodawanym ustawieniem domyślnym> VirtualHost>

   

2. Jeśli w powyższym przykładzie zamierzasz użyć tylko secure VirtualHost dla tego konkretnego serwera proxy interfejsu API, wyślij żądania do interfejsu API tylko do secure VirtualHost za pomocą protokołu HTTPS:

   https://myorg-prod.apigee.net/weather

Przyczyna: host wirtualny został usunięty z nowo wdrożonej wersji serwera proxy interfejsu API

Ten problem może być przyczyną wdrożenia nowej wersji serwera proxy interfejsu API po usunięciu określonego hosta wirtualnego (który był częścią poprzednio wdrożonej wersji), który jest nadal używany przez klienty do wysyłania żądań do interfejsu API.

Diagnostyka

1. Sprawdź konfigurację punktu końcowego serwera proxy dla serwera proxy interfejsu API, aby zobaczyć, czy serwer proxy interfejsu API jest skonfigurowany do akceptowania żądań hosta wirtualnego określonego w błędzie. Wskazuje to element VirtualHost w konfiguracji ProxyEndpoint.
2. Jeśli hosta wirtualnego wskazanego w błędzie nie ma w konfiguracji ProxyEndpoint, wykonaj poniższe czynności. W przeciwnym razie przejdź do następnej przyczyny – ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API.
3. Porównaj konfigurację ProxyEndpoint wcześniej wdrożonej wersji z obecnie wdrożoną.
   1. Załóżmy na przykład, że poprzednio wdrożona wersja to 5, a obecnie wdrożona wersja to 6:
      • Hosty wirtualne skonfigurowane w punkcie końcowym serwera proxy w wersji 5

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>
      

      • Hosty wirtualne skonfigurowane w punkcie końcowym serwera proxy w wersji 6

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>
      

   2. W tym przykładzie obiekt VirtualHost vh1 istniał w regionie revision 5,, ale został usunięty w revision 6 i zastąpiony przez VirtualHost secure.
   3. Jeśli więc Ty lub Twoi klienci wysyłacie żądania do tego serwera proxy interfejsu API za pomocą elementu VirtualHost vh1 (będącego częścią revision 5), otrzymasz kod odpowiedzi 404 z tym komunikatem o błędzie:

      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
      

4. Sprawdź, czy zmiana hosta wirtualnego nie została wprowadzona celowo czy przypadkowo w obecnie wdrożonej wersji i podejmij odpowiednie działania opisane w sekcji Rozwiązanie.

Rozdzielczość

Jeśli zauważysz, że hosty wirtualne lub hosty zostały usunięte w nowej wersji, może to być celowe lub przypadkowe. W każdym z tych przypadków wykonaj te czynności, aby rozwiązać problem.

Scenariusz 1: celowa zmiana

Jeśli usunięcie hosta wirtualnego jest zamierzone, możesz wybrać jedną z tych opcji, przy czym pierwsza opcja jest metodą zalecaną:

1. Utwórz nowy serwer proxy z inną ścieżką bazową i użyj innego hosta wirtualnego (który nie istnieje we wcześniej wdrożonej wersji).

2. Jeśli chcesz nadal korzystać z istniejącego serwera proxy interfejsu API, ale używasz innego hosta wirtualnego, lepiej zachować istniejącego hosta wirtualnego i dodać kolejnego hosta wirtualnego.

   Dzięki temu zmiana nie będzie miała wpływu na użytkowników tego serwera proxy interfejsu API.

3. Jeśli chcesz korzystać z istniejącego serwera proxy interfejsu API i masz tylko innego hosta wirtualnego, poinformuj o tym użytkowników z wyprzedzeniem i wprowadź tę zmianę w okresie konserwacji.

   Dzięki temu użytkownicy tego serwera proxy interfejsu API będą wiedzieć o zmianie i będą mogli używać innego hosta wirtualnego do wywoływania tego serwera proxy interfejsu API. Dlatego ta zmiana nie będzie miała na nich wpływu.

Scenariusz 2. Niezamierzona zmiana

Jeśli usunięcie hosta wirtualnego jest wynikiem błędu i nie jest zamierzone,wykonaj te czynności:

1. Zaktualizuj konfigurację ProxyEndpoint w obecnie wdrożonej wersji, aby używać tych samych hostów wirtualnych, które były używane we wcześniej wdrożonej wersji. W powyższym przykładzie zmień tę sekcję z:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>
   

    

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>
   

2. Wdróż ponownie wersję.

Sprawdzone metody

Zalecamy wdrażanie nowych serwerów proxy lub nowych wersji w okresie konserwacji lub w czasie, gdy ruch jest najmniej oczekiwany, aby uniknąć problemów występujących podczas wdrażania i zminimalizować ich wpływ na ruch.

Przyczyna: ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API

Jeśli serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań dotyczących określonej ścieżki używanej w adresie URL żądania interfejsu API, możemy otrzymać odpowiedź 404 Not Found z komunikatem o błędzie Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnostyka

1. Sprawdź konfigurację ProxyEndpoint konkretnego serwera proxy interfejsu API, dla którego chcesz wysyłać żądania do API.
2. Sprawdź, czy serwer proxy interfejsu API jest skonfigurowany do akceptowania żądań związanych z konkretną ścieżką wskazaną w komunikacie o błędzie. Aby to zrobić, wykonaj czynności opisane w scenariuszu 1 i scenariuszu 2.

Scenariusz 1. Ścieżka nie pasuje do ścieżki bazowej serwera proxy interfejsu API

1. Jeśli path wskazany w komunikacie o błędzie nie jest taki sam jak basepath konkretnego serwera proxy interfejsu API lub nie zaczyna się od basepath, może to być przyczyną błędu.
2. Przeanalizujmy przykład:
1. Wartość basepath odpowiedniego serwera proxy interfejsu API to /weather
2. URL żądania do interfejsu API to https://myorg-prod.apigee.net/climate. Oznacza to, że ścieżka użyta w adresie URL żądania do interfejsu API to /climate.
3. W tym przykładzie path różni się od basepath i nie zaczyna się od basepath. W związku z tym pojawia się ten błąd:

   {
      "fault":{
         "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
         "detail":{
            "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
         }
      }
   }

Rozdzielczość

1. Sprawdź, czy path używany w adresie URL żądania do interfejsu API jest taki sam jak basepath konkretnego serwera proxy interfejsu API.
2. W przykładzie powyżej adres URL żądania do interfejsu API powinien wyglądać tak:

   {
   https://myorg-prod.apigee.net/weather
   

Scenariusz 2: ścieżka nie pasuje do żadnego z dostępnych przepływów warunkowych

1. Jeśli element path używany w adresie URL żądania do interfejsu API zaczyna się od basepath, możliwe, że element path suffix (część występująca po basepath) wskazywanej w komunikacie o błędzie nie pasuje do żadnego z procesów warunkowych, może to spowodować błąd 404.
2. Przeanalizujmy przykład:
   1. Wartość basepath odpowiedniego serwera proxy interfejsu API to /weather
   2. URL żądania do interfejsu API to https://myorg-prod.apigee.net/weather/Delhi. Oznacza to, że ścieżka użyta w adresie URL żądania do interfejsu API to /weather/Delhi.
3. W tym przykładzie path zaczyna się od basepath /weather. Ponadto ma path suffix o wartości /Delhi.
4. Teraz sprawdź, czy w pliku ProxyEndpoint są jakieś przepływy warunkowe.
5. Jeśli nie ma przepływów warunkowych lub jest kilka przepływów bezwarunkowych, przejdź do następnej przyczyny – serwer proxy interfejsu API nie został wdrożony w środowisku.
6. Jeśli ProxyEndpoint zawiera tylko przepływy warunkowe, sprawdź, czy:
   1. Jeśli warunki we wszystkich tych przepływach warunkowych sprawdzają, czy występuje określony proxy.pathsuffix (ścieżka po ścieżce bazowej).
   2. A jeśli wartość path suffix podana w adresie URL żądania interfejsu API nie pasuje do żadnego z warunków, to jest przyczyną błędu.
7. Załóżmy, że w elemencie ProxyEndpoint mamy 2 procesy warunkowe, jak na przykładzie poniżej:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
   

   1. W powyższym przykładzie mamy 2 przepływy warunkowe: jeden pasuje do proxy.pathsuffix (ścieżka po ścieżce bazowej) do /Bangalore, a drugi – /Chennai. ale żaden nie pasuje do elementu /Delhi, który jest wartością path suffix przekazaną w adresie URL żądania do interfejsu API.
   2. To jest przyczyna błędu 404. W związku z tym pojawi się ten błąd:

      {
         "fault":{
            "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
            "detail":{
               "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
            }
         }
      }

Rozdzielczość

1. Upewnij się, że path suffix odpowiada co najmniej 1 przepływowi warunkowemu w punkcie końcowym serwera proxy.
2. Aby naprawić błąd, możesz skorzystać z tych rozwiązań:
   1. Jeśli chcesz uruchomić dowolny określony zestaw zasad dla ścieżki /Delhi, dodaj oddzielny przepływ z wymaganym zestawem zasad i sprawdź, czy istnieje warunek pasujący do elementu /Delhi /proxy.pathsuffix, jak pokazano poniżej:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. Jeśli chcesz uruchamiać wspólny zestaw zasad dla ścieżki /Delhi, upewnij się w nim, że istnieje warunek, który pozwala na użycie ogólnego /proxy.pathsuffix. Oznacza to, że dopuszcza ona dowolną ścieżkę po basepath /weather, jak pokazano poniżej:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Jeśli ProxyEndpoint ma prawidłową wartość basepath, a path suffix określony w adresie URL interfejsu API jest zgodny z jednym z przepływów warunkowych, przejdź do następnej przyczyny: serwer proxy interfejsu API nie został wdrożony w środowisku.

Przyczyna: serwer proxy interfejsu API nie został wdrożony w środowisku

Diagnostyka

1. Określ środowisko, w którym znajduje się alias hosta używany w adresie URL żądania do interfejsu API. Możesz to zrobić, sprawdzając szczegóły wszystkich hostów wirtualnych w każdym ze środowisk organizacji w interfejsie użytkownika Edge.

   Załóżmy na przykład, że masz taką konfigurację:

   • Jeśli http://myorg-prod.apigee.net/weather jest Twoim adresem URL, myorg-prod.apigee.net jest aliasem hosta.
   • Alias hosta myorg-prod.apigee.net jest skonfigurowany jako część jednego z hostów wirtualnych w środowisku prod organizacji.
2. Sprawdź, czy określony serwer proxy interfejsu API jest wdrożony w konkretnym środowisku określonym w kroku 1 powyżej.
3. Jeśli serwer proxy interfejsu API nie jest wdrożony w konkretnym środowisku, jest to przyczyną błędu 404.
   1. Załóżmy więc, że w przykładzie użytym w kroku 1 powyżej serwer proxy interfejsu API nie jest wdrożony w środowisku prod, co jest przyczyną błędu.
   2. Przejdź do sekcji Rozwiązanie poniżej.
4. Jeśli serwer proxy interfejsu API jest wdrożony w konkretnym środowisku, przejdź do następnej przyczyny – środowisko niezaładowane przez procesory wiadomości.

Rozdzielczość

Wdróż serwer proxy interfejsu API w konkretnym środowisku, w którym chcesz wysyłać żądania do interfejsu API.

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

Diagnostyka

1. Zaloguj się do każdego podmiotu przetwarzającego wiadomości i sprawdź, czy określone środowisko, w którym przesyłasz żądanie do interfejsu API, jest w nim wczytane, korzystając z tego polecenia:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Jeśli określone środowisko jest wymienione w powyższym poleceniu, przejdź do następnej przyczyny: Serwer proxy interfejsu API nie został wdrożony w co najmniej jednym procesorze wiadomości.
3. Jeśli danego środowiska nie ma na liście, sprawdź, czy podczas wczytywania środowisk nie wystąpiły błędy podczas wczytywania środowisk w /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.
4. 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 błędu, który wystąpił.

Rozdzielczość

Środowisko może nie być wczytywane w procesorze wiadomości z wielu powodów. W tej sekcji podano kilka możliwych przyczyn tego problemu i podaliśmy sposoby jego rozwiązania.

1. Jeśli w logu procesora wiadomości wyświetla się jeden z wymienionych niżej błędów, jest to spowodowane problemem z certyfikatami lub kluczami dodanymi do określonego magazynu kluczy lub magazynu kluczy 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, używając 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 sekcji Wymagane jest zbieranie informacji diagnostycznych.

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

Serwer proxy interfejsu API może nie być wdrożony w co najmniej jednym procesorze wiadomości. Ten problem występuje bardzo rzadko i najczęściej wynika z braku powiadomienia o zdarzeniu z serwera zarządzania 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 procesora wiadomości i sprawdź, czy określona wersja serwera proxy interfejsu API jest wdrożona, czy nie, korzystając z tego polecenia:

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

2. Jeśli konkretna 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.
3. Powtórz kroki 1–2 dla wszystkich procesorów wiadomości.
4. Jeśli konkretna wersja serwera proxy interfejsu API jest wdrożona we wszystkich procesorach wiadomości, nie jest to przyczyną tego problemu. Otwórz Wymagane zbieranie informacji diagnostycznych.

Rozdzielczość

Ponownie uruchom konkretne procesory wiadomości, w których określona wersja serwera proxy interfejsu API nie jest wdrożona.

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

Diagnozowanie problemów za pomocą monitorowania interfejsów API

Monitorowanie interfejsów API umożliwia szybkie wyizolowanie problematycznych obszarów w celu diagnozowania problemów dotyczących błędów, wydajności i opóźnień oraz ich źródeł, takich jak aplikacje dla programistów, serwery proxy interfejsów API, cele backendu czy platforma API.

W przypadku tego problemu możesz otworzyć stronę Monitorowanie interfejsów API > Zbadaj i wybrać odpowiednią datę, serwer proxy itd. Mogą pojawić się te informacje:

• Kod błędu: messaging.adaptors.http.flow.ApplicationNotFound
• Kod stanu: 404
• Źródło błędu: Apigee lub MP

Dodatkowo możesz kliknąć Wyświetl dzienniki, jak pokazano na zrzucie ekranu powyżej, i sprawdzić to dalej.

Przeanalizuj przykładowy scenariusz i dowiedz się, jak rozwiązać problemy z interfejsami API (5xx) za pomocą monitorowania interfejsów API. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba kodów stanu w stanie 404 przekroczy określony próg.

Musisz zebrać informacje diagnostyczne

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 te informacje.

1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
   • Nazwa organizacji
   • Nazwa środowiska
   • Nazwa serwera proxy interfejsu API
   • Wykonaj polecenie curl, aby odtworzyć błąd
2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
   • Zaobserwowano pełny komunikat o błędzie
   • Nazwa środowiska
   • Pakiet proxy interfejsu API
   • Procesor wiadomości loguje /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Dane wyjściowe następujących poleceń w każdym procesorze wiadomości.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

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

3. Informacje o wypróbowanych przez Ciebie sekcjach tego poradnika oraz o innych statystykach, które pomogą nam szybko rozwiązać ten problem.