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

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

Filmy

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu odpowiedzi HTTP 503 z komunikatem Usługa niedostępna i kodem błędu NoActiveTarget dla żądań serwera proxy interfejsu API.

Komunikat o błędzie

Zobaczysz taką odpowiedź o błędzie:

HTTP/1.1 503 Service Unavailable
  

W odpowiedzi HTTP pojawi się ten komunikat o błędzie:

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

Możliwe przyczyny

Gdy używasz co najmniej jednego serwera docelowego w konfiguracji docelowego punktu końcowego w serwerze proxy interfejsu API, zwykle obserwowany jest komunikat HTTP 503 Service AVAILABLE (Usługa niedostępna) z kodem błędu NoActiveTarget (Nieaktywnych celów).

Ten scenariusz zawiera informacje na temat błędu 503 Service available (Usługa niedostępna) z kodem błędu NoActiveTarget, który jest przyczyną błędów kontroli stanu. Zapoznaj się z tym poradnikiem, aby poznać inne przyczyny tego błędu.

Niepowodzenie kontroli stanu

Błędy kontroli stanu będą obserwowane tylko wtedy, gdy skonfigurujesz Monitor 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 błędów kontroli stanu serwera osiągnie wstępnie zdefiniowany próg (<MaxFailures>), procesor wiadomości zapisze w swoim pliku dziennika komunikat z ostrzeżeniem, jak pokazano poniżej:

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 te informacje. Dzięki temu dowiesz się, który serwer docelowy osiągnął liczbę MaxFailure:

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

Następnie Edge przestaje wysyłać kolejne żądania do tego serwera. Gdy wszystkie serwery docelowe skonfigurowane w konfiguracji LoadBalancer osiągną liczbę MaxFailure, kolejne żądania do interfejsu API są wysyłane w odpowiedzi na 503 Service Niedostępne z kodem błędu NoActiveTarget.

Korzystanie z Monitora stanu ułatwia Apigee Edge automatyczne uwzględnianie serwera docelowego z powrotem w rotacji, gdy stanie się sprawne, bez konieczności ponownego wdrażania serwera proxy interfejsu API.

Oto możliwe przyczyny niepowodzeń kontroli stanu:

Najczęstsze kroki diagnostyki

Określ identyfikator wiadomości nieudanego żądania

Częste komunikaty o błędach

Jeśli przy korzystaniu z serwerów docelowych wystąpi błąd, gdy procesor wiadomości próbuje połączyć się z serwerem backendu, w logach tego procesora pojawi się kilka typowych komunikatów o błędach. Te błędy są rejestrowane po rzeczywistym wystąpieniu wyjątku/błędu, który doprowadził do niepowodzenia.

Typowe komunikaty o błędach, które pojawiają się w logach procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log) dotyczące komunikatu 503 Service Niedostępne z kodem błędu NoActiveTarget, to:

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 z powodu błędu nie udało się wysłać żądania do serwera backendu. W rezultacie podmiot przetwarzający wiadomości wysyła w odpowiedzi klienta komunikat 503 Service available (Niedostępna usługa 503) z kodem błędu NoActiveTarget.

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 powiązane z identyfikatorem wiadomości. Aby jednak poznać faktyczną przyczynę niepowodzeń kontroli stanu, przewiń stronę nad tymi typowymi komunikatami o błędach i sprawdź, czy nie występują błędy MONITORA STANU.

   Na przykład ten komunikat o błędzie MONITOR HEALTH MONITOR wskazuje, że podczas wysyłania żądania do interfejsu API kontroli stanu wystąpił błąd związany z przekroczeniem limitu czasu połączenia przez procesor wiadomości:

   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 Monitorze stanu, zobaczysz komunikat ostrzegawczy podobny 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 zawarte w komunikacie ostrzegawczym. Sprawdź, czy dla serwera docelowego używanego w określonym serwerze proxy interfejsu API, dla którego występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, został osiągnięty limit MaxFailure.

4. W powyższym przykładzie kontrola stanu nie powiodła się i wystąpił błąd connection timed out. Sprawdź, czy możesz połączyć się z określonym serwerem backendu bezpośrednio z każdego procesora wiadomości za pomocą polecenia telnet:

telnet <BackendServer-HostName> 443
      

