Żądania interfejsu API nie są rejestrowane w interfejsie Edge

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

Krótki opis problemu

Poniższy obraz przedstawia żądania do interfejsu API, które nie są przechwytywane w interfejsie użytkownika Edge po rozpoczęciu sesji śledzenia:

Komunikat o błędzie

W przypadku wystąpienia tego problemu w interfejsie Edge nie zostaną wyświetlone żadne komunikaty o błędach.

Możliwe przyczyny

W tabeli poniżej znajdziesz możliwe przyczyny niepowodzenia przechwytywania żądań interfejsu API w narzędziu Edge UI Trace:

Przyczyna: żądania nie zostały przetworzone przez procesor wiadomości

Diagnoza

Aby przechwycić żądanie interfejsu API w sesji śledzenia, musi ono zostać przetworzone przez procesor komunikatów komponentu Edge. Jest kilka powodów, dla których żądanie do interfejsu API może nie zostać zarejestrowane w transakcji śledzenia.

Jeśli na przykład żądanie do interfejsu API nie dotrze do Apigee Edge, w punkcie wejścia do Edge (np. routera) lub ulegnie awarii, zanim zostanie przetworzony przez procesor wiadomości, nie będzie można przechwycić śladu. Każdy z tych scenariuszy został szczegółowo opisany poniżej.

Scenariusz 1. Żądania nie docierają do Apigee Edge

• Przyczyna

  W tym przypadku błąd może być spowodowany przez rozpoznawanie nazw DNS lub problem z połączeniem sieciowym. Jeśli tak, podczas uruchamiania tego polecenia może pojawić się taki błąd:

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• Rozdzielczość

  Konfigurację DNS możesz sprawdzić za pomocą tego polecenia:

  dig hostName

  Połączenia sieciowe możesz sprawdzić za pomocą tego polecenia:

  telnet hostName port

Scenariusz 2. Żądania w routerze Edge Apigee kończą się niepowodzeniem

• Przyczyna

  W tym scenariuszu błąd może być spowodowany niepowodzeniem uzgadniania połączenia TLS/SSL. W takim przypadku może pojawić się jeden z tych błędów:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Może też pojawić się błąd certyfikatu SSL.

• Rozdzielczość

  Zapoznaj się z tymi poradnikami, aby dowiedzieć się, jak rozwiązać te problemy:

  Błędy uzgadniania połączenia TLS/SSL

  400 Nieprawidłowe żądanie – błąd certyfikatu SSL

Scenariusz 3. Podmiot przetwarzający wiadomości nie może przetworzyć żądań

• Przyczyna

  W tym scenariuszu procesor wiadomości Apigee nie może znaleźć serwera proxy interfejsu API dla określonego hosta wirtualnego i ścieżki. W rezultacie możesz zobaczyć jeden z tych błędów:

  HTTP/1.1 404 Not Found
  

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

• Rozdzielczość

  Zapoznaj się z tym scenariuszem, aby rozwiązać ten problem: 404 Nie można zidentyfikować serwera proxy dla hosta.

Przyczyna: nie znaleziono serwera proxy interfejsu API w drzewie klasyfikacji

Diagnoza

Jeśli podmiot przetwarzający wiadomości nie może znaleźć serwera proxy interfejsu API w swoim drzewie klasyfikacji, żadne żądania interfejsu API wysyłane do tego konkretnego serwera proxy nie będą wyświetlane w sesjach śledzenia w interfejsie użytkownika Edge.

Aby sprawdzić, czy tak jest w Twoim przypadku, wykonaj te czynności:

1. Zaloguj się do każdego podmiotu przetwarzającego wiadomości i sprawdź, czy konkretna wersja żądanego interfejsu API jest wdrożona w odpowiednim środowisku procesora wiadomości za pomocą tego polecenia:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Przykładowe dane wyjściowe:

   Powyższe polecenie zwróci listę wdrożonych wersji. Jeśli na przykład wdrożona jest wersja 12, wyświetlą się takie dane wyjściowe:

   [ "12" ]
   

   Jeśli nie występują przejściowe błędy HTTP 404, prawdopodobnie zobaczysz, że określona wersja została wdrożona.

2. Przeczytaj drzewo klasyfikacji i sprawdź, czy nazwa serwera proxy interfejsu API istnieje, korzystając z tego polecenia:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Powtórz kroki 1 i 2 dla każdego procesora wiadomości. Jeśli podanej nazwy serwera proxy interfejsu API nie ma w drzewie klasyfikacji dowolnego z procesorów do przetwarzania wiadomości, postępuj zgodnie z podanymi niżej instrukcjami.

Rozwiązanie

Aby rozwiązać ten problem, wykonaj poniższe czynności. Stosuj wszelkie środki ostrożności, aby uniknąć przerw w działaniu środowiska produkcyjnego, które mogą wystąpić w wyniku ponownego uruchomienia procesorów wiadomości przy dużym ładowaniu żądań.

1. Zaloguj się na wszystkie hosty procesora wiadomości, w przypadku których w drzewie klasyfikacji brakuje określonego serwera proxy interfejsu API, i użyj poniższego polecenia, aby ponownie uruchomić ten procesor:

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

2. Po ponownym uruchomieniu urządzenia za pomocą tego polecenia poczekaj, aż stanie się aktywne:

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

3. Gdy procesor wiadomości będzie gotowy, sprawdź dostępność serwera proxy interfejsu API za pomocą tego polecenia:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Przykładowe dane wyjściowe:

   Powyższe polecenie zwróci listę wdrożonych wersji. Jeśli na przykład wdrożona jest wersja 12, wyświetlą się takie dane wyjściowe:

   [ "12" ]
   

   Jeśli nie występują przejściowe błędy HTTP 404, prawdopodobnie zobaczysz, że określona wersja została wdrożona.

4. Przeczytaj drzewo klasyfikacji i sprawdź, czy nazwa serwera proxy interfejsu API istnieje, korzystając z tego polecenia:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

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

Gromadzenie informacji diagnostycznych

Jeśli po wykonaniu powyższych instrukcji problem będzie nadal występował, zbierz poniższe informacje diagnostyczne i udostępnij je zespołowi pomocy Apigee Edge:

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

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

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

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree