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

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

Krótki opis problemu

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

Ten błąd oznacza, że Edge nie znalazł serwera proxy interfejsu API dla określonego hosta wirtualnego i ścieżki.

Komunikat o błędzie

Otrzymasz następujący kod stanu HTTP:

HTTP/1.1 404 Not Found

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

{
   "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 może znaleźć serwera proxy interfejsu API dla Host wirtualny default i ścieżka /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 niepowiązany z konkretnym hostem wirtualnym	Określony serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań na hoście wirtualnym podane w komunikacie o błędzie.	Użytkownicy chmury publicznej i prywatnej Edge
Host wirtualny został usunięty z nowo wdrożonej wersji serwera proxy interfejsu API	Usuwanie hosta wirtualnego z nowo wdrożonej wersji, gdy klient jest w dalszym ciągu używanie konkretnego hosta wirtualnego może powodować ten problem.	Użytkownicy chmury publicznej i prywatnej Edge
Ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API	Określony serwer proxy interfejsu API nie jest skonfigurowany do akceptowania żądań na wskazanej ścieżce w komunikacie o błędzie.	Użytkownicy chmury publicznej i prywatnej Edge
Serwer proxy interfejsu API nie został wdrożony w środowisku	Określony serwer proxy interfejsu API nie jest wdrożony w środowisku, w którym i prób wysyłania żądań do interfejsu API.	Użytkownicy chmury publicznej i prywatnej Edge
Środowisko nie zostało wczytane na procesorze wiadomości	Konkretne środowisko (w którym próbujesz wysłać żądania do interfejsu API) nie zostały załadowane na procesorach wiadomości z powodu błędu.	Użytkownicy Edge Private Cloud
Serwer proxy interfejsu API nie został wdrożony w co najmniej jednym procesorze wiadomości	Nie można wdrożyć serwera proxy interfejsu API w co najmniej jednym procesorze wiadomości z powodu braku powiadomienia o zdarzeniach podczas wdrażania.	Użytkownicy Edge Private Cloud

Typowe kroki diagnostyki

Logi NGINX i logi procesora wiadomości pomogą w rozwiązywaniu problemu 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 wpisy logu zawierają te pola:

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

   Zanotuj identyfikator wiadomości widoczny w dziennikach.

3. Sprawdzanie logów procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby sprawdzić, czy wartość messaging.adaptors.http.flow.ApplicationNotFound dla konkretnego interfejsu API lub jeśli posiadasz unikalny identyfikatora 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)

Kod błędu i komunikat o błędzie w powyższym dzienniku wygląda tak:

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ń dla określonego 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ź, czy w konfiguracji Proxy Endpoint (Punkt końcowy serwera proxy) znajduje się serwer proxy interfejsu API. skonfigurowano tak, aby akceptował żądania dla hosta wirtualnego wskazanego w błędzie. To jest wskazuje element VirtualHost. Przyjrzyjmy się przykładowi ProxyEndpoint aby to zrozumieć.

   Przykładowa konfiguracja punktu końcowego serwera proxy pokazująca, że serwer proxy interfejsu API akceptuje żądania bezpieczny host wirtualny

   

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

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

3. Za pomocą adresu URL wysyłasz żądanie do interfejsu API typu default (VirtualHost). http://myorg-prod.apigee.net/weather
4. ProxyEndpoint nie ma default VirtualHost, jak pokazano w z powyższego przykładu otrzymujesz kod odpowiedzi 404 z następującym komunikatem o błędzie:

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

5. Przejdź do sekcji Rozwiązanie poniżej, aby dowiedzieć się, jak rozwiązać ten problem.
6. Jeśli ProxyEndpoint jest skonfigurowane tak, aby akceptować żądania na platformie default VirtualHost, do następnej sprawy - . Ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API.

Rozdzielczość

1. Dodaj brakujący element VirtualHost do konfiguracji ProxyEndpoint w: i rozwiązać problem. 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 użyciem wartości domyślnej> VirtualHost&gt; w trakcie dodawania

   

2. Z drugiej strony, jeśli w przykładzie powyżej chcesz użyć tylko atrybutu secure VirtualHost dla tego konkretnego serwera proxy interfejsu API, a następnie 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

W przypadku wdrożenia nowej wersji serwera proxy interfejsu API po usunięciu określonego hosta wirtualnego (która była częścią wcześniej wdrożonej wersji), która jest nadal używana przez klientów do wysyłania żądań do interfejsu API, może to powodować ten problem.

Diagnostyka

1. Sprawdź konfigurację punktu końcowego serwera proxy serwera proxy interfejsu API, aby dowiedzieć się, czy skonfigurowano tak, aby akceptował żądania dla hosta wirtualnego wskazanego w błędzie. To jest wskazuje element VirtualHost w konfiguracji ProxyEndpoint.
2. Jeśli hosta wirtualnego wskazanego w błędzie nie ma w ProxyEndpoint i wykonaj podane niżej czynności. W przeciwnym razie przejdź do następnej sprawy: Ścieżka nie jest powiązana z żadnym serwerem proxy interfejsu API.
3. Porównaj konfigurację ProxyEndpoint we wcześniej wdrożonej wersji z wersją aktualnie wdrożoną wdrożoną wersję.
   1. Załóżmy na przykład, że wcześniej wdrożona wersja to 5, a wersja 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 powyższym przykładzie VirtualHost vh1 istniał w lokalizacji revision 5, , ale została usunięta w revision 6 i zastąpiona przez VirtualHost secure.
   3. Jeśli więc Ty lub Twoi klienci wysyłacie żądania do tego serwera proxy interfejsu API za pomocą VirtualHost vh1 (które było częścią revision 5), otrzymasz 404 z kodem odpowiedzi 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 została wprowadzona celowo. niecelowo w obecnie wdrożonej wersji i odpowiednie środki opisane w sekcji Rozwiązanie.

Rozdzielczość

Jeśli zauważysz, że host lub hosty wirtualne zostały usunięte w nowej wersji, może to być zamierzone lub przez wypadku. W każdym przypadku wykonaj te czynności, aby rozwiązać problem.

Scenariusz 1: zamierzona zmiana

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

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

2. Jeśli chcesz nadal używać dotychczasowego serwera proxy interfejsu API, ale używać innego hosta wirtualnego, lepiej zachować istniejący host wirtualny i dodać dodatkowego.

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

3. Jeśli chcesz używać istniejącego serwera proxy interfejsu API i masz tylko innego hosta wirtualnego: poinformuj o tym użytkowników z wyprzedzeniem i wprowadź zmianę w trakcie prac konserwacyjnych.

   Dzięki temu użytkownicy tego serwera proxy interfejsu API będą wiedzieć o zmianie i będą może używać innego hosta wirtualnego do wywoływania tego serwera proxy interfejsu API. Z tego powodu będą i nie ma wpływu na zmiany.

Scenariusz 2: niezamierzona zmiana

Jeśli host wirtualnego został usunięty przez pomyłkę i nie był zamierzony,wykonaj te czynności:

1. Zaktualizuj do użycia konfigurację ProxyEndpoint we obecnie wdrożonej wersji te same hosty wirtualne, które były używane we wcześniej wdrożonej wersji. W powyżej, zmień następującą 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

Zawsze zaleca się wdrażanie nowych serwerów proxy lub nowych wersji w okresie konserwacji lub kiedy ruch jest spodziewany najmniejszy, aby problemy pojawiające się podczas wdrażania mogły zostać uniknąć lub ograniczyć wpływ tego problemu 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ń dla określonej ścieżki używanej w metodzie URL żądania 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 dla konkretnego serwera proxy interfejsu API, którego dotyczy wysyłania żądań do interfejsu API.
2. Sprawdź, czy serwer proxy interfejsu API jest skonfigurowany tak, aby akceptował żądania dla określonej ścieżki. w komunikacie o błędzie. Aby to zrobić, wykonaj czynności podane w Scenariusz 1 Scenariusz 2.

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

1. Jeśli path wskazana w komunikacie o błędzie nie jest taki sam jak basepath określonego serwera proxy interfejsu API lub nie zaczyna się od basepath, wtedy może być przyczyną tego błędu.
2. Wyjaśnimy to na przykładzie:
1. Element basepath docelowego serwera proxy interfejsu API to /weather
2. Adres URL żądania do interfejsu API to https://myorg-prod.apigee.net/climate. Oznacza to, że ścieżka używana w adresie URL żądania do interfejsu API to /climate.
3. W tym przykładzie path to nie to samo co basepath. nie zaczyna się od basepath. W związku z tym pojawia się następujący błąd:

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

Rozdzielczość

1. Upewnij się, że pole path używane w adresie URL żądania do interfejsu API jest takie samo jak basepath określonego serwera proxy interfejsu API.
2. W powyższym przykładzie 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 path używany w adresie URL żądania interfejsu API zaczyna się od basepath, może się zdarzyć, że path suffix (część występująca po parametrze basepath) wskazane w komunikacie o błędzie nie pasują do żadnego z warunków to może to spowodować błąd 404.
2. Wyjaśnimy to na przykładzie:
   1. Element basepath docelowego serwera proxy interfejsu API to /weather
   2. Adres 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 /weather basepath. Dodatkowo ma path suffix o wartości /Delhi.
4. Następnie sprawdź, czy w ProxyEndpoint są jakieś przepływy warunkowe.
5. Jeśli nie ma przepływów warunkowych lub jest kilka przepływów niewarunkowych, otwórz następna przyczyna - Serwer proxy interfejsu API nie został wdrożony w środowisku.
6. Jeśli w elemencie ProxyEndpoint występują tylko przepływy warunkowe, sprawdź te elementy:
   1. Jeśli warunki we wszystkich procesach warunkowych sprawdzają się w przypadku konkretnego elementu proxy.pathsuffix (ścieżka po ścieżce bazowej).
   2. A jeśli path suffix określony w adresie URL żądania API nie pasuje do żadnego z warunków, to to jest przyczyną błędu.
7. Załóżmy, że w ProxyEndpoint mamy 2 przepływy i oba są przepływy warunkowe jak poniżej:

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

   1. W przykładzie powyżej mamy 2 przepływy warunkowe. Jeden z nich pasuje proxy.pathsuffix (ścieżka za ścieżką bazową) do: /Bangalore i inny pasuje do: /Chennai. Nie ma jednak żadnego pasującego do zapytania /Delhi czyli identyfikator path suffix przekazany w adresie URL żądania do interfejsu API.
   2. To jest przyczyna błędu 404. W związku z tym pojawi się następujący 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 jest zgodny z co najmniej 1 przepływem warunkowym w punkcie końcowym serwera proxy.
2. W przykładzie powyżej możesz użyć tych rozwiązań:
   1. Jeśli chcesz zastosować określony zestaw zasad dla ścieżki /Delhi, dodaj osobny proces z wymaganym zestawem zasad i dopilnuj, aby był spełniony warunek zgodny z /proxy.pathsuffix /Delhi, jak pokazano poniżej:

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

   2. Jeśli chcesz zastosować wspólny zestaw zasad dla ścieżki /Delhi, wówczas w należy uwzględnić warunek, który pozwala na użycie /proxy.pathsuffix Oznacza to, że będzie zezwalać na każdą ścieżkę po basepath /weather jak poniżej:

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

Jeśli ProxyEndpoint zawiera poprawną wartość basepath i element path suffix określony w adresie URL interfejsu API pasuje do jednego z przepływów warunkowych, a następnie przechodzi do kolejnej 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 istnieje alias hosta używany w adresie URL żądania do interfejsu API. Można to zrobić, sprawdzając szczegóły wszystkich hostów wirtualnych w każdym środowisku. organizacji w interfejsie Edge.

   Załóżmy na przykład, że konfiguracja jest taka:

   • Jeśli http://myorg-prod.apigee.net/weather to Twój URL, myorg-prod.apigee.net to alias hosta.
   • Alias hosta myorg-prod.apigee.net jest skonfigurowany jako część jednej z hosty wirtualne w środowisku prod Twojej organizacji.
2. Sprawdź, czy dany serwer proxy interfejsu API został wdrożony w konkretnym środowisku określonym w kroku 1 powyżej.
3. Jeśli serwer proxy interfejsu API nie jest wdrożony w danym środowisku, to jest przyczyną błąd 404.
   1. Zatem w przykładzie użytym w kroku 1 powyżej załóżmy, że serwer proxy interfejsu API nie został wdrożony prod, to to 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: Nie wczytano środowiska na procesorach wiadomości.

Rozdzielczość

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

