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

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

Krótki opis problemu

Ten obraz przedstawia, że żądania do interfejsu API nie są przechwytywane w interfejsie Edge po rozpoczęciu sesji śledzenia:

Komunikat o błędzie

Gdy wystąpi ten problem, w interfejsie Edge nie będą wyświetlane żadne komunikaty o błędach.

Możliwe przyczyny

W tabeli poniżej znajdziesz możliwe przyczyny niepowodzeń rejestrowania żądań do interfejsu API w usłudze Edge UI Trace:

Przyczyna: żądania nieprzetworzone przez procesor wiadomości

Diagnostyka

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

Jeśli na przykład żądanie do interfejsu API nie dociera do Apigee Edge, kończy się niepowodzeniem w punkcie wejścia do Edge (tzn. routera) lub wystąpi błąd, zanim zostanie przetworzony przez procesor wiadomości, nie będzie można przechwycić logu czasu. Poniżej szczegółowo opisujemy każdy z tych scenariuszy.

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

• Przyczyna

  W tym przypadku błąd może być spowodowany problemem z rozpoznawaniem nazw DNS lub połączeniem sieciowym. Jeśli tak, podczas uruchamiania tego polecenia może pojawić się następujący błąd:

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

  curl: (6) Could not resolve host: hostName
  

• Rozdzielczość

  Możesz sprawdzić konfigurację DNS za pomocą tego polecenia:

  dig hostName

  Możesz sprawdzić połączenie sieciowe, używając tego polecenia:

  telnet hostName port

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

• Przyczyna

  W tym przypadku błąd może być spowodowany niepowodzeniem uzgadniania połączenia TLS/SSL. Jeśli tak się stanie, może pojawić się jeden z tych błędów:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Może też wystąpić błąd certyfikatu SSL.

• Rozdzielczość

  Aby rozwiązać te problemy, zapoznaj się z tymi poradnikami:

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

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

Scenariusz 3: procesor wiadomości nie może przetwarzać żądań

• Przyczyna

  W tym scenariuszu procesor komunikatów Apigee nie może znaleźć serwera proxy interfejsu API dla instancji określonego hosta wirtualnego i ścieżki. W związku z tym możesz zobaczyć jeden z następujące błędy:

  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ść

  Aby dowiedzieć się, jak rozwiązać ten problem, zapoznaj się z tym poradnikiem: 404 („Nie można zidentyfikować serwera proxy dla hosta).

Przyczyna: w drzewie klasyfikacji nie znaleziono serwera proxy interfejsu API

Diagnostyka

Jeśli procesor wiadomości nie może znaleźć serwera proxy interfejsu API w swoim drzewie klasyfikacji, żadne żądania interfejsu API kierowane do tego konkretnego serwera proxy nie będą wyświetlane w sesjach śledzenia w interfejsie Edge.

Aby sprawdzić, czy to jest przyczyną tej sytuacji, wykonaj poniższe czynności:

1. Zaloguj się do każdego z procesorów wiadomości i sprawdź, czy określona wersja żądanego interfejsu API została wdrożona w odpowiednim środowisku procesora wiadomości, korzystając z następującego 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 zostanie wersja 12, zobaczysz takie dane wyjściowe:

   [ "12" ]
   

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

2. Przeczytaj drzewo klasyfikacji i sprawdź, czy istnieje nazwa serwera proxy interfejsu API, korzystając z następującego 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 danej nazwy serwera proxy interfejsu API nie ma w drzewie klasyfikacji dowolnego z procesorów komunikatów, wykonaj poniższe rozwiązanie.

Rozwiązanie

Aby rozwiązać ten problem, wykonaj poniższe czynności. Przestrzegaj wszelkich środków 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 obciążeniu żądań.

1. Zaloguj się na każdym z hostów procesora wiadomości, w którym brakuje określonego serwera proxy interfejsu API w drzewie klasyfikacji, i użyj poniższego polecenia, aby ponownie uruchomić procesor wiadomości:

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

2. Po ponownym uruchomieniu użyj tego polecenia, aby poczekać, 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 zostanie wersja 12, zobaczysz takie dane wyjściowe:

   [ "12" ]
   

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

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

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

   Jeśli problem nadal występuje, przejdź do artykułu Wymagane zbieranie informacji diagnostycznych.

Wymagane jest zbieranie informacji diagnostycznych

Jeśli po wykonaniu powyższych instrukcji problem nie ustąpi, zbierz następujące informacje diagnostyczne i udostępnij je zespole 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