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

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

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 w odpowiedzi na wywołania interfejsu API.

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

Komunikat o błędzie

Otrzymasz ten kod stanu HTTP:

HTTP/1.1 404 Not Found

Wyświetli się 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 mógł znaleźć serwera proxy interfejsu API dla hosta wirtualnego default i ścieżki /oauth2/token.

Możliwe przyczyny

Oto niektóre możliwe przyczyny tego błędu:

Typowe etapy diagnostyki

Dzienniki NGINX i procesora komunikatów pomogą w rozwiązywaniu problemów z błędem 404. Aby sprawdzić dzienniki:

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

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

2. Sprawdź, czy w wpisach logu znajdują się te pola:

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

   Zanotuj identyfikator wiadomości z logów.

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

   Przykładowy komunikat o błędzie z dziennika procesora komunikatów

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)

W dzienniku powyżej kod błędu i komunikat o błędzie są następujące:

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

Przyczyna: proxy interfejsu API nie jest powiązane z określonym hostem wirtualnym

Jeśli proxy interfejsu API nie jest skonfigurowany do akceptowania żądań dotyczących 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 proxy proxy interfejsu API i zobacz, czy proxy interfejsu API jest skonfigurowane tak, aby akceptować żądania dotyczące hosta wirtualnego określonego w błędzie. Jest to oznaczone elementem VirtualHost. Aby to zrozumieć, przyjrzyjmy się przykładowej konfiguracji ProxyEndpoint.

   Przykładowa konfiguracja punktu końcowego proxy pokazująca, że proxy interfejsu API akceptuje żądania na bezpiecznym hoście wirtualnym

   

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

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

3. Wysyłasz żądanie do interfejsu API default VirtualHost, używając 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 ProxyEndpoint jest skonfigurowany do akceptowania żądań w 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ący atrybut VirtualHost do konfiguracji ProxyEndpoint. W przypadku powyższego przykładu możesz dodać domyślny element VirtualHost do konfiguracji ProxyEndpoint w ten sposób:

   <VirtualHost>default</VirtualHost>

   Przykładowa konfiguracja punktu końcowego proxy pokazująca dodawanie domyślnego elementu VirtualHost

   

2. W przykładzie powyżej, jeśli zamierzasz używać tylko secure VirtualHost w przypadku tego konkretnego proxy interfejsu API, wysyłaj żą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 w nowo wdrożonej wersji proxy interfejsu API

Jeśli po usunięciu konkretnego hosta wirtualnego (który był częścią wcześniej wdrożonej wersji) zostanie wdrożona nowa wersja serwera proxy interfejsu API, a klienci nadal będą używać tego hosta do wysyłania żądań do interfejsu API, może to spowodować ten problem.

Diagnostyka

1. Sprawdź konfigurację punktu końcowego proxy proxy interfejsu API, aby dowiedzieć się, czy proxy interfejsu API jest skonfigurowany do akceptowania żądań dotyczących hosta wirtualnego określonego w błędzie. Wskazuje na to element VirtualHost w konfiguracji ProxyEndpoint.
2. Jeśli host wirtualny podany w błędzie nie istnieje w konfiguracji ProxyEndpoint, wykonaj te czynności. W przeciwnym razie przejdź do następnej przyczyny – Ścieżka nie jest powiązana z żadnym proxy interfejsu API.
3. Porównaj konfigurację ProxyEndpoint wcześniej wdrożonej wersji z obecnie wdrożoną wersją.
   1. Załóżmy na przykład, że wcześniej wdrożona wersja to 5, a obecnie wdrożona wersja to 6:
      • Wirtualni hostowie skonfigurowani w punkcie końcowym serwera proxy w wersji 5

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

      • Wirtualni hosty skonfigurowani w punkcie końcowym serwera proxy w wersji 6

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

   2. W przykładzie powyżej element VirtualHost vh1 występował w revision 5,, ale został usunięty w revision 6 i zastąpiony elementem VirtualHost secure.
   3. Jeśli Ty lub Twoi klienci wysyłacie żądania do tego proxy interfejsu API za pomocą VirtualHost vh1 (który był 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 została wprowadzona celowo czy nieumyślnie w obecnie wdrożonej wersji i podejmij odpowiednie działania zgodnie z instrukcjami w sekcji Rozwiązanie.

Rozdzielczość

Jeśli zauważysz, że w nowej wersji host wirtualny lub hosty wirtualne zostały usunięte, może to być celowe lub przypadkowe. W każdym przypadku 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 (pierwsza z nich jest zalecana):

1. Utwórz nowy serwer proxy z inną ścieżką podstawową i użyj innego hosta wirtualnego (który nie występuje w poprzednio wdrożonej wersji).

2. Jeśli chcesz nadal używać istniejącego serwera proxy interfejsu API, ale z innym hostem wirtualnym, lepiej zachować dotychczasowy host wirtualny i dodać kolejny.

   Dzięki temu zmiana nie wpłynie na użytkowników tego serwera proxy interfejsu API.

3. Jeśli chcesz używać dotychczasowego serwera proxy interfejsu API i mieć 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ą świadomi zmiany 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 nie wpływu.

Scenariusz 2. Nieumyślna zmiana

Jeśli usunięcie hosta wirtualnego nastąpiło przez pomyłkę, a nie było 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 w poprzednio wdrożonej wersji. W przykładzie powyżej zmień tę sekcję:

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

   do

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

2. Wdróż ponownie wersję.

Sprawdzone metody

Zawsze zalecamy wdrażanie nowych serwerów proxy lub nowych wersji w okresie konserwacji lub gdy spodziewany jest najmniejszy ruch. Dzięki temu można uniknąć problemów, które mogą wystąpić podczas wdrażania, lub zminimalizować wpływ na ruch.

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

Jeśli proxy interfejsu API nie jest skonfigurowany do przyjmowania żądań dotyczących konkretnej ścieżki użytej w adresie 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 konkretnego proxy interfejsu API, do którego chcesz wysyłać żądania.
2. Sprawdź, czy serwer proxy interfejsu API jest skonfigurowany tak, aby akceptować żądania dotyczące konkretnej ścieżki wskazanej 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 podstawowej 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. Wyjaśnijmy to na przykładzie:
1. 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 znak path nie jest taki sam jak znak basepath i nie zaczyna się od basepathniego. Dlatego 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. Upewnij się, że path użyty w adresie URL żądania do interfejsu API jest taki sam jak basepath konkretnego proxy interfejsu API.
2. W podanym wyżej 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żyty w adresie URL żądania interfejsu API zaczyna się od basepath, może się zdarzyć, że path suffix (część, która występuje po basepath) wskazany w komunikacie o błędzie nie pasuje do żadnego z przepływów warunkowych, co może spowodować błąd 404.
2. Wyjaśnimy to na przykładzie:
   1. 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żywana w adresie URL żądania do interfejsu API to /weather/Delhi.
3. W tym przykładzie path zaczyna się od basepath /weather. Dodatkowo ma path suffix o wartości /Delhi.
4. Teraz sprawdź, czy w ProxyEndpoint nie ma przepływów warunkowych.
5. Jeśli nie ma przepływów warunkowych lub jest ich kilka, przejdź do następnej przyczyny – serwer proxy interfejsu API nie jest wdrożony w środowisku.
6. Jeśli ProxyEndpoint zawiera tylko przepływy warunkowe, sprawdź te kwestie:
   1. Jeśli warunki we wszystkich tych przepływach warunkowych sprawdzają konkretną proxy.pathsuffix (ścieżkę po ścieżce podstawowej).
   2. Jeśli parametr path suffix podany w adresie URL żądania interfejsu API nie spełnia żadnego z warunków, jest to przyczyną błędu.
7. Załóżmy, że w sekcji ProxyEndpoint mamy 2 automatyzacje, które są automatyzacjami warunkowymi, jak pokazano 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 pasuje do proxy.pathsuffix (ścieżka po ścieżce podstawowej) i /Bangalore, a drugi pasuje do /Chennai. Nie ma jednak żadnego, który pasuje do /Delhi, czyli path suffix przekazanego w adresie URL żądania do interfejsu API.
   2. Jest to przyczyna błędu 404. W takim przypadku 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 pasuje do co najmniej jednego przepływu warunkowego w punkcie końcowym proxy.
2. W podanym powyżej przykładzie możesz rozwiązać problem na jeden z tych sposobów:
   1. Jeśli chcesz zastosować określony zestaw zasad do ścieżki /Delhi, dodaj osobny przepływ z wymaganym zestawem zasad i upewnij się, że istnieje warunek pasujący do /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 do ścieżki /Delhi, w przypadku wspólnego przepływu upewnij się, że istnieje warunek, który zezwala na ogólny wzorzec /proxy.pathsuffix. Oznacza to, że zezwala na dowolną ścieżkę po basepath /weather, jak pokazano poniżej:

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

Jeśli ProxyEndpoint ma prawidłowy basepath, a path suffix określony w adresie URL interfejsu API pasuje do jednego z przepływów warunkowych, przejdź do następnej przyczyny – serwer proxy interfejsu API nie jest wdrożony w środowisku.

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

Diagnostyka

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

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

   • Jeśli Twój adres URL to http://myorg-prod.apigee.net/weather, alias hosta to myorg-prod.apigee.net.
   • Alias hosta myorg-prod.apigee.net jest skonfigurowany w ramach jednego z wirtualnych hostów w środowisku prod Twojej organizacji.
2. Sprawdź, czy konkretny serwer proxy interfejsu API jest wdrożony w określonym środowisku, które zostało ustalone w kroku 1 powyżej.
3. Jeśli serwer proxy interfejsu API nie jest wdrożony w określonym środowisku, jest to przyczyną błędu 404.
   1. W przykładzie z kroku 1 załóżmy, że serwer proxy interfejsu API nie jest wdrożony w środowisku prod. W takim przypadku to jest przyczyną błędu.
   2. Przejdź do sekcji Rozwiązanie poniżej.
4. Jeśli proxy interfejsu API jest wdrożony w określonym środowisku, przejdź do następnej przyczyny – Środowisko nie jest wczytane w procesorach wiadomości.

Rozdzielczość

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

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

Diagnostyka

1. Zaloguj się na każdy procesor komunikatów i sprawdź, czy konkretne środowisko, w którym wysyłasz żądanie do interfejsu API, jest załadowane na procesorze komunikatów. W tym celu użyj tego polecenia:

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

2. Jeśli konkretne środowisko jest wymienione w powyższym poleceniu, przejdź do następnej przyczyny: Proxy interfejsu API nie jest wdrożony na co najmniej jednym procesorze wiadomości.
3. Jeśli konkretne środowisko nie jest wymienione, sprawdź /opt/apigee/var/log/edge-message-processor/logs/system.log i /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log w sekcji Procesory wiadomości, czy podczas wczytywania środowisk nie wystąpiły błędy.
4. Może wystąpić wiele różnych błędów, które mogą spowodować niepowodzenie wczytywania środowiska w procesorze komunikatów. Rozwiązanie zależy od rodzaju błędu.

Rozdzielczość

Środowisko może nie zostać wczytane w procesorze komunikatów z wielu powodów. W tej sekcji przedstawiamy kilka możliwych przyczyn tego problemu i wyjaśniamy, jak go rozwiązać.

1. Jeśli w dzienniku procesora komunikatów zobaczysz jeden z tych błędów, oznacza to, że problem dotyczy certyfikatów lub kluczy dodanych do określonego magazynu kluczy lub magazynu zaufanych certyfikatów 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: Cannot overwrite secret key

   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 lub magazynu zaufanych certyfikatów określonego w komunikacie o błędzie wyświetlonym 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 pokazują, że w magazynie zaufanych certyfikatów znajdują się 2 certyfikaty i kluczmyTruststore. Magazyn zaufanych certyfikatów zwykle nie zawiera klucza. W takim przypadku lepiej jest mieć jeden certyfikat i jeden klucz.
4. Szczegóły 2 certyfikatów możesz uzyskać za pomocą 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 z nich wygasł lub jest starszy.
6. Usuń z magazynu zaufanych certyfikatów myTruststore wygasły lub niechciany certyfikat.

Jeśli problem nadal występuje lub widzisz inny błąd niż wymienione w kroku 1 powyżej, przejdź do sekcji Informacje diagnostyczne, które musisz zebrać.

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

Proxy interfejsu API może nie być wdrożony na co najmniej 1 procesorze wiadomości. Ten problem występuje bardzo rzadko i jest zwykle spowodowany brakiem powiadomienia o zdarzeniu z serwera zarządzania do procesora komunikatów podczas wdrażania konkretnego serwera proxy interfejsu API. W tym przypadku nie możesz też utworzyć sesji śledzenia w interfejsie Edge.

Diagnostyka

1. Zaloguj się na każdym procesorze wiadomości i sprawdź, czy konkretna wersja serwera proxy interfejsu API jest wdrożona, czy nie, używając tego polecenia:

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

2. Jeśli konkretna wersja proxy interfejsu API nie jest widoczna w wyniku polecenia wymienionego w kroku 1 powyżej, uruchom ponownie konkretny procesor komunikatów zgodnie z instrukcjami w sekcji Rozwiązanie.
3. Powtórz kroki 1–2 w przypadku wszystkich procesorów wiadomości.
4. Jeśli konkretna wersja proxy interfejsu API jest wdrożona na wszystkich procesorach wiadomości, nie jest to przyczyną tego problemu. Otwórz stronę Musisz zebrać informacje diagnostyczne.

Rozdzielczość

Ponownie uruchom konkretne procesory wiadomości, na których nie jest wdrożona konkretna wersja proxy interfejsu API.

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

Diagnozowanie problemów za pomocą monitorowania interfejsu API

Monitorowanie interfejsu API umożliwia szybkie odizolowanie obszarów problemowych w celu zdiagnozowania błędów, problemów z wydajnością i czasem oczekiwania oraz ich źródła, np. aplikacji deweloperów, serwerów proxy interfejsów API, docelowych usług backendu lub platformy interfejsu API.

Aby rozwiązać ten problem, otwórz stronę Monitorowanie interfejsu API > Zbadaj i wybierz odpowiednią datę, serwer proxy itp. Możesz zobaczyć te 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 logi, jak pokazano na zrzucie ekranu powyżej, i sprawdzić więcej informacji.

Przykładowy scenariusz pokazuje, jak rozwiązywać5xx problemy z interfejsami API za pomocą usługi API Monitoring. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba kodów stanu 404 przekroczy określony próg.

musi zbierać informacje diagnostyczne;

Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne: Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij mu te informacje.

1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
   • Nazwa organizacji
   • Nazwa środowiska
   • Nazwa proxy interfejsu API
   • Pełne polecenie curl do odtworzenia błędu
2. Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:
   • Pełny komunikat o błędzie
   • Nazwa środowiska
   • pakiet proxy interfejsu API,
   • Dzienniki procesora komunikatów /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Dane wyjściowe tych poleceń na 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. Szczegółowe informacje o sekcjach tego przewodnika, które zostały przez Ciebie wypróbowane, oraz wszelkie inne spostrzeżenia, które pomogą nam szybko rozwiązać ten problem.