Przyczyna: środowisko nie zostało wczytane na procesorach wiadomości

Diagnostyka

1. Zaloguj się do każdego z procesorów wiadomości i sprawdź, czy środowisko, w którym żądania do interfejsu API są wczytywane do procesora wiadomości za pomocą następującego polecenia:

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

2. Jeśli konkretne środowisko jest wymienione w ramach powyższego polecenia, przejdź do następnej przyczyny: Nie wdrożono serwera proxy interfejsu API w co najmniej jednym procesorze wiadomości.
3. Jeśli danego środowiska nie ma na liście, sprawdź, /opt/apigee/var/log/edge-message-processor/logs/system.log i /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log w: Procesory komunikatów do wykrywania błędów podczas wczytywania środowisk.
4. Może być wiele różnych błędów, które mogą prowadzić do niepowodzeń podczas wczytywania środowiska do procesora wiadomości. Rozwiązanie zależy od rodzaju błędu.

Rozdzielczość

Środowisko może nie zostać załadowane w procesorze wiadomości z wielu powodów. Ta sekcja przedstawia kilka możliwych przyczyn tej sytuacji i wyjaśnia, jak ją rozwiązać. i rozpoznają problem.

1. Jeśli w dzienniku procesora wiadomości pojawi się jeden z poniższych błędów, jest on spowodowany przez znaleziono problem z certyfikatami/kluczami, które zostały dodane do określonego magazynu kluczy/magazynu kluczy 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. Pobierz szczegóły magazynu kluczy/magazynu zaufania określonego w komunikacie o błędzie wyświetlanym w w poprzednim kroku przy użyciu 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 są 2 certyfikaty i klucz myTruststore Magazyn zaufania zwykle nie zawiera klucza. Jeśli tak, jest lepiej jest 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 zaufanego magazynu myTruststore.

Jeśli problem nadal występuje lub widzisz błąd inny niż wymienione w kroku 1 powyżej przejdź do sekcji Wymagane są informacje diagnostyczne.

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

Nie można wdrożyć serwera proxy interfejsu API w co najmniej jednym procesorze wiadomości. Ten problem występuje bardzo rzadko i zdarza się głównie z powodu brakującego powiadomienia o zdarzeniu przesyłanego przez serwer zarządzania do Procesor komunikatów podczas wdrażania określonego serwera proxy interfejsu API. W tym przypadku również nie można utworzyć sesji śledzenia w interfejsie Edge.

Diagnostyka

1. Zaloguj się do każdego z procesorów wiadomości i sprawdź, czy jego wersja Serwer proxy interfejsu API został wdrożony lub nie używa tego polecenia:

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

2. Jeśli określona wersja serwera proxy interfejsu API nie wyświetla się jako wynik polecenia wymienione w kroku 1 powyżej, a następnie uruchom ponownie określony procesor wiadomości zgodnie z opisem na stronie Rozwiązanie.
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, to nie jest przyczyna tego problemu. Przejdź do Musi zbierać informacje diagnostyczne.

Rozdzielczość

Uruchom ponownie konkretne procesory wiadomości, na których jest określona wersja serwera proxy interfejsu API nie wdrożono.

/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. do diagnozowania błędów, wydajności i opóźnień oraz problemów z ich źródłem, takich jak aplikacje Serwery proxy interfejsu API, cele backendu lub platforma API.

Aby rozwiązać ten problem, możesz przejść do sekcji Monitorowanie interfejsów API > Zbadaj stronę wybierz odpowiednią datę, serwer proxy itd. mogą zostać wyświetlone następujące szczegóły:

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

Możesz też kliknąć Wyświetl dzienniki (jak pokazano na zrzucie ekranu powyżej), i sprawdź więcej.

Przeanalizuj przykładowy scenariusz pokazujący, jak Rozwiąż problemy z interfejsami API: 5xx przy użyciu API Monitoring. Możesz na przykład chcesz skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba kodów stanu (404) przekroczy dla konkretnego progu.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, 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 serwerów proxy interfejsu API
   • Logi procesora wiadomości /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Dane wyjściowe poniższych poleceń na każdym z procesorów 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. szczegółowe informacje o wypróbowanych sekcjach tego poradnika i innych statystykach, pomoże nam szybko rozwiązać ten problem.