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

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

Krótki opis problemu

Na tym obrazie widać, że gdy sesja śledzenia jest uruchomiona, żądania interfejsu API nie są rejestrowane w interfejsie Edge:

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 niepowodzenia przechwytywania żądań do interfejsu API w narzędziu Trace w interfejsie Edge:

Przyczyna Opis Instrukcje rozwiązywania problemów mające zastosowanie w przypadku
Żądania nieprzetworzone przez procesor komunikatów Aby przechwycić log czasu, żądania do interfejsu API muszą być przetwarzane przez komponent Edge o nazwie procesor komunikatów. Jeśli żądanie do interfejsu API nie dotrze do Apigee Edge lub nie powiedzie się w punkcie wejścia do Edge (np. Router) lub ulegnie awarii, zanim zostanie przetworzony przez procesor komunikatów, log czasu nie będzie mógł zostać zarejestrowany. Użytkownicy Edge Public Cloud i Private Cloud
Nie znaleziono serwera proxy interfejsu API w drzewie klasyfikacji Procesory wiadomości Apigee używają definicji reguły routingu o nazwie drzewo klasyfikacji do wysyłania żądań na podstawie nazwy hosta, ścieżki podstawowej, wersji i środowiska żądania przychodzącego. Jeśli odpowiedni serwer proxy interfejsu API zostanie z jakiegoś powodu usunięty z drzewa klasyfikacji, transakcje śledzenia mogą nie zostać wypełnione. Użytkownicy Edge Private Cloud

Przyczyna: żądania nie są przetwarzane przez procesor komunikatów

Diagnoza

Aby przechwycić żądanie do interfejsu API w sesji śledzenia, musi ono zostać przetworzone przez komponent Edge o nazwie procesor komunikatów. Istnieje 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 dociera do Apigee Edge lub nie powiedzie się w punkcie wejścia do Edge (np. Router) lub ulegnie awarii, zanim zostanie przetworzony przez procesor komunikatów, log czasu nie będzie mógł zostać zarejestrowany. Każdy z tych scenariuszy został szczegółowo opisany poniżej.

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

  • Przyczyna

    W takim przypadku błąd może być spowodowany problemem z rozpoznawaniem nazw DNS lub połączeniem sieciowym. W takim przypadku podczas uruchamiania tego polecenia może się pojawić ten 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łączenie sieciowe możesz sprawdzić za pomocą tego polecenia:

    telnet hostName port

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

Scenariusz 3. Procesor komunikatów nie może przetworzyć żądań

  • Przyczyna

    W takim przypadku procesor komunikatów Apigee nie może znaleźć serwera proxy interfejsu API dla określonego hosta wirtualnego i ścieżki. W rezultacie może się pojawić 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ść

    Aby rozwiązać ten problem, zapoznaj się z tym przewodnikiem: 404 Nie udało się zidentyfikować serwera proxy dla hosta.

Przyczyna: serwera proxy interfejsu API nie znaleziono w drzewie klasyfikacji

Diagnoza

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

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

  1. Zaloguj się w każdym procesorze komunikatów i sprawdź, czy konkretna wersja żądanego interfejsu API jest wdrożona w odpowiednim środowisku procesora komunikatów. Aby to zrobić, użyj tego polecenia:

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

    Przykładowe dane wyjściowe:

    Powyższe polecenie wyświetli listę wdrożonych wersji. Jeśli na przykład wdrożona jest wersja 12, zobaczysz te dane wyjściowe:

    [ "12" ]

    Jeśli nie występują sporadyczne błędy HTTP 404, prawdopodobnie zobaczysz, że wdrożona jest konkretna wersja.

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

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

  3. Powtórz kroki 1 i 2 w przypadku każdego procesora komunikatów. Jeśli podana nazwa proxy interfejsu API nie występuje w drzewie klasyfikacji żadnego z procesorów wiadomości, wykonaj czynności opisane poniżej.

Rozdzielczość

Aby rozwiązać ten problem, wykonaj poniższe czynności. Podejmij wszelkie niezbędne ś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 obciążeniu żądaniami.

  1. Zaloguj się na każdym z hostów procesora komunikatów, w których brakuje konkretnego proxy interfejsu API w drzewie klasyfikacji, i użyj poniższego polecenia, aby ponownie uruchomić procesor komunikatów:

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

  2. Po ponownym uruchomieniu użyj tego polecenia, aby poczekać, aż stanie się aktywny:

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

  3. Gdy procesor komunikatów będzie gotowy, sprawdź dostępność 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 wyświetli listę wdrożonych wersji. Jeśli na przykład wdrożona jest wersja 12, zobaczysz te dane wyjściowe:

    [ "12" ]

    Jeśli nie występują sporadyczne błędy HTTP 404, prawdopodobnie zobaczysz, że wdrożona jest konkretna wersja.

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

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

    Jeśli problem nadal występuje, przejdź do sekcji Wymagane informacje diagnostyczne.

Informacje diagnostyczne, które należy zebrać

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

Informacje diagnostyczne   Typ    Command
Wynik polecenia sesji śledzenia 
curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user
Log serwera zarządzania 
/opt/apigee/var/log/edge-management-server/logs/system.log
Logi procesora komunikatów 
/opt/apigee/var/log/edge-message-processor/logs/system.log
Dane wyjściowe poleceń telnet/netcat z serwera zarządzania do procesora komunikatów 
telnet MessageProcessor_IP 8082
 
nc -vz MessageProcessor_IP 8082
Wynik polecenia netstat na procesorach komunikatów 
netstat -an > netstat.txt
Lista wyjściowa wersji wdrożonych dla konkretnego proxy interfejsu API na wszystkich procesorach komunikatów. 
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
Dane wyjściowe drzewa klasyfikacji na wszystkich procesorach komunikatów 
curl -i http://localhost:8082/v1/classification/tree