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

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

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 Service Unavailable i kodem błędu NoActiveTargets w przypadku żądań serwera proxy interfejsu API.

Komunikat o błędzie

Pojawi się taki komunikat o błędzie:

HTTP/1.1 503 Service Unavailable
  

W odpowiedzi HTTP zobaczysz ten komunikat o błędzie:

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

Możliwe przyczyny

Odpowiedź HTTP 503 Service Unavailable z kodem błędu NoActiveTargets jest zwykle obserwowana, gdy w konfiguracji docelowego punktu końcowego w serwerze proxy interfejsu API używasz co najmniej 1 serwera docelowego.

Ten przewodnik obejmuje błąd 503 Service Unavailable z kodem błędu NoActiveTargets, który jest spowodowany niepowodzeniem kontroli stanu. Więcej informacji o innych przyczynach tego błędu znajdziesz w tym poradniku.

Nieudane kontrole stanu

Błędy kontroli stanu będą widoczne tylko wtedy, gdy w docelowym punkcie końcowym proxy interfejsu API skonfigurujesz monitor stanu w ramach konfiguracji równoważenia obciążenia serwera docelowego.

Gdy serwer docelowy nie przejdzie kontroli stanu, Edge zwiększa liczbę niepowodzeń tego serwera. Jeśli liczba nieudanych kontroli stanu na tym serwerze osiągnie wstępnie zdefiniowany próg (<MaxFailures>), procesor wiadomości zapisze w pliku dziennika komunikat ostrzegawczy, 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}
    

Wiadomość 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 proxy interfejsu API
• Nazwa docelowego punktu końcowego

Następnie Edge przestaje wysyłać do tego serwera kolejne żądania. Gdy wszystkie serwery docelowe skonfigurowane w konfiguracji LoadBalancer osiągną liczbę MaxFailure, kolejne żądania interfejsu API będą odpowiadać kodem 503 Service Unavailable z kodem błędu NoActiveTargets.

Korzystanie z monitora stanu pomaga Apigee Edge automatycznie włączać serwer docelowy z powrotem do rotacji, gdy odzyska on sprawność, bez konieczności ponownego wdrażania serwera proxy interfejsu API.

Oto możliwe przyczyny nieudanych kontroli stanu:

Typowe etapy diagnostyki

Określ identyfikator wiadomości, której żądanie się nie powiodło.

Częste komunikaty o błędach

Jeśli używane są serwery docelowe i wystąpi błąd podczas próby połączenia przez procesor komunikatów z serwerem backendu, w logach procesora komunikatów zobaczysz kilka typowych komunikatów o błędach. Te błędy są rejestrowane po rzeczywistym wyjątku lub komunikacie o błędzie, który spowodował niepowodzenie.

Typowe komunikaty o błędach obserwowane w dziennikach procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) w przypadku błędu 503 Service Unavailable 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 wskazują, że nie udało się wysłać żądania do serwera backendu z powodu awarii. W rezultacie procesor komunikatów wysyła do klienta odpowiedź 503 Service Unavailable z kodem błędu NoActiveTargets.

Przyczyna: upłynął limit czasu połączenia

Diagnostyka

1. Określ identyfikator wiadomości, której żądanie się nie powiodło.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Wyświetlą się typowe komunikaty o błędach odpowiadające identyfikatorowi wiadomości. Aby jednak poznać rzeczywistą przyczynę niepowodzeń kontroli stanu, przewiń w górę od tych typowych komunikatów o błędach i sprawdź, czy nie występują błędy MONITORA STANU.

   Na przykład ten komunikat o błędzie HEALTH MONITOR wskazuje, że procesor komunikatów nie działał z powodu błędu przekroczenia limitu czasu połączenia podczas wysyłania żądania do interfejsu API sprawdzania 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 powtórzy się MaxFailure razy (liczba skonfigurowana w monitorze stanu), zobaczysz taki komunikat ostrzegawczy:

   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 w komunikacie z ostrzeżeniem. Sprawdź, czy w przypadku serwera docelowego używanego w konkretnym serwerze proxy interfejsu API, w którym występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, osiągnięto wartość MaxFailure.

4. W powyższym przykładzie kontrola stanu zakończyła się niepowodzeniem z błędem 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 uda Ci się połączyć z serwerem backendu, zobaczysz komunikat podobny do tego: Połączono z serwerem backendu. W takim przypadku problem może być tymczasowy i zostać rozwiązany lub może występować okresowo. Powtórz krok 4 kilka razy (ponad 10 razy) i sprawdź dane wyjściowe.
1. Jeśli polecenie telnet nie powoduje błędów, problem został rozwiązany. Sprawdź ponownie, czy błędy kontroli stanu przestały występować. Jeśli tak, nie musisz nic więcej robić.
2. Jeśli nie możesz połączyć się z serwerem backendu za pomocą polecenia telnet, może to oznaczać problem z siecią lub przeciążenie serwera backendu.
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 tym serwerze jest niedozwolony.

Rozdzielczość

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

Jeśli problem nadal występuje, skontaktuj się z administratorem sieci, aby go zdiagnozować i rozwiązać. Jeśli potrzebujesz dalszej pomocy ze strony Apigee, skontaktuj się z zespołem pomocy Apigee.

Przyczyna: bezpieczne żądanie na niezabezpieczonym porcie

Diagnostyka

1. Określ identyfikator wiadomości, której żądanie się nie powiodło.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Wyświetlą się typowe komunikaty o błędach odpowiadające identyfikatorowi komunikatu. Aby jednak poznać rzeczywistą przyczynę niepowodzeń kontroli stanu, przewiń w górę od tych typowych komunikatów o błędach i sprawdź, czy nie występują błędy MONITORA STANU.

   Możesz na przykład zobaczyć błąd HEALTH MONITOR, jak pokazano 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 powtórzy się MaxFailure razy (liczba skonfigurowana w monitorze stanu), zobaczysz taki komunikat ostrzegawczy:

   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 w komunikacie z ostrzeżeniem. Sprawdź, czy w przypadku serwera docelowego używanego w konkretnym serwerze proxy interfejsu API, w którym występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, osiągnięto wartość MaxFailure.

4. Kontrola stanu zakończyła się niepowodzeniem z 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 adres URL wskazują, że przyczyną problemu jest bezpieczne wywołanie (HTTPS) na niezabezpieczonym porcie 80.

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

   • Zdefiniowano bezpieczny serwer docelowy z niezabezpieczonym portem
   • Zdefiniowano bezpieczny serwer docelowy, ale monitor stanu jest skonfigurowany z niezabezpieczonym portem

   Bezpieczny port docelowy niebezpiecznego portu

   Scenariusz 1. Zdefiniowano bezpieczny serwer docelowy z niezabezpieczonym portem

   Jeśli zdefiniowano bezpieczny serwer docelowy, ale z niezabezpieczonym portem, np. 80, pojawi się ten błąd. Aby sprawdzić, czy to jest przyczyną problemu, wykonaj te czynności:

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

   Użyj interfejsu Get TargetServer API, aby pobrać 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 przykładzie powyżej definicja pokazuje, że serwer docelowy mocktarget jest serwerem bezpiecznym, co wskazuje blok SSLInfo. Jest on jednak skonfigurowany z niezabezpieczonym portem 80.

   2. Teraz sprawdź konfigurację monitora stanu serwera docelowego w konfiguracji 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 konfiguracji monitora stanu powyżej nie ma elementu <Port>. W tym przypadku procesor komunikatów Edge używa portu określonego w definicji serwera docelowego (czyli 80) do wywoływania interfejsu API kontroli stanu.

   3. Z powyższych informacji wynika, że przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako serwer bezpieczny (blok SSLInfo jest włączony), ale używa niezabezpieczonego portu 80.

   Bezpieczny port HM docelowego miejsca docelowego

   Scenariusz 2. Zdefiniowano bezpieczny serwer docelowy, ale monitor stanu jest skonfigurowany z niezabezpieczonym portem

   Ten błąd występuje, jeśli zdefiniowano bezpieczny serwer docelowy, ale monitor stanu jest skonfigurowany z użyciem portu niezabezpieczonego, np. 80. Aby sprawdzić, czy to jest przyczyną problemu, wykonaj te czynności:

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

      Aby pobrać definicję serwera docelowego, użyj interfejsu Get TargetServer API.

      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 przykładzie powyżej definicja pokazuje, że serwer docelowy mocktarget jest serwerem bezpiecznym, co wskazuje blok SSLInfo.

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

      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 przykładzie powyżej monitor stanu jest skonfigurowany z niezabezpieczonym portem 80, co wskazuje element <Port>.

   3. Z powyższych informacji wynika, że przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako serwer bezpieczny (blok SSLInfo jest włączony) i używa bezpiecznego portu 443, ale monitor stanu jest skonfigurowany do przeprowadzania kontroli stanu za pomocą niezabezpieczonego portu 80 (określonego w elemencie <Port>).

      W tym przypadku Edge wykonuje wywołania interfejsów API kontroli stanu jako bezpieczne wywołania z niezabezpieczonym portem 80 i zwraca wspomniany powyżej błąd.

Rozdzielczość

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

Przyczyna: niezabezpieczone żądanie na zabezpieczonym porcie

Diagnostyka

1. Określ identyfikator wiadomości, której żądanie się nie powiodło.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Wyświetlą się typowe komunikaty o błędach odpowiadające identyfikatorowi wiadomości. Aby jednak poznać rzeczywistą przyczynę niepowodzeń kontroli stanu, przewiń w górę od tych typowych komunikatów o błędach i sprawdź, czy nie występują błędy MONITORA STANU.

   Możesz na przykład zobaczyć błąd HEALTH MONITOR, jak pokazano 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 powtórzy się MaxFailure razy (liczba skonfigurowana w monitorze stanu), zobaczysz taki komunikat ostrzegawczy:

   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 w komunikacie z ostrzeżeniem. Sprawdź, czy w przypadku serwera docelowego używanego w konkretnym serwerze proxy interfejsu API, w którym występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, osiągnięto wartość MaxFailure.

4. Kontrola stanu zakończyła się niepowodzeniem z 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 adres URL wskazują, że przyczyną problemu jest niezabezpieczone wywołanie (HTTP) na zabezpieczonym porcie 443.

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

   • Niezabezpieczony serwer docelowy z zabezpieczonym portem
   • Zdefiniowano niezabezpieczony serwer docelowy, ale monitor stanu jest skonfigurowany z zabezpieczonym portem

   Niezabezpieczony port docelowy

   Scenariusz 1. Niezabezpieczony serwer docelowy z zabezpieczonym portem

   Ten błąd występuje, jeśli zdefiniowano docelowy serwer bez zabezpieczeń, ale z bezpiecznym portem, np. 443. Aby sprawdzić, czy to jest przyczyną problemu, wykonaj te czynności:

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

      Aby pobrać definicję serwera docelowego, użyj interfejsu Get TargetServer API.

      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 pokazuje, że serwer docelowy mocktarget jest serwerem niezabezpieczonym, ponieważ nie ma bloku SSLInfo. Jest on jednak nieprawidłowo skonfigurowany z bezpiecznym portem 443.

   2. Teraz sprawdź konfigurację monitora stanu serwera docelowego w konfiguracji 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 konfiguracji monitora stanu powyżej nie ma elementu <Port>. W tym przypadku procesor komunikatów Edge użyje portu określonego w definicji serwera docelowego, czyli 443.

   3. Z powyższych informacji wynika, że przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako serwer niezabezpieczony (ponieważ blok SSLInfo nie jest zdefiniowany), ale z bezpiecznym portem 443.

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

   Niezabezpieczony port hostowanego wpisu docelowego

   Scenariusz 2. Zdefiniowano niezabezpieczony serwer docelowy, ale monitor stanu jest skonfigurowany z zabezpieczonym portem

   Ten błąd występuje, jeśli zdefiniowano niezabezpieczony serwer docelowy, ale monitor stanu jest skonfigurowany z zabezpieczonym portem, np. 443. Aby sprawdzić, czy to jest przyczyną problemu, wykonaj te czynności:

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

      Aby pobrać definicję serwera docelowego, użyj interfejsu Get TargetServer API.

      Dane wyjściowe definicji serwera docelowego

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

      W przykładzie powyżej definicja pokazuje, że serwer docelowy mocktarget jest serwerem niezabezpieczonym (ponieważ nie ma bloku SSLInfo) skonfigurowanym z niezabezpieczonym portem 80 prawidłowo.

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

      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. Z powyższych informacji wynika, że przyczyną tego błędu jest to, że serwer docelowy jest zdefiniowany jako niezabezpieczony serwer (ponieważ blok SSLInfo nie jest zdefiniowany) z niezabezpieczonym portem 80, ale monitor stanu jest skonfigurowany do przeprowadzania testów stanu za pomocą zabezpieczonego portu 443 (określonego w elemencie <Port>).

      Oznacza to, że w tym przypadku Edge wykonuje kontrole stanu jako połączenie niezabezpieczone z zabezpieczonym portem 443 i kończy się niepowodzeniem z wyżej wymienionym błędem.

Rozdzielczość

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

Przyczyna: interfejs Health Check API zwraca błąd

Diagnostyka

1. Określ identyfikator wiadomości, której żądanie się nie powiodło.
2. Wyszukaj identyfikator wiadomości w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Wyświetlą się typowe komunikaty o błędach odpowiadające identyfikatorowi komunikatu. Aby jednak poznać rzeczywistą przyczynę niepowodzeń kontroli stanu, przewiń w górę od tych typowych komunikatów o błędach i sprawdź, czy nie ma błędów lub ostrzeżeń dotyczących monitora stanu.

   Może na przykład pojawić się ostrzeżenie MONITOR ZDROWIA, jak pokazano 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ę MaxFailure razy (liczba skonfigurowana w monitorze stanu), zobaczysz taki komunikat ostrzegawczy:

   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 w komunikacie z ostrzeżeniem. Sprawdź, czy w przypadku serwera docelowego używanego w konkretnym serwerze proxy interfejsu API, w którym występuje kod odpowiedzi 503 z kodem błędu NoActiveTargets, osiągnięto wartość 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 sprawdzania stanu to 200, ale rzeczywista odpowiedź to 404. Dlatego jest to traktowane jako niepowodzenie.

5. Zanim zaczniesz szukać przyczyny błędu w odpowiedzi z interfejsu Health Check API, ustal, dlaczego Edge oczekuje kodu odpowiedzi 200 w przypadku tego interfejsu. W tym celu sprawdź konfigurację monitora stanu w konfiguracji docelowego punktu końcowego serwera docelowego:

   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 z kodem odpowiedzi 200 w elemencie <SuccessResponse>. Oznacza to, że jeśli Edge otrzyma z interfejsu API kontroli stanu kod odpowiedzi inny niż 200 (np. 400, 401, 404, 500), zostanie on potraktowany jako błąd i zwiększy liczbę niepowodzeń.

6. Aby zbadać przyczynę odpowiedzi o błędzie z interfejsu API kontroli stanu, wykonaj te czynności:
1. Sprawdź wiadomość poprzedzającą komunikat ostrzegawczy w logu 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 komunikatów i sprawdzić rzeczywistą odpowiedź.

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

   Odpowiedź z powyższego wywołania zawiera kod 404, co widać w dziennikach procesora komunikatów:

   < HTTP/2 404
             

3. Pokazuje to, że nawet bezpośrednie wywołanie adresu URL sprawdzania stanu kończy się niepowodzeniem z tym samym kodem odpowiedzi 404. Oznacza to, że adres URL kontroli stanu może być nieprawidłowy lub zasób, do którego uzyskuje się dostęp w ramach adresu URL, jest już niedostępny.
4. W podanym powyżej przykładzie interfejsu API kontroli stanu problem występuje, ponieważ w konfiguracji monitora stanu użyto nieprawidłowego adresu URL. Prawidłowy adres URL to https://mocktarget.apigee.net:443/statuscode/200 z Mock Target API.
7. Jeśli otrzymasz inną odpowiedź o błędzie, ustal jej przyczynę, wykonując powyższe czynności. W razie potrzeby skontaktuj się z zespołem ds. 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 stanu na /statuscode/200, jak pokazano poniżej:

   <Path>/statuscode/200</Path>
           

2. Zapisz zmiany w proxy interfejsu API.

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

Diagnozowanie problemów za pomocą monitorowania interfejsu API

Monitorowanie interfejsu API umożliwia szybkie odizolowanie obszarów, w których występują problemy, aby zdiagnozować błędy, problemy z wydajnością i czasem oczekiwania oraz ich źródło, np. aplikacje deweloperów, serwery proxy interfejsów API, docelowe systemy backendu lub platformę interfejsu API.

Przejdź przykładowy scenariusz, który pokazuje, jak rozwiązywać problemy z kodami 5xx w interfejsach API za pomocą usługi API Monitoring. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba messaging.adaptors.http.flow.NoActiveTargets błędów przekroczy określony próg.

musi zbierać informacje diagnostyczne;

Jeśli problem nadal występuje nawet po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne: Skontaktuj się z zespołem pomocy Apigee i udostępnij mu te informacje:

1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
1. Nazwa organizacji
2. Nazwa środowiska
3. Nazwa proxy interfejsu API
4. Pełne polecenie curl do odtworzenia błędu
5. Plik śledzenia zawierający żądania z błędem 503 Usługa niedostępna i kodem błędu NoActiveTargets.
2. Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:
   1. Pełny komunikat o błędzie
   2. Nazwa środowiska
   3. Pakiet proxy interfejsu API
   4. Plik śledzenia zawierający żądania z błędem 503 Usługa niedostępna i kodem błędu NoActiveTargets.
   5. Logi dostępu NGINX

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

   6. Dzienniki procesora komunikatów

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