5. Jeśli możesz nawiązać połączenie z serwerem backendu, może wyświetlić się komunikat Połączono z serwerem backendu. Jeśli tak, może to być problem tymczasowy, który został już rozwiązany lub występuje przejściowy. Powtórz krok 4 kilka razy (ponad 10 razy) i sprawdź wynik.
1. Jeśli konsekwentnie nie występują błędy w poleceniu telnet, problem został rozwiązany. Sprawdź, czy błędy kontroli stanu ustały. Jeśli tak, nie musisz robić nic więcej.
2. Jeśli nie możesz połączyć się z serwerem backendu sporadycznie przy użyciu polecenia telnet, może to oznaczać problem z siecią lub serwer backendu może być zajęty.
6. Jeśli nie możesz połączyć się z serwerem backendu spójnie za pomocą polecenia telnet, może to być spowodowane tym, że ruch generowany przez procesory wiadomości nie jest dozwolony na danym serwerze backendu.

Rozdzielczość

Jeśli błąd connection timed out jest stale obserwowany, sprawdź, czy na serwerze backendu nie ma żadnych ograniczeń zapory sieciowej i że zezwala na ruch z procesorów wiadomości Apigee Edge. Na przykład w systemie Linux możesz użyć polecenia iptables, aby zezwolić na ruch z adresów IP procesora wiadomości na serwerze backendu.

Jeśli problem nie ustąpi, skontaktuj się z administratorem sieci, aby go rozwiązać i rozwiązać. Jeśli potrzebujesz dodatkowej pomocy dotyczącej 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 powiązane z identyfikatorem wiadomości. Aby jednak poznać faktyczną przyczynę niepowodzeń kontroli stanu, przewiń stronę nad tymi typowymi komunikatami o błędach i sprawdź, czy nie występują błędy MONITORA STANU.

   Możesz na przykład zobaczyć błąd MONITOR ZDROWIA jak poniżej:

   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 powtarza się MaxFailure razy skonfigurowanych w Monitorze stanu, zobaczysz komunikat ostrzegawczy podobny 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 zawarte w komunikacie ostrzegawczym. Sprawdź, czy dla serwera docelowego używanego w określonym serwerze proxy interfejsu API, dla którego występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, został osiągnięty limit MaxFailure.

4. Kontrola stanu nie powiodła się. Wystąpił błąd:

   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ą, że przyczyną tego problemu jest bezpieczne wywołanie (HTTPS) wysłane na niezabezpieczonej porcie 80.

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

   • Bezpieczny serwer docelowy zdefiniowany z niezabezpieczonym portem
   • Zdefiniowano bezpieczny serwer docelowy, ale monitor stanu został skonfigurowany z niezabezpieczonym portem

   Bezpieczny niezabezpieczony port docelowy

   Scenariusz 1. Bezpieczny serwer docelowy został zdefiniowany z niezabezpieczonym portem

   Ten błąd występuje, jeśli masz zdefiniowany bezpieczny serwer docelowy, ale z niezabezpieczonym portem, np. 80. Wykonaj te czynności, by sprawdzić, czy jest ono przyczyną problemu:

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

   Użyj interfejsu Get TargetServer API, by 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 serwerem bezpiecznym, co wskazuje blok SSLInfo. Jest on jednak skonfigurowany na niezabezpieczonym porcie 80.

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

      Konfiguracja monitora stanu

      <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 powyższej konfiguracji monitorowania stanu nie określono elementu <Port>. W tym przypadku procesor wiadomości w Edge używa portu określonego w definicji serwera docelowego (czyli 80) do wykonywania wywołań interfejsu API kontroli stanu.

   3. Na podstawie powyższych informacji przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako bezpieczny (gdy blok SSLInfo jest włączony), ale z niezabezpieczonym portem 80.

   Bezpieczny docelowy niezabezpieczony port HM

   Scenariusz 2. Zdefiniowano bezpieczny serwer docelowy, ale usługa Monitor stanu została skonfigurowana z niezabezpieczonem portem

   Ten błąd występuje, jeśli masz bezpieczny serwer docelowy, ale monitor stanu jest skonfigurowany z niezabezpieczonym portem, np. 80. Wykonaj te czynności, aby sprawdzić, czy to jest przyczyną problemu:

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

      Użyj interfejsu Get TargetServer API, by 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, co wskazuje blok SSLInfo.

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

      Konfiguracja monitora stanu

      <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 jest skonfigurowany z niezabezpieczonym portem 80, co wskazuje element <Port>.

   3. Na podstawie powyższych informacji przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako bezpieczny serwer (gdy blok SSLInfo jest włączony) i używa bezpiecznego portu 443, ale monitor stanu jest skonfigurowany do wykonywania kontroli stanu z niezabezpieczonym portem 80 (określonym w elemencie <Port>).

      Oznacza to, że w tym przypadku Edge używa interfejsów API kontroli stanu jako bezpieczne wywołanie z niezabezpieczonym portem 80, co kończy się niepowodzeniem z powodu wspomnianego powyżej 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 przez zabezpieczony port

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 powiązane z identyfikatorem wiadomości. Aby jednak poznać faktyczną przyczynę niepowodzeń kontroli stanu, przewiń stronę nad tymi typowymi komunikatami o błędach i sprawdź, czy nie występują błędy MONITORA STANU.

   Możesz na przykład zobaczyć błąd MONITOR ZDROWIA jak poniżej:

   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 powtarza się MaxFailure razy skonfigurowanych w Monitorze stanu, zobaczysz komunikat ostrzegawczy podobny 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 zawarte w komunikacie ostrzegawczym. Sprawdź, czy dla serwera docelowego używanego w określonym serwerze proxy interfejsu API, dla którego występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, został osiągnięty limit MaxFailure.

4. Kontrola stanu nie powiodła się. Wystąpił błąd:

   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 adres URL wskazują, że przyczyną tego problemu jest niezabezpieczone wywołanie (HTTP) na bezpiecznym porcie 443.

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

   • Niezabezpieczony serwer docelowy zdefiniowany z użyciem bezpiecznego portu
   • Zdefiniowano niezabezpieczone serwer docelowy, ale usługa monitor stanu została skonfigurowana z użyciem bezpiecznego portu

   Niezabezpieczony bezpieczny port docelowy

   Scenariusz 1. Niezabezpieczony serwer docelowy zdefiniowany z wykorzystaniem bezpiecznego portu

   Ten błąd występuje, jeśli masz zdefiniowany niezabezpieczony serwer docelowy z zabezpieczonym portem, np. 443. Wykonaj te czynności, by sprawdzić, czy jest ono przyczyną problemu:

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

      Użyj interfejsu Get TargetServer API, by 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 serwerem niezabezpieczonym, ponieważ nie ma blokady SSLInfo. Jest jednak nieprawidłowo skonfigurowana przy użyciu bezpiecznego portu 443.

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

      Konfiguracja monitora stanu

      <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 powyższej konfiguracji Monitora stanu nie określono elementu <Port>. W tym przypadku procesor wiadomości serwera Edge użyje portu określonego w definicji serwera docelowego, czyli 443.

   3. Na podstawie powyższych informacji przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako serwer niezabezpieczony (nie zdefiniowano bloku SSLInfo), ale z zabezpieczonym portem 443.

      Oznacza to, że Edge powoduje, że kontrole stanu są niezabezpieczone, korzystając z bezpiecznego portu 443, i kończy się niepowodzeniem z powodu wspomnianego powyżej błędu.

   Niezabezpieczony docelowy bezpieczny port HM

   Scenariusz 2. Zdefiniowano niezabezpieczone serwer docelowy, ale funkcja monitorowania stanu została skonfigurowana z użyciem bezpiecznego portu

   Ten błąd występuje, jeśli masz zdefiniowany niezabezpieczony serwer docelowy, ale monitor stanu jest skonfigurowany z bezpiecznym portem, np. 443. Wykonaj te czynności, by sprawdzić, czy jest ono przyczyną problemu:

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

      Użyj interfejsu Get TargetServer API, by 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 serwerem niezabezpieczonym (ponieważ nie ma bloku SSLInfo) skonfigurowanym prawidłowo z niezabezpieczonym portem 80.

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

      Konfiguracja monitora stanu

      <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 jest skonfigurowany z bezpiecznym portem 443, co wskazuje element <Port>.

   3. Na podstawie powyższych informacji przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako serwer niezabezpieczony (bo blok SSLInfo nie jest zdefiniowany) z poprawnie niezabezpieczonym portem 80, ale monitor stanu jest skonfigurowany do wykonywania kontroli stanu przy użyciu bezpiecznego portu 443 (określonego w elemencie <Port>).

      Oznacza to, że w tym przypadku Edge przeprowadza kontrole stanu jako niezabezpieczone połączenie przez bezpieczny port 443, co 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 Health Check API zwraca komunikat o błędzie

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 powiązane z identyfikatorem wiadomości. Aby jednak poznać faktyczną przyczynę niepowodzeń kontroli stanu, przewiń stronę nad tymi typowymi komunikatami o błędach i sprawdź, czy nie ma żadnych błędów lub ostrzeżeń dotyczących MONITORA STANU.

   Możesz na przykład zobaczyć ostrzeżenie MONITOR ZDROWIA jak 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 powtarza się MaxFailure razy skonfigurowanych w Monitorze stanu, zobaczysz komunikat ostrzegawczy podobny 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 zawarte w komunikacie ostrzegawczym. Sprawdź, czy dla serwera docelowego używanego w określonym serwerze proxy interfejsu API, dla którego występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, został osiągnięty limit MaxFailure.

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 informuje, że oczekiwany kod odpowiedzi interfejsu API kontroli stanu to 200, ale rzeczywista odpowiedź to 404. Z tego powodu jest to traktowane jako błąd.

5. Zanim sprawdzisz przyczynę błędu z interfejsu API kontroli stanu, ustal, dlaczego Edge oczekuje kodu odpowiedzi 200 dla interfejsu API kontroli stanu. W tym celu sprawdź konfigurację Monitora stanu dla serwera docelowego w konfiguracji docelowego punktu końcowego:

   Konfiguracja monitora stanu

   <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 Monitora stanu jest skonfigurowana za pomocą kodu odpowiedzi 200 w elemencie <SuccessResponse>. Oznacza to, że jeśli Edge otrzyma z interfejsu API kontroli stanu dowolny kod odpowiedzi (na przykład 400, 401, 404, 500) inny niż 200, zostanie potraktowany jako błąd i zwiększy liczbę błędów.

6. Teraz, aby zbadać przyczynę błędu odpowiedzi interfejsu API kontroli stanu, wykonaj te czynności:
1. Zapoznaj się z komunikatem poprzedzającym ostrzeżenie 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 z tej wiadomości.

2. Możesz wykonać bezpośrednie wywołanie tego adresu URL z procesora wiadomości i sprawdzić faktyczną odpowiedź

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

   W odpowiedzi z powyższego połączenia występuje błąd 404, który widać w dziennikach procesora wiadomości:

   < HTTP/2 404
             

3. Oznacza to, że nawet bezpośrednie wywołanie adresu URL kontroli stanu koń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 uzyskuje się dostęp w ramach adresu URL, nie jest już dostępny.
4. W powyższym przykładowym interfejsie API kontroli stanu problem występuje, ponieważ w konfiguracji monitora stanu użyto nieprawidłowego adresu URL. Stwierdziliśmy, że prawidłowy adres URL to https://mocktarget.apigee.net:443/statuscode/200 w interfejsie Mock Target API.
7. Jeśli pojawi się inny komunikat o błędzie, ustal jego przyczynę, wykonując czynności 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 przykładzie omówionym powyżej:
1. Zmień element <Path> w konfiguracji Monitora stanu na /statuscode/200, jak pokazano poniżej:

   <Path>/statuscode/200</Path>
           

2. Zapisz zmiany w API Proxy.

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

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

Monitorowanie interfejsów API umożliwia szybkie wyodrębnianie problematycznych obszarów w celu diagnozowania problemów dotyczących błędów, wydajności i opóźnień oraz ich źródeł, takich jak aplikacje dla programistów, serwery proxy interfejsów API, cele backendu czy platforma API.

Przejrzyj przykładowy scenariusz pokazujący, jak rozwiązywać problemy 5xx z interfejsami API za pomocą API Monitoring. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba błędów w messaging.adaptors.http.flow.NoActiveTargets przekroczy określony próg.

Musisz zebrać informacje diagnostyczne

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee i udostępnij je:

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 kodem 503 Service Niedostępne z kodem błędu NoActiveTarget
2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
   1. Zarejestrowano pełny komunikat o błędzie
   2. Nazwa środowiska
   3. Pakiet proxy API
   4. Plik śledzenia zawierający żądania z kodem 503 Service Niedostępne z kodem błędu NoActiveTarget
   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)