503 Usługa niedostępna – brak aktywnych celów – błędy w stanie kontroli stanu (HealthCheckFailures)

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

Filmy

Więcej informacji o błędach 503 znajdziesz w filmach:

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu odpowiedzi HTTP 503 z kodem stanu komunikat Service Unavailable (Usługa niedostępna) i kod błędu NoActiveTargets (NoActiveTargets). dla żądań serwera proxy interfejsu API.

Komunikat o błędzie

Wyświetli się następująca odpowiedź o błędzie:

HTTP/1.1 503 Service Unavailable
  

W odpowiedzi HTTP wyświetli się następujący komunikat o błędzie:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

Możliwe przyczyny

Zwykle występuje odpowiedź HTTP 503 Service Unavailable (usługa niedostępna) z kodem błędu NoActiveTargets. gdy używasz co najmniej 1 serwera docelowego w konfiguracji docelowego punktu końcowego na serwerze proxy interfejsu API.

Ten scenariusz obejmuje temat 503 Service Unavailable (Usługa niedostępna 503) z kodem błędu Wartość NoActiveTargets wywołana z powodu błędów kontroli stanu. Więcej informacji o innych przyczynach tego błędu znajdziesz w tym poradniku.

Niepowodzenia kontroli stanu

Niepowodzenia kontroli stanu będą obserwowane tylko wtedy, gdy skonfigurujesz Monitorowanie stanu w ramach konfiguracji równoważenia obciążenia serwera docelowego w docelowym punkcie końcowym serwera proxy interfejsu API.

Gdy serwer docelowy nie przejdzie kontroli stanu, Edge zwiększa liczbę błędów tego serwera. Jeśli liczba niepowodzeń kontroli stanu dla tego serwera osiągnie wstępnie zdefiniowany próg (<MaxFailures>), Procesor wiadomości zapisuje w pliku dziennika poniższy komunikat z ostrzeżeniem:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

Komunikat z ostrzeżeniem zawiera następujące informacje. Dzięki temu dowiesz się, który serwer docelowy osiągnął liczbę żądań MaxFailure:

• Nazwa serwera docelowego
• Nazwy organizacji i środowisk
• Nazwa serwera proxy interfejsu API
• Nazwa docelowego punktu końcowego

Potem Edge przestanie wysyłać kolejne żądania do tego konkretnego serwera. Gdy wszystkie wartości docelowe serwerów skonfigurowanych w konfiguracji systemu równoważenia obciążenia osiągnie liczbę MaxFailure, kolejne Odpowiedzi na żądania do interfejsu API są wysyłane z komunikatem 503 Service Unavailable (usługa niedostępna) kodem błędu NoActiveTargets.

Użycie Monitora stanu pomaga Apigee Edge automatycznie dodawać serwer docelowy z powrotem do i rotacji, gdy stanie się sprawna, bez konieczności ponownego wdrażania serwera proxy interfejsu API.

Oto możliwe przyczyny błędów kontroli stanu:

Typowe kroki diagnostyki

Określ identyfikator wiadomości nieudanego żądania

Częste komunikaty o błędach

Gdy podczas używania serwerów docelowych występuje błąd, a procesor wiadomości próbuje nawiązać połączenie z serwerem backendu, w wynikach wyszukiwania pojawi się kilka typowych komunikatów o błędach. Logi procesora wiadomości. Błędy te są rejestrowane po rzeczywistym komunikacie o wyjątku lub błędzie. która doprowadziła do niepowodzenia.

Typowe komunikaty o błędach obserwowane w dziennikach procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log) dla 503 Service Unavailable (Usługa niedostępna) z kodem błędu NoActiveTargets są następujące:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

Te komunikaty o błędach oznaczają, że nie udało się wysłać żądania do serwera backendu z powodu błędu niepowodzenie. W związku z tym procesor wiadomości wysyła komunikat 503 Service Unavailable (Usługa niedostępna 503). z kodem błędu NoActiveTargets w odpowiedzi na żądanie klienta.

Przyczyna: przekroczenie limitu czasu połączenia

Diagnostyka

1. Określ identyfikator wiadomości nieudanego żądania.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Zobaczysz typowe komunikaty o błędach dotyczące identyfikatora wiadomości. Pamiętaj jednak: aby poznać rzeczywistą przyczynę błędów kontroli stanu, przewiń nad tymi typowe komunikaty o błędach i sprawdź, czy nie występują błędy HEALTH MONITOR.

   Na przykład komunikat o błędzie HEALTH MONITOR oznacza, że wystąpił błąd procesora komunikatów z błędem przekroczenia limitu czasu połączenia podczas wysyłania żądania do interfejsu API kontroli stanu:

   Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
   java.net.ConnectException: Connection timed out (Connection timed out)
   	at java.net.PlainSocketImpl.socketConnect(Native Method)
   	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   …<snipped>
           

   Jeśli ten błąd powtarza się MaxFailure razy skonfigurowany w kontroli zdrowia, zobaczysz ostrzeżenie podobne do tego:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Uważnie przeczytaj informacje podane w ostrzeżeniu. Upewnij się, że MaxFailure dla serwera docelowego używanego na określonym serwerze proxy API, którego używasz, pojawia się kod odpowiedzi 503 z kodem błędu NoActiveTargets.

4. W powyższym przykładzie kontrola stanu zakończyła się błędem connection timed out. Sprawdź, czy możesz połączyć się z konkretnym serwerem backendu bezpośrednio z poziomu Procesory wiadomości za pomocą polecenia telnet:

telnet <BackendServer-HostName> 443
      

5. Jeśli możesz połączyć się z serwerem backendu, możesz zobaczyć komunikat podobny do tego: Połączono z serwerem backendu. Może to być problem przejściowy, może on zostać rozwiązany lub jest problemem przejściowym. Powtórz krok 4 kilka razy (co najmniej 10 razy) i sprawdź wynik.
1. Jeśli w poleceniu telnet nie występują błędy, problem jest taki: . Sprawdź ponownie, czy błędy kontroli stanu ustały. Jeśli tak, nie musisz tego robić coś więcej.
2. Jeśli nie możesz połączyć się z serwerem backendu za pomocą polecenia telnet, być może występuje problem z siecią lub Twój serwer backendu jest zajęty.
6. Jeśli nie możesz połączyć się z serwerem backendu za pomocą polecenia telnet, może to być spowodowane tym, że ruch z procesorów wiadomości na konkretnym serwerze backendu nie jest dozwolony.

Rozdzielczość

Jeśli błąd connection timed out jest stale obserwowany, upewnij się, że backend Serwer nie ma żadnych ograniczeń zapory sieciowej i dopuszcza ruch z procesorów brzegowych Apigee. Na przykład w systemie Linux możesz użyć parametru iptables, aby zezwolić na ruch z Adresy IP procesora wiadomości na serwerze backendu.

Jeśli problem nie ustąpi, skontaktuj się z administratorem sieci, aby go znaleźć i rozwiązać. Jeśli potrzebujesz dodatkowej pomocy Apigee, skontaktuj się z zespołem pomocy Apigee.

Przyczyna: bezpieczne żądanie na niezabezpieczonym porcie

Diagnostyka

1. Określ identyfikator wiadomości nieudanego żądania.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Zobaczysz typowe komunikaty o błędach odpowiadające identyfikatorowi wiadomości. Aby jednak poznać faktyczną przyczynę błędów kontroli stanu, przewiń powyżej typowe komunikaty o błędach i sprawdź, czy nie występują błędy HEALTH MONITOR.

   Na przykład może pojawić się błąd HEALTH MONITOR:

   Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
           at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
           at sun.security.ssl.InputRecord.read(InputRecord.java:527)
           at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
   …<snipped>
           

   Jeśli ten błąd powtórzy się kilka razy (MaxFailure) w monitorowaniu zdrowia, zobaczysz ostrzeżenie podobne do tego:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Uważnie przeczytaj informacje podane w ostrzeżeniu. Upewnij się, że MaxFailure dla serwera docelowego używanego na określonym serwerze proxy API, którego używasz, pojawia się kod odpowiedzi 503 z kodem błędu NoActiveTargets.

4. Kontrola stanu zakończyła się błędem:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   Komunikat o błędzie i URL wskazują przyczynę tego problemu: wykonano bezpieczne wywołanie (HTTPS) z niezabezpieczonego portu 80.

   Ten błąd może wystąpić w tych 2 przypadkach:

   • Bezpieczny serwer docelowy zdefiniowany z niezabezpieczonym portem
   • Zdefiniowano bezpieczny serwer docelowy, ale kontrola stanu została skonfigurowana z użyciem niezabezpieczonego portu

   Bezpieczny port, który nie jest zabezpieczony

   Scenariusz 1. Bezpieczny serwer docelowy zdefiniowany z niezabezpieczonym portem

   Jeśli zdefiniujesz bezpieczny serwer docelowy z niezabezpieczonym portem, takim jak 80, otrzymasz ten błąd. Aby sprawdzić, czy to jest przyczyną tego problemu, wykonaj te czynności:

   1. Sprawdź definicję serwera docelowego używanego w konfiguracji docelowego punktu końcowego.

   Użyj Pobierz interfejs TargetServer API aby uzyskać definicję serwera docelowego.

   Dane wyjściowe definicji serwera docelowego

   <TargetServer name="mocktarget">
     <Host>mocktarget.apigee.net</Host>
     <Port>80</Port>
     <IsEnabled>true</IsEnabled>
     <SSLInfo>
         <Enabled>true</Enabled>
     </SSLInfo>
   </TargetServer>
             

   W powyższym przykładzie definicja wskazuje, że serwer docelowy mocktarget jest bezpieczny serwera zgodnie z blokiem SSLInfo. Jest on jednak skonfigurowany za pomocą niezabezpieczonego portu 80.

   2. Teraz sprawdź konfigurację monitorowania stanu dla serwera docelowego w konfiguracji docelowego punktu końcowego:

      Konfiguracja monitorowania zdrowia

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      Zwróć uwagę, że w parametrze <Port> nie określono żadnego elementu <Port> Konfiguracja monitorowania stanu powyżej. W tym przypadku procesor wiadomości na brzegu używa portu określone w definicji serwera docelowego (czyli 80) na potrzeby wywołań interfejsu API kontroli stanu.

   3. Zgodnie z powyższymi informacjami przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako bezpieczny serwer (włączony jest blok SSLInfo), ale z niezabezpieczonym portem 80.

   Bezpieczny docelowy port HM, który nie jest zabezpieczony

   Scenariusz 2. Zdefiniowano bezpieczny serwer docelowy, ale kontrola stanu została skonfigurowana z niezabezpieczonym portem

   Jeśli zdefiniowany jest bezpieczny serwer docelowy, a kontrola stanu jest skonfigurowana z parametrem niezabezpieczonego portu, na przykład 80, pojawia się ten błąd. Wykonaj te czynności, aby przejść weryfikację jeśli to jest przyczyną tego problemu:

   1. Sprawdź definicję serwera docelowego używanego w konfiguracji docelowego punktu końcowego.

      Użyj instrukcji Pobierz interfejs TargetServer API, aby uzyskać definicję serwera docelowego.

      Dane wyjściowe definicji serwera docelowego

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
              

      W powyższym przykładzie definicja wskazuje, że serwer docelowy mocktarget jest serwerem bezpiecznym zgodnie z blokiem SSLInfo.

   2. Następnie sprawdź konfigurację monitorowania stanu dla serwera docelowego w konfiguracji docelowego punktu końcowego:

      Konfiguracja monitorowania zdrowia

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      W powyższym przykładzie monitor stanu zdrowia jest skonfigurowany z niezabezpieczonym portem 80, co wskazuje element <Port>.

   3. Zgodnie z powyższymi informacjami przyczyną tego błędu jest to, że zdefiniowano serwer docelowy jako bezpieczny serwer (bo włączony jest blok SSLInfo) i korzysta z bezpiecznego portu 443, ale jest skonfigurowana do przeprowadzania kontroli stanu przy użyciu niezabezpieczonego portu 80 (określonego w elemencie <Port>).

      Oznacza to, że w tym przypadku Edge udostępnia interfejsy API kontroli stanu jako bezpieczne wywołanie z niezabezpieczonym na porcie 80 i kończy się niepowodzeniem z powodu powyższego błędu.

Rozdzielczość

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    

Przyczyna: niezabezpieczone żądanie w bezpiecznym porcie

Diagnostyka

1. Określ identyfikator wiadomości nieudanego żądania.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Zobaczysz typowe komunikaty o błędach dotyczące identyfikatora wiadomości. Aby jednak poznać faktyczną przyczynę błędów kontroli stanu, przewiń powyżej typowe komunikaty o błędach i sprawdź, czy nie występują błędy HEALTH MONITOR.

   Na przykład może pojawić się błąd HEALTH MONITOR:

   Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
   …<snipped>
             

   Jeśli ten błąd powtórzy się kilka razy (MaxFailure) w monitorowaniu zdrowia, zobaczysz ostrzeżenie podobne do tego:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

   Uważnie przeczytaj informacje podane w ostrzeżeniu. Upewnij się, że MaxFailure dla serwera docelowego używanego na określonym serwerze proxy API, którego używasz, pojawia się kod odpowiedzi 503 z kodem błędu NoActiveTargets.

4. Kontrola stanu zakończyła się błędem:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   Komunikat o błędzie i URL wskazują przyczynę tego problemu: wykonano niezabezpieczone wywołanie (HTTP) przez zabezpieczony port 443.

   Ten błąd może wystąpić w tych 2 przypadkach:

   • Niezabezpieczony serwer docelowy zdefiniowany z bezpiecznym portem
   • Zdefiniowano niezabezpieczony serwer docelowy, ale kontrola stanu została skonfigurowana z użyciem bezpiecznego portu

   Niezabezpieczony bezpieczny port docelowy

   Scenariusz 1. Niezabezpieczony serwer docelowy zdefiniowany za pomocą bezpiecznego portu

   Jeśli zdefiniujesz niezabezpieczony serwer docelowy z zabezpieczonym portem, takim jak 443, pojawia się taki błąd. Aby sprawdzić, czy to jest przyczyną tego problemu, wykonaj te czynności:

   1. Sprawdź definicję serwera docelowego używanego w konfiguracji docelowego punktu końcowego.

      Użyj instrukcji Pobierz interfejs TargetServer API, aby uzyskać definicję serwera docelowego.

      Dane wyjściowe definicji serwera docelowego

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
                    

      W powyższym przykładzie definicja wskazuje, że serwer docelowy mocktarget jest niezabezpieczonej serwerem, ponieważ nie ma bloku SSLInfo. Jest jednak nieprawidłowo skonfigurowany przy użyciu bezpiecznego portu 443.

   2. Teraz sprawdź konfigurację monitorowania stanu dla serwera docelowego w konfiguracji docelowego punktu końcowego:

      Konfiguracja monitorowania zdrowia

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      Zwróć uwagę, że w kontroli zdrowia nie określono elementu <Port>. powyżej. W tym przypadku procesor wiadomości na brzegu użyje portu określonego w definicji serwera docelowego, czyli 443.

   3. Zgodnie z powyższymi informacjami przyczyną tego błędu jest to, że zdefiniowano serwer docelowy jako niezabezpieczonego serwera (ponieważ nie został zdefiniowany blok SSLInfo), ale z bezpiecznym portem 443.

      Oznacza to, że Edge wykonuje kontrole stanu jako niezabezpieczone wywołanie z bezpiecznym portem 443 i kończy się niepowodzeniem z wspomnianym wyżej błędem.

   Niezabezpieczony bezpieczny port HM

   Scenariusz 2. Zdefiniowano niezabezpieczony serwer docelowy, ale kontrola stanu została skonfigurowana z użyciem bezpiecznego portu

   Jeśli zdefiniowany jest niezabezpieczone serwer docelowy, a kontrola stanu jest skonfigurowana z użyciem bezpiecznego portu, np. 443, pojawia się taki błąd. Aby sprawdzić, czy to jest przyczyną tego problemu, wykonaj te czynności:

   1. Sprawdź definicję serwera docelowego używanego w konfiguracji docelowego punktu końcowego.

      Użyj instrukcji Pobierz interfejs TargetServer API, aby uzyskać definicję serwera docelowego.

      Dane wyjściowe definicji serwera docelowego

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      W powyższym przykładzie definicja wskazuje, że serwer docelowy mocktarget jest niezabezpieczony (ponieważ nie ma bloku SSLInfo) skonfigurowanym prawidłowo niezabezpieczonym portem 80.

   2. Następnie sprawdź konfigurację monitorowania stanu dla serwera docelowego w konfiguracji docelowego punktu końcowego:

      Konfiguracja monitorowania zdrowia

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      W powyższym przykładzie monitor stanu zdrowia jest skonfigurowany z bezpiecznym portem 443, co wskazuje element <Port>.

   3. Według powyższych informacji przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako niezabezpieczonego serwera (ponieważ nie został zdefiniowany blok SSLInfo) z niezabezpieczonym portem 80, ale kontrola stanu jest skonfigurowana do przeprowadzania kontroli stanu przy użyciu bezpiecznego portu 443 (określonego w elemencie <Port>).

      Oznacza to, że w tym przypadku Edge wykonuje kontrole stanu jako niezabezpieczone wywołanie z bezpiecznym portem 443 i kończy się niepowodzeniem z powodu powyższego błędu.

Rozdzielczość

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

Przyczyna: interfejs API kontroli stanu zwraca błąd

Diagnostyka

1. Określ identyfikator wiadomości nieudanego żądania.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Zobaczysz typowe komunikaty o błędach odpowiadające identyfikatorowi wiadomości. Aby jednak poznać faktyczną przyczynę błędów kontroli stanu, przewiń powyżej typowych komunikatów o błędach i sprawdź, czy nie ma żadnych błędów/ostrzeżeń dotyczących MONITORU HEALTH.

   Na przykład możesz zobaczyć ostrzeżenie HEALTH MONITOR, które widać poniżej:

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
   Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
           

   Jeśli ten błąd powtórzy się kilka razy (MaxFailure) w monitorowaniu zdrowia, zobaczysz ostrzeżenie podobne do tego:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Uważnie przeczytaj informacje podane w ostrzeżeniu. Upewnij się, że MaxFailure dla serwera docelowego używanego na określonym serwerze proxy API, którego używasz, pojawia się kod odpowiedzi 503 z kodem błędu NoActiveTargets.

4. Kontrola stanu zwróciła komunikat ostrzegawczy:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   Powyższy komunikat ostrzegawczy stwierdza, że oczekiwany kod odpowiedzi dla interfejsu API kontroli stanu to 200, ale rzeczywista odpowiedź to kod 404. Jest to więc traktowane jako niepowodzenie.

5. Zanim poznasz przyczynę odpowiedzi błędu za pomocą interfejsu API kontroli stanu, ustal, dlaczego Edge w przypadku interfejsu API kontroli stanu oczekuje kodu odpowiedzi 200. W tym celu sprawdź Monitor stanu dla serwera docelowego w konfiguracji docelowego punktu końcowego:

   Konfiguracja monitorowania zdrowia

   <HealthMonitor>
     <IsEnabled>true</IsEnabled>
     <IntervalInSec>5</IntervalInSec>
     <HTTPMonitor>
       <Request>
         <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
         <Port>443</Port>
         <Verb>GET</Verb>
         <Path>/status/200</Path>
       </Request>
       <SuccessResponse>
         <ResponseCode>200</ResponseCode>
       </SuccessResponse>
     </HTTPMonitor>
   </HealthMonitor>
           

   Zwróć uwagę, że konfiguracja monitorowania stanu zdrowia zawiera kod odpowiedzi 200 w elemencie <SuccessResponse>. Oznacza to, że jeśli Edge otrzyma z interfejsu API kontroli stanu kod odpowiedzi (np. 400, 401, 404, 500) inny niż 200, zostanie potraktowany jako błąd, co zwiększy liczbę niepowodzeń.

6. Aby zbadać przyczynę odpowiedzi błędu z interfejsu API kontroli stanu, wykonaj te czynności:
1. Spójrz na komunikat przed komunikatem ostrzegawczym w dzienniku procesora wiadomości.

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
             

   Zanotuj adres URL kontroli stanu podany w tym komunikacie.

2. Możesz zadzwonić bezpośrednio pod ten adres URL z procesora wiadomości i sprawdzić faktyczną odpowiedź

   curl -i https://mocktarget.apigee.net:443/status/200
             

   Odpowiedź z powyższego wywołania zwraca kod 404 taki jak w dziennikach procesora wiadomości:

   < HTTP/2 404
             

3. Oznacza to, że nawet bezpośrednie wywołanie URL-a kontroli stanu zakończy się niepowodzeniem z tym samym kodem odpowiedzi 404. Oznacza to, że URL kontroli stanu może być nieprawidłowy lub zasób, do którego dostęp jest uzyskiwany jako część tego adresu, nie jest już dostępny.
4. W podanym powyżej przykładowym interfejsie API kontroli stanu problem występuje, ponieważ w konfiguracji monitorowania stanu został użyty nieprawidłowy adres URL. Prawidłowy adres URL to https://mocktarget.apigee.net:443/statuscode/200 z Przykładowy docelowy interfejs API.
7. Jeśli pojawi się inny błąd, ustal przyczynę jego błędu, wykonując opisane powyżej. W razie potrzeby skontaktuj się z zespołem backendu.

Rozdzielczość

1. Rozwiąż problem z interfejsem API kontroli stanu na serwerze backendu.
2. Aby rozwiązać problem w omówionym powyżej przykładzie:
1. Zmodyfikuj element <Path> w konfiguracji Monitora zdrowia na /statuscode/200, jak pokazano poniżej:

   <Path>/statuscode/200</Path>
           

2. Zapisz zmiany na serwerze proxy interfejsu API.

Jeśli problem będzie nadal występował, wejdź na Wymagane jest zbieranie informacji diagnostycznych.

Diagnozowanie problemów za pomocą monitorowania interfejsów API

Monitorowanie interfejsów API umożliwia wyizolowanie problemów szybko diagnozować problemy z błędami, wydajnością i opóźnieniami oraz ich źródła, na przykład aplikacji, serwerów proxy API, celów backendu czy platformy API.

Przeanalizuj przykładowy scenariusz , który pokazuje, jak rozwiązywać problemy z kodem 5xx z interfejsami API przy użyciu monitorowania interfejsów API. Przykład: możesz skonfigurować alert, aby otrzymywać powiadomienia, gdy: messaging.adaptors.http.flow.NoActiveTargets przekracza określony próg.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zbierz: informacje diagnostyczne. Skontaktuj się z nimi i udostępnij je zespołowi pomocy Apigee:

1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
1. Nazwa organizacji
2. Nazwa środowiska
3. Nazwa serwera proxy interfejsu API
4. Wykonaj polecenie curl, aby odtworzyć błąd
5. Plik śledzenia zawierający żądania z błędem 503 Service Unavailable (usługa niedostępna z kodem błędu NoActiveTargets)
2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
   1. Zaobserwowano pełny komunikat o błędzie
   2. Nazwa środowiska
   3. Pakiet serwera proxy interfejsu API
   4. Plik śledzenia zawierający żądania z błędem 503 Service Unavailable (usługa niedostępna z kodem błędu NoActiveTargets)
   5. Logi dostępu NGINX

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

   6. Logi procesora wiadomości

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