Równoważenie obciążenia na serwerach backendu

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

Apigee Edge zwiększa dostępność interfejsu API, zapewniając wbudowaną obsługę równoważenia obciążenia i przełączania awaryjnego w wielu instancjach serwerów backendu.

Konfiguracje serwera docelowego oddzielają konkretne adresy URL punktów końcowych od konfiguracji docelowych punktów końcowych. Do każdego serwera docelowego odwołuje się nazwa w połączeniu HTTPEndpoint. Zamiast definiować w konfiguracji konkretny adres URL, możesz skonfigurować co najmniej 1 serwer docelowy o nazwie zgodnie z opisem w sekcji TargetEndpoint.

Definicja serwera docelowego składa się z nazwy, hosta i portu oraz dodatkowego elementu wskazującego, czy serwer docelowy jest włączony czy wyłączony.

Filmy

Obejrzyj te filmy, aby dowiedzieć się więcej o routingu i równoważeniu obciążenia interfejsów API za pomocą serwerów docelowych

Wideo	Opis
Równoważenie obciążenia za pomocą serwerów docelowych	Interfejsy API równoważenia obciążenia na serwerach docelowych.
Routing interfejsów API oparty na środowisku z użyciem serwerów docelowych	Przekierowanie interfejsu API do innego serwera docelowego w zależności od środowiska.
Routing i równoważenie obciążenia interfejsów API przy użyciu serwerów docelowych (klasyczna wersja Edge)	Kieruj interfejs API na inny serwer docelowy na podstawie środowiska i równoważenia obciążenia interfejsu API między serwerami docelowymi w klasycznym interfejsie użytkownika Edge.

Przykładowa konfiguracja serwera docelowego

Ten kod określa serwer docelowy:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Elementy konfiguracji serwera docelowego

Tabela poniżej zawiera opis elementów używanych do tworzenia i konfigurowania serwera docelowego:

Nazwa	Opis	Domyślnie	Wymagana?
name	Nazwa konfiguracji serwera docelowego, która musi być unikalna w obrębie środowiska. Nazwa serwera docelowego może zawierać tylko znaki alfanumeryczne.	Nie dotyczy	Tak
Host	Adres URL hosta usługi backendu (bez protokołu).	Nie dotyczy	Tak
Port	Port, na którym nasłuchuje usługa backendu	Nie dotyczy	Tak
IsEnabled	Wartość logiczna wskazująca, czy konfiguracja serwera docelowego jest włączona czy wyłączona. Pozwala to wyeliminować serwery docelowe z rotacji bez modyfikowania konfiguracji serwera proxy interfejsu API. Typowym zastosowaniem jest napisanie aplikacji lub skryptu, który będzie automatycznie włączać lub wyłączać serwery docelowe na podstawie oczekiwanych wymagań dotyczących pojemności, harmonogramów konserwacji itp.	true	Tak

Zarządzanie serwerami docelowymi za pomocą interfejsu użytkownika

Zarządzaj serwerami docelowymi w sposób opisany poniżej.

Zarządzanie serwerami docelowymi przy użyciu interfejsu API

Przy użyciu interfejsu Edge API możesz tworzyć, usuwać, aktualizować, pobierać i wyświetlać serwery docelowe. Więcej informacji znajdziesz w artykule TargetServers.

Aby utworzyć serwer docelowy, użyj tego wywołania interfejsu API:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Przykładowa odpowiedź:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Po utworzeniu pierwszego serwera docelowego użyj poniższego wywołania interfejsu API, aby utworzyć drugi serwer docelowy. Definiując 2 serwery docelowe, udostępniasz dwa adresy URL, których punkt końcowy może używać do równoważenia obciążenia:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Przykładowa odpowiedź:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Aby pobrać listę serwerów docelowych w środowisku, użyj tego wywołania interfejsu API:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Przykładowa odpowiedź:

[ "target2", "target1" ]

Obecnie dostępne są 2 serwery docelowe do użycia przez serwery proxy interfejsu API wdrożone w środowisku testowym. Aby równoważyć obciążenie ruchu między tymi serwerami docelowymi, musisz skonfigurować połączenie HTTP w docelowym punkcie końcowym serwera proxy interfejsu API tak, aby używało serwerów docelowych.

Obowiązuje limit 500 serwerów docelowych na środowisko, zgodnie z opisem w temacie Limity.

Konfigurowanie punktu końcowego w celu równoważenia obciążenia między nazwanymi serwerami docelowymi

Mając już dostępne 2 serwery docelowe, możesz zmienić ustawienie połączenia HTTP docelowego punktu końcowego, aby odwoływało się do nich za pomocą nazwy:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Powyższa konfiguracja to najbardziej podstawowa konfiguracja równoważenia obciążenia. System równoważenia obciążenia obsługuje 3 algorytmy równoważenia obciążenia: Round Robin, Ważone i najmniejsze połączenie. Algorytm karuzelowy to domyślny algorytm. Ponieważ w powyższej konfiguracji nie określono żadnego algorytmu, żądania wychodzące z serwera proxy interfejsu API do serwerów backendu będą naprzemienne, po jednym dla jednego celu, w obszarze docelowym 1 i docelowym 2.

Element <Path> tworzy ścieżkę bazową identyfikatora URI elementu TargetEndpoint dla wszystkich serwerów docelowych. Jest używana tylko wtedy, gdy używana jest zasada <LoadBalancer>. W przeciwnym razie jest ignorowana. W tym przykładzie żądanie docierające do wartości „target1” będzie mieć wartość http://target1/test itd. w przypadku innych serwerów docelowych.

Ustawianie opcji systemu równoważenia obciążenia

Dostępność możesz dostosować za pomocą opcji równoważenia obciążenia i przełączania awaryjnego na poziomie systemu równoważenia obciążenia i serwera docelowego. W tej sekcji opisujemy te opcje.

Algorytm

Ustawia algorytm używany przez funkcję <LoadBalancer>. Dostępne algorytmy to RoundRobin, Weighted i LeastConnections. Poniżej znajdziesz ich opis.

Algorytm karuzelowy

Domyślny algorytm (round robin) przekazuje żądanie do każdego serwera docelowego w kolejności, w której serwery są wymienione w połączeniu HTTP docelowego punktu końcowego. Na przykład:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Ważona

Algorytm równoważenia obciążenia ważonego umożliwia skonfigurowanie proporcjonalnego obciążenia ruchu dla serwerów docelowych. Ważony system LoadBalancer rozdziela żądania do serwerów docelowych w bezpośredniej proporcji do wagi każdego serwera docelowego. Dlatego algorytm ważony wymaga ustawienia atrybutu weight dla każdego serwera docelowego. Na przykład:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

W tym przykładzie każde skierowane do elementu target1 każde żądanie będzie przekierowywane do 2 żądań.

Najmniejsze połączenie

Moduły równoważenia obciążenia skonfigurowane pod kątem użycia algorytmu jak najmniejszego połączenia kierują żądania wychodzące do serwera docelowego z najmniejszą liczbą otwartych połączeń HTTP. Na przykład:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Maksymalna liczba niepowodzeń

Maksymalna liczba nieudanych żądań z serwera proxy interfejsu API do serwera docelowego, które skutkują przekierowaniem żądania do innego serwera docelowego.

Błąd odpowiedzi oznacza, że Apigee nie otrzymuje żadnej odpowiedzi z serwera docelowego. W takim przypadku licznik błędów zwiększa się o jeden.

Jeśli jednak Apigee otrzyma odpowiedź z celu, nawet jeśli odpowiedź to błąd HTTP (np. 500), jest to liczone jako odpowiedź z serwera docelowego, a licznik błędów jest resetowany. Aby mieć pewność, że nieprawidłowe odpowiedzi HTTP (takie jak 500) także będą zwiększać wartość licznika błędów i jak najszybciej wyeliminować z rotacji systemu równoważenia obciążenia w złym stanie, do konfiguracji systemu równoważenia obciążenia możesz dodać element <ServerUnhealthyResponse> z elementami podrzędnymi <ResponseCode>. Edge będzie też liczyć odpowiedzi z tymi kodami jako niepowodzenia.

W poniższym przykładzie obiekt target1 zostanie usunięty z rotacji po 5 nieudanych żądaniach, w tym niektórych odpowiedziach 5XX z serwera docelowego.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Wartość domyślna MaxFailures to 0. Oznacza to, że Edge zawsze próbuje połączyć się z miejscem docelowym w przypadku każdego żądania i nigdy nie usuwa serwera docelowego z rotacji.

Najlepiej używać wartości MaxFailures > 0 z HealthMonitor. Jeśli skonfigurujesz wartość MaxFailures > 0, serwer docelowy zostanie usunięty z rotacji, gdy cel nie zadziała zgodnie z podaną przez Ciebie liczbą razy. Po ustawieniu HealthMonitor Apigee automatycznie ustawia serwer docelowy z powrotem w rotacji po ponownym uruchomieniu środowiska docelowego zgodnie z konfiguracją tego HealthMonitor. Więcej informacji znajdziesz w sekcji Monitorowanie stanu.

Jeśli natomiast ustawisz wartość MaxFailures > 0 i nie skonfigurujesz HealthMonitor, Apigee nie ponownie uwzględni serwera docelowego w rotacji automatycznie po wykryciu przez Apigee błędu. W takim przypadku musisz ponownie wdrożyć serwer proxy interfejsu API, zanim Apigee włączy serwer docelowy w rotacji. Więcej informacji znajdziesz w artykule o wdrażaniu serwera proxy interfejsu API.

Spróbuj ponownie

Jeśli włączone jest ponawianie, żądanie jest ponawiane za każdym razem, gdy wystąpi niepowodzenie odpowiedzi (błąd wejścia-wyjścia lub czas oczekiwania HTTP) lub otrzymana odpowiedź będzie zgodna z wartością ustawioną przez <ServerUnhealthyResponse>. Więcej informacji o ustawieniu <ServerUnhealthyResponse> znajdziesz powyżej w sekcji Maksymalna liczba niepowodzeń.

Domyślnie <RetryEnabled> ma wartość true. Aby wyłączyć ponawianie próby, ustaw wartość false. Na przykład:

<RetryEnabled>false</RetryEnabled>

IsFallback

Jeden (i tylko jeden) serwer docelowy można ustawić jako serwer zastępczy. Zastępczy serwer docelowy nie jest uwzględniany w procedurach równoważenia obciążenia, dopóki wszystkie inne serwery docelowe nie zostaną zidentyfikowane przez system równoważenia obciążenia jako niedostępne. Gdy system równoważenia obciążenia ustali, że wszystkie serwery docelowe są niedostępne, cały ruch jest kierowany na serwer zastępczy. Na przykład:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Powyższa konfiguracja powoduje równoważenie obciążenia w trybie rotacyjnym między celami 1 i 2 do momentu, gdy oba cele 1 i 2 będą niedostępne. Gdy cele 1 i 2 są niedostępne, cały ruch jest kierowany do celu 3.

Ścieżka

Ścieżka określa fragment identyfikatora URI, który będzie dołączany do wszystkich żądań wysyłanych przez serwer docelowy do serwera backendu.

Ten element akceptuje ścieżkę do ciągu znaków literału lub szablon wiadomości. Szablon wiadomości umożliwia zastępowanie ciągu zmiennych w czasie działania. Na przykład w tej definicji docelowego punktu końcowego ścieżki używana jest wartość {mypath}:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Konfigurowanie serwera docelowego dla protokołu TLS/SSL

Jeśli używasz serwera docelowego do definiowania usługi backendu, a usługa backendu wymaga połączenia w celu korzystania z protokołu HTTPS, musisz włączyć TLS/SSL w definicji serwera docelowego. Jest to konieczne, ponieważ tag <Host> nie umożliwia określenia protokołu połączenia. Poniżej znajduje się definicja serwera docelowego dla jednokierunkowego protokołu TLS/SSL, w której Edge wysyła żądania HTTPS do usługi backendu:

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

Jeśli usługa backendu wymaga dwukierunkowej lub wzajemnego protokołu TLS/SSL, możesz skonfigurować serwer docelowy przy użyciu tych samych ustawień konfiguracji TLS/SSL co w przypadku punktów końcowych docelowych:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Informacje o właściwościach <SSLInfo>, takich jak <Ciphers> i <ClientAuthEnabled>, znajdziesz w informacjach o konfigurowaniu tych właściwości dla hosta wirtualnego w sekcji Konfigurowanie dostępu TLS do interfejsu API w chmurze prywatnej.

Pełne instrukcje konfigurowania wychodzącego ruchu TLS/SSL znajdziesz w artykule Konfigurowanie protokołu TLS z serwera Edge do backendu (Cloud i Private Cloud).

Schemat serwera docelowego

Zobacz schemat serwera docelowego i innych encji w GitHub.

Monitorowanie zdrowia

Monitorowanie stanu umożliwia ulepszenie konfiguracji równoważenia obciążenia przez aktywne odpytywanie adresów URL usług backendu zdefiniowanych w konfiguracjach serwera docelowego. Przy włączonym monitorowaniu stanu nieudanego serwera docelowego jest automatycznie przywracane do rotacji, gdy HealthMonitor ustali, że serwer docelowy jest aktywny.

Monitorowanie zdrowia działa z aplikacją <MaxFailures>. Przy wyłączonym monitorowaniu stanu <MaxFailures> określa liczbę nieudanych żądań z serwera proxy interfejsu API do serwera docelowego, które skutkują przekierowaniem żądania do innego serwera docelowego. Następnie serwer docelowy, w przypadku którego wystąpił błąd, będzie usuwany z rotacji, dopóki nie wdrożysz ponownie serwera proxy.

Przy włączonym monitorowaniu stanu nieudanego serwera docelowego jest automatycznie przywracane do rotacji i nie jest wymagane ponowne wdrażanie serwera proxy.

HealthMonitor działa jako prosty klient, który wywołuje usługę backendu przez TCP lub HTTP:

• Klient TCP zapewnia tylko możliwość otwarcia gniazda.
• Konfigurujesz klienta HTTP tak, aby przesyłał prawidłowe żądanie HTTP do usługi backendu. Możesz zdefiniować operacje HTTP GET, PUT, POST i DELETE. Odpowiedź wywołania monitora HTTP musi być zgodna z ustawieniami skonfigurowanymi w bloku <SuccessResponse>.

Sukcesy i porażki

Gdy włączysz monitorowanie stanu, Edge rozpoczyna wysyłanie kontroli stanu do serwera docelowego. Kontrola stanu to żądanie wysyłane do serwera docelowego, które określa, czy jest on w dobrym stanie.

Kontrola stanu może mieć jeden z 2 możliwych wyników:

• Sukces: serwer docelowy jest uznawany za dobry, gdy kontrola stanu się powiodła. Jest to zwykle spowodowane przez co najmniej jedną z tych przyczyn:
  • Serwer docelowy akceptuje nowe połączenie z określonym portem, odpowiada na żądanie na tym porcie, a następnie zamyka ten port w określonym przedziale czasu. Odpowiedź z serwera docelowego zawiera tekst „Połączenie: zamknięcie”.
  • Serwer docelowy odpowiada na żądanie kontroli stanu, wysyłając 200 (OK) lub inny kod stanu HTTP, który zostanie uznany za akceptowany.
  • Serwer docelowy odpowiada na żądanie kontroli stanu, przesyłając treść wiadomości zgodną z oczekiwaną treścią.

  Gdy Edge ustali, że serwer jest w dobrym stanie, kontynuuje lub wznawia wysyłanie do niego żądań.

• Błąd: w zależności od typu kontroli serwer docelowy może nie przejść kontroli stanu na różne sposoby. Awaria może być logowana, gdy serwer docelowy:
  • Blokuje połączenie między Edge z portem kontroli stanu.
  • Nie odpowiada na prośbę o kontrolę stanu w określonym czasie.
  • Zwraca nieoczekiwany kod stanu HTTP.
  • odpowiedź z treścią wiadomości niezgodną z oczekiwanym treścią wiadomości;

  Gdy serwer docelowy nie przejdzie kontroli stanu, serwer brzegowy zwiększa liczbę błędów tego serwera. Jeśli liczba błędów dla tego serwera osiągnie lub przekroczy wstępnie zdefiniowany próg (<MaxFailures>), Edge przestanie wysyłać żądania do tego serwera.

Włączanie monitora zdrowia

Aby utworzyć HealthMonitor, dodaj element <HealthMonitor> do konfiguracji HTTPConnection serwera proxy w docelowym punkcie końcowym. Nie można tego zrobić w interfejsie użytkownika. Zamiast tego utwórz konfigurację serwera proxy i prześlij ją jako plik ZIP do Edge. Konfiguracja serwera proxy to uporządkowany opis wszystkich aspektów serwera proxy interfejsu API. Konfiguracje serwera proxy składają się z plików XML we wstępnie zdefiniowanej strukturze katalogów. Więcej informacji znajdziesz w dokumentacji konfiguracji serwera proxy interfejsu API.

Prosty HealthMonitor definiuje obiekt IntervalInSec połączony z TCPMonitor lub HTTPMonitorem. Element <MaxFailures> określa maksymalną liczbę nieudanych żądań z serwera proxy interfejsu API do serwera docelowego, które powodują przekierowanie żądania do innego serwera docelowego. Domyślnie <MaxFailures> ma wartość 0, co oznacza, że Edge nie wykonuje działania naprawczego. Podczas konfigurowania monitora stanu ustaw wartość <MaxFailures> w tagu <HTTPTargetConnection> tagu <TargetEndpoint> na wartość inną niż zero.

TCPMonitor

Poniższa konfiguracja definiuje HealthMonitor, który odpytuje każdy serwer docelowy, otwierając połączenie na porcie 80 co 5 sekund. (Port jest opcjonalny. Jeśli nie określono tego portu, port TCPMonitor będzie portem serwera docelowego).

• Jeśli nie uda się nawiązać połączenia lub połączenie będzie trwać dłużej niż 10 sekund, liczba błędów dla danego serwera docelowego zwiększa się o 1.
• Jeśli połączenie się powiedzie, liczba błędów serwera docelowego jest resetowana do 0.

Możesz dodać HealthMonitor jako element podrzędny elementu HTTPTargetConnetion elementu TargetEndpoint w następujący sposób:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor z elementami konfiguracji TCPMonitor

Poniższa tabela zawiera opis elementów konfiguracji TCPMonitor:

Nazwa	Opis	Domyślnie	Wymagana?
IsEnabled	Wartość logiczna, która włącza lub wyłącza HealthMonitor.	false	Nie
IntervalInSec	Odstęp czasu (w sekundach) między poszczególnymi żądaniami TCP odpytywania.	0	Tak
ConnectTimeoutInSec	Czas, w którym musi zostać nawiązane połączenie z portem TCP, aby zostało uznane za udane. Nieudane połączenie w podanym odstępie czasu jest traktowane jako niepowodzenie, zwiększając liczbę błędów systemu równoważenia obciążenia dla serwera docelowego.	0	Tak
Port	Opcjonalnie. Port, na którym zostanie nawiązane połączenie TCP. Jeśli nie określono tego portu, port TCPMonitor będzie portem serwera docelowego.	0	Nie

HTTPMonitor

Przykładowy HealthMonitor, który korzysta z HTTPMonitor, będzie co 5 sekund przesyłać żądanie GET do usługi backendu. Poniższy przykład pokazuje nagłówek podstawowej autoryzacji HTTP do komunikatu żądania. Konfiguracja odpowiedzi określa ustawienia, które będą porównywane z rzeczywistą odpowiedzią usługi backendu. W przykładzie poniżej oczekiwana odpowiedź to kod odpowiedzi HTTP 200 i niestandardowy nagłówek HTTP ImOK, którego wartość to YourOK. Jeśli odpowiedź nie będzie zgodna, żądanie zostanie potraktowane jako błąd przez konfigurację systemu równoważenia obciążenia.

HTTPMonitor obsługuje usługi backendu skonfigurowane pod kątem używania protokołów HTTP i jednokierunkowych protokołów HTTPS. Nie są jednak obsługiwane:

• Dwukierunkowy protokół HTTPS (nazywany też dwukierunkową szyfrowaniem TLS/SSL)
• podpisane samodzielnie,

Wszystkie ustawienia żądań i odpowiedzi w monitorze HTTP są specyficzne dla usługi backendu, która musi zostać wywołana.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor z elementami konfiguracji HTTPMonitor

Tabela poniżej zawiera opis elementów konfiguracji HTTPMonitor:

Nazwa	Opis	Domyślnie	Wymagana?
IsEnabled	Wartość logiczna, która włącza lub wyłącza HealthMonitor.	false	Nie
IntervalInSec	Odstęp czasu (w sekundach) między poszczególnymi żądaniami odpytywania.	0	Tak
Request	Opcje konfiguracji wiadomości z żądaniem wychodzącym wysyłanej przez HealthMonitor do serwerów docelowych w rotacji. Ścieżka nie obsługuje zmiennych.	Nie dotyczy	Tak
IsSSL	Określa, czy do monitorowania połączeń ma być używany protokół HTTPS (bezpieczny HTTP). Potencjalne wartości: true: używany jest protokół HTTP. false: używany jest protokół HTTP. Nieokreślona: używana jest konfiguracja serwera docelowego.	false	Nie
ConnectTimeoutInSec	Czas (w sekundach), w którym musi zakończyć się uzgadnianie połączenia TCP z usługą HTTP, aby zostało uznane za powodzenie. Nieudane połączenie w podanym odstępie czasu jest traktowane jako niepowodzenie, zwiększając liczbę błędów systemu LoadBalancer dla serwera docelowego.	0	Nie
SocketReadTimeoutInSec	Czas w sekundach, w którym muszą zostać odczytane dane z usługi HTTP, aby można je było uznać za sukces. Nieudane odczyt w podanym odstępie czasu jest liczone jako błąd, co zwiększa liczbę błędów systemu LoadBalancer dla serwera docelowego.	0	Nie
Port	Port, na którym zostanie ustanowione połączenie HTTP z usługą backendu.	Nie dotyczy	Nie
Verb	Czasownik HTTP używany w przypadku każdego żądania HTTP wysyłanego do usługi backendu .	Nie dotyczy	Nie
Path	Ścieżka dołączana do adresu URL zdefiniowanego w serwerze docelowym. Użyj elementu ścieżki, aby skonfigurować „punkt końcowy sondowania” w usłudze HTTP.	Nie dotyczy	Nie
IncludeHealthCheckIdHeader	Umożliwia śledzenie żądań kontroli stanu w systemach nadrzędnych. IncludeHealthCheckIdHeader przyjmuje wartość logiczną i przyjmuje domyślnie wartość false. Jeśli ustawisz wartość true, do żądania kontroli stanu wstrzykiwany jest element Header o nazwie X-Apigee-Healthcheck-Id. Wartość nagłówka jest przypisywana dynamicznie i ma postać ORG/ENV/SERVER_UUID/N, gdzie ORG to nazwa organizacji, ENV to nazwa środowiska, SERVER_UUID to unikalny identyfikator identyfikujący MP, a N to liczba milisekund, które upłynęły od 1 stycznia 1970 r. Przykładowy nagłówek żądania: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	Nie
Payload	Treść HTTP generowana dla każdego żądania HTTP odpytywania. Pamiętaj, że w przypadku żądań GET ten element nie jest wymagany.	Nie dotyczy	Nie
SuccessResponse	Opcje dopasowania dla przychodzącej odpowiedzi HTTP wygenerowanej przez ankietowaną usługę backendu. Odpowiedzi, które nie pasują, zwiększają liczbę błędów o 1.	Nie dotyczy	Nie
ResponseCode	Kod odpowiedzi HTTP, który ma zostać odebrany z ankietowanego serwera docelowego. Kod inny niż podany spowoduje błąd, a liczba ta jest zwiększana w przypadku ankietowanej usługi backendu. Możesz zdefiniować wiele elementów ResponseCode.	Nie dotyczy	Nie
Headers	Lista co najmniej 1 nagłówka HTTP i wartości, które mają być odbierane z ankietowanej usługi backendu. Wszystkie nagłówki lub wartości HTTP w odpowiedzi, które różnią się od podanych, spowodują błąd, a liczba ankietowanych serwerów docelowych jest zwiększana o 1. Możesz zdefiniować wiele elementów nagłówka.	Nie dotyczy	Nie