Load balancing lintas server backend

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Apigee Edge meningkatkan ketersediaan API Anda dengan menyediakan dukungan bawaan untuk load balancing dan failover di beberapa instance server backend.

Konfigurasi TargetServer memisahkan URL endpoint konkret dari konfigurasi TargetEndpoint. Setiap TargetServer direferensikan dengan nama dalam HTTPConnection TargetEndpoint. Daripada menentukan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa TargetServers bernama seperti yang dijelaskan di bagian TargetEndpoint.

Definisi TargetServer terdiri dari nama, host, dan port, dengan elemen tambahan untuk menunjukkan apakah TargetServer diaktifkan atau dinonaktifkan.

Video

Tonton video berikut untuk mempelajari lebih lanjut perutean dan load balancing API menggunakan server target

Video	Deskripsi
Load balancing menggunakan server target	API load balancing di seluruh server target.
Pemilihan rute API berdasarkan lingkungan yang menggunakan server target	Rutekan API ke server target yang berbeda berdasarkan lingkungan.
Pemilihan rute dan load balancing API menggunakan server target (classic Edge)	Rutekan API ke server target yang berbeda berdasarkan lingkungan dan lakukan load balancing pada API Anda di berbagai server target di UI Classic Edge.

Contoh Konfigurasi TargetServer

Kode berikut menentukan server target:

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

Elemen Konfigurasi TargetServer

Tabel berikut menjelaskan elemen yang digunakan untuk membuat dan mengonfigurasi TargetServer:

Nama	Deskripsi	Default	Wajib diisi?
name	Nama konfigurasi TargetServer, yang harus unik di dalam lingkungan. Nama TargetServer hanya boleh berisi karakter alfanumerik.	T/A	Ya
Host	URL host layanan backend (tanpa protokol).	T/A	Ya
Port	Port tempat layanan backend memproses	T/A	Ya
IsEnabled	Boolean yang menunjukkan apakah konfigurasi TargetServer diaktifkan atau dinonaktifkan. Hal ini memungkinkan Anda mengeluarkan TargetServers dari rotasi tanpa mengubah konfigurasi proxy API. Penggunaan yang umum adalah menulis aplikasi atau skrip yang mengaktifkan atau menonaktifkan TargetServers secara otomatis berdasarkan persyaratan kapasitas yang diharapkan, jadwal pemeliharaan, dll.	true	Ya

Mengelola server target menggunakan UI

Kelola server target, seperti yang dijelaskan di bawah.

Mengelola server target menggunakan API

Anda dapat menggunakan Edge API untuk membuat, menghapus, mengupdate, mendapatkan, dan mencantumkan server target. Untuk mengetahui informasi selengkapnya, lihat TargetServers.

Gunakan panggilan API berikut untuk membuat server target:

$ 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

Contoh Respons:

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

Setelah Anda membuat TargetServer pertama, gunakan panggilan API berikut untuk membuat TargetServer kedua. Dengan menentukan dua TargetServer, Anda memberikan dua URL yang dapat digunakan TargetEndpoint untuk load balancing:

$ 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

Contoh Respons:

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

Gunakan panggilan API berikut untuk mengambil daftar TargetServers di lingkungan:

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

Contoh respons:

[ "target2", "target1" ]

Kini ada dua TargetServer yang tersedia untuk digunakan oleh proxy API yang di-deploy di lingkungan pengujian. Untuk melakukan load balancing terhadap traffic di seluruh TargetServer ini, konfigurasikan koneksi HTTP di endpoint target proxy API untuk menggunakan TargetServers.

Ada batas 500 TargetServer per lingkungan, seperti yang didokumentasikan dalam topik Batas.

Mengonfigurasi TargetEndpoint untuk melakukan load balancing di seluruh TargetServers yang bernama

Setelah memiliki dua TargetServer yang tersedia, Anda dapat memodifikasi setelan koneksi HTTP TargetEndpoint untuk merujuk kedua TargetServers tersebut berdasarkan namanya:

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

Konfigurasi di atas adalah konfigurasi load balancing paling dasar. Load balancer ini mendukung tiga algoritma load balancing, yakni Round Robin, Berbobot, dan Koneksi Terkecil. Round Robin adalah algoritma {i>default<i}. Karena tidak ada algoritma yang ditentukan dalam konfigurasi di atas, permintaan keluar dari proxy API ke server backend akan bergantian, satu per satu, antara target1 dan target 2.

Elemen <Path> membentuk dasar jalur URI TargetEndpoint untuk semua server target. Ini hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, akan diabaikan. Pada contoh di atas, permintaan yang mencapai "target1" akan menjadi http://target1/test, dan begitu juga untuk server target lainnya.

Menyetel opsi load balancer

Anda dapat menyesuaikan ketersediaan menggunakan opsi untuk load balancing dan failover di tingkat load balancer dan TargetServer. Bagian ini menjelaskan opsi tersebut.

Algorithm

Menetapkan algoritma yang digunakan oleh <LoadBalancer>. Algoritma yang tersedia adalah RoundRobin, Weighted, dan LeastConnections, yang masing-masing didokumentasikan di bawah ini.

Round robin

Algoritma default, round robin, meneruskan permintaan ke setiap TargetServer sesuai urutan daftar server dalam koneksi HTTP endpoint target. Contoh:

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

Berbobot

Algoritma load balancing berbobot memungkinkan Anda mengonfigurasi beban traffic yang proporsional untuk TargetServers Anda. LoadBalancer tertimbang mendistribusikan permintaan ke TargetServers Anda dalam proporsi langsung dengan bobot setiap TargetServer. Oleh karena itu, algoritma berbobot mengharuskan Anda menetapkan atribut weight untuk setiap TargetServer. Contoh:

<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>

Dalam contoh ini, dua permintaan akan dirutekan ke target2 untuk setiap satu permintaan yang dirutekan ke target1.

Koneksi Terendah

LoadBalancers yang dikonfigurasi untuk menggunakan algoritma koneksi yang paling sedikit akan merutekan permintaan keluar ke TargetServer dengan koneksi HTTP terbuka yang paling sedikit. Contoh:

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

Kegagalan maksimum

Jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain.

Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika hal ini terjadi, penghitung kegagalan akan bertambah satu.

Namun, saat Apigee menerima respons dari target, meskipun responsnya adalah error HTTP (seperti 500), yang dihitung sebagai respons dari server target, dan penghitung kegagalan direset. Untuk membantu memastikan bahwa respons HTTP yang buruk (seperti 500) juga menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari rotasi load balancing sesegera mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse> dengan elemen turunan <ResponseCode> ke konfigurasi load balancer. Edge juga akan menghitung respons dengan kode tersebut sebagai kegagalan.

Pada contoh berikut, target1 akan dihapus dari rotasi setelah lima permintaan gagal, termasuk beberapa respons 5XX dari server target.

<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>

Default MaxFailures adalah 0. Artinya, Edge selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.

Sebaiknya gunakan MaxFailures > 0 dengan HealthMonitor. Jika Anda mengonfigurasi MaxFailures > 0, TargetServer akan dihapus dari rotasi saat target gagal mencapai jumlah yang Anda tunjukkan. Saat HealthMonitor diterapkan, Apigee otomatis menempatkan TargetServer kembali berputar setelah target aktif dan berjalan kembali, sesuai dengan konfigurasi HealthMonitor tersebut. Lihat Pemantauan kesehatan untuk informasi selengkapnya.

Atau, jika Anda mengonfigurasi MaxFailures > 0, dan Anda tidak mengonfigurasi HealthMonitor, Apigee tidak akan otomatis menyertakan kembali TargetServer ke dalam rotasi setelah Apigee mendeteksi kegagalan. Dalam hal ini, Anda harus men-deploy ulang proxy API sebelum Apigee mengembalikan TargetServer kembali ke rotasi. Lihat Men-deploy proxy API.

Coba lagi

Jika percobaan ulang diaktifkan, permintaan akan dicoba lagi setiap kali terjadi kegagalan respons (error I/O atau waktu tunggu HTTP) terjadi atau respons yang diterima cocok dengan nilai yang ditetapkan oleh <ServerUnhealthyResponse>. Lihat Kegagalan maksimum di atas untuk mengetahui informasi selengkapnya tentang cara menetapkan <ServerUnhealthyResponse>.

Secara default, <RetryEnabled> disetel ke true. Setel ke false untuk menonaktifkan percobaan ulang. Contoh:

<RetryEnabled>false</RetryEnabled>

IsFallback

Satu (dan hanya satu) TargetServer yang dapat disetel sebagai server 'penggantian'. TargetServer penggantian tidak disertakan dalam rutinitas load balancing hingga semua TargetServer lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua TargetServers tidak tersedia, semua traffic akan dirutekan ke server penggantian. Contoh:

<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>

Konfigurasi di atas menghasilkan load balancing round robin antara target 1 dan 2 hingga kedua target 1 dan 2 tidak tersedia. Jika target 1 dan 2 tidak tersedia, semua traffic akan dialihkan ke target 3.

Jalur

Path menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh TargetServer ke server backend.

Elemen ini menerima jalur string literal atau template pesan. Template pesan memungkinkan Anda melakukan penggantian string variabel saat runtime. Misalnya, dalam definisi endpoint target berikut, nilai {mypath} digunakan untuk jalur:

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

Mengonfigurasi server target untuk TLS/SSL

Jika menggunakan TargetServer untuk menentukan layanan backend, dan layanan backend memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL dalam definisi TargetServer. Hal ini diperlukan karena tag <Host> tidak memungkinkan Anda menentukan protokol koneksi. Berikut adalah definisi TargetServer untuk TLS/SSL satu arah tempat Edge membuat permintaan HTTPS ke layanan backend:

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

Jika layanan backend memerlukan TLS/SSL dua arah, atau bersama, Anda dapat mengonfigurasi TargetServer menggunakan setelan konfigurasi TLS/SSL yang sama dengan TargetEndpoint:

<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 >

Untuk informasi tentang properti <SSLInfo>, seperti <Ciphers> dan <ClientAuthEnabled>, lihat informasi tentang menetapkan properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API untuk Private Cloud.

Untuk mengetahui petunjuk selengkapnya tentang cara mengonfigurasi TLS/SSL keluar, lihat Mengonfigurasi TLS dari Edge ke backend (Cloud dan Cloud Pribadi).

Skema TargetServer

Lihat skema untuk TargetServer dan entity lainnya di GitHub.

Pemantauan kesehatan

Health Monitoring memungkinkan Anda meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling pada URL layanan backend yang ditentukan dalam konfigurasi TargetServer. Dengan mengaktifkan pemantauan kondisi, TargetServer yang gagal akan otomatis dimasukkan kembali saat HealthMonitor menentukan bahwa TargetServer aktif.

Pemantauan kondisi berfungsi dengan <MaxFailures>. Tanpa mengaktifkan pemantauan kondisi, <MaxFailures> akan menentukan jumlah permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain. TargetServer yang gagal akan dikeluarkan dari rotasi hingga Anda men-deploy ulang proxy.

Dengan mengaktifkan pemantauan kondisi, TargetServer yang gagal akan otomatis dimasukkan kembali ke rotasi dan deployment ulang proxy tidak diperlukan.

HealthMonitor bertindak sebagai klien sederhana yang memanggil layanan backend melalui TCP atau HTTP:

• Klien TCP memastikan bahwa soket dapat dibuka.
• Anda akan mengonfigurasi klien HTTP untuk mengirimkan permintaan HTTP yang valid ke layanan backend. Anda dapat menentukan operasi HTTP GET, PUT, POST, atau DELETE. Respons panggilan monitor HTTP harus sesuai dengan setelan yang dikonfigurasi dalam blok <SuccessResponse>.

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Edge akan mulai mengirimkan health check ke server target Anda. Health check adalah permintaan yang dikirim ke server target yang menentukan apakah server target responsif atau tidak.

Health check dapat memiliki salah satu dari dua kemungkinan hasil:

• Berhasil: Server target dianggap responsif jika health check berhasil terjadi. Hal ini biasanya disebabkan oleh satu atau beberapa hal berikut:
  • Server target menerima koneksi baru ke port yang ditentukan, merespons permintaan pada port tersebut, lalu menutup port dalam jangka waktu yang ditentukan. Respons dari server target berisi “Connection: close”
  • Server target merespons permintaan health check dengan 200 (OK) atau kode status HTTP lain yang Anda anggap dapat diterima.
  • Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.

  Saat Edge menentukan bahwa server tersebut sehat, Edge akan melanjutkan atau melanjutkan pengiriman permintaan ke server.

• Kegagalan: Server target dapat menggagalkan health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat server target:
  • Menolak koneksi dari Edge ke port health check.
  • Tidak merespons permintaan health check dalam jangka waktu tertentu.
  • Menampilkan kode status HTTP yang tidak diharapkan.
  • Merespons dengan isi pesan yang tidak cocok dengan isi pesan yang diharapkan.

  Jika server target gagal dalam health check, Edge akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melampaui ambang batas yang telah ditentukan (<MaxFailures>), Edge akan berhenti mengirim permintaan ke server tersebut.

Mengaktifkan HealthMonitor

Untuk membuat HealthMonitor, Anda menambahkan elemen <HealthMonitor> ke konfigurasi HTTPConnection TargetEndpoint untuk proxy. Anda tidak dapat melakukannya di UI. Sebagai gantinya, Anda membuat konfigurasi proxy dan menguploadnya sebagai file ZIP ke Edge. Konfigurasi proxy adalah deskripsi terstruktur dari semua aspek proxy API. Konfigurasi proxy terdiri dari file XML dalam struktur direktori yang telah ditentukan sebelumnya. Untuk mengetahui informasi selengkapnya, lihat Referensi Konfigurasi Proxy API.

HealthMonitor sederhana menentukan IntervalInSec yang dikombinasikan dengan TCPMonitor atau HTTPMonitor. Elemen <MaxFailures> menentukan jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang mengakibatkan permintaan dialihkan ke TargetServer lain. Secara default, <MaxFailures> adalah 0, yang berarti Edge tidak melakukan tindakan korektif. Saat mengonfigurasi pemantau kondisi, pastikan Anda menetapkan <MaxFailures> dalam tag <HTTPTargetConnection> tag <TargetEndpoint> ke nilai bukan nol.

TCPMonitor

Konfigurasi di bawah menentukan HealthMonitor yang melakukan polling setiap TargetServer dengan membuka koneksi pada port 80 setiap lima detik. (Porta bersifat opsional. Jika tidak ditentukan, port TCPMonitor adalah port TargetServer.)

• Jika koneksi gagal atau membutuhkan waktu lebih dari 10 detik untuk terhubung, jumlah kegagalan akan bertambah 1 untuk TargetServer tersebut.
• Jika koneksi berhasil, jumlah kegagalan untuk TargetServer direset ke 0.

Anda dapat menambahkan HealthMonitor sebagai elemen turunan dari elemen HTTPTargetConnetion TargetEndpoint, seperti ditunjukkan di bawah ini:

<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 dengan elemen konfigurasi TCPMonitor

Tabel berikut menjelaskan elemen konfigurasi TCPMonitor:

Nama	Deskripsi	Default	Wajib diisi?
IsEnabled	Boolean yang mengaktifkan atau menonaktifkan HealthMonitor.	false	Tidak
IntervalInSec	Interval waktu, dalam detik, antara setiap permintaan TCP polling.	0	Ya
ConnectTimeoutInSec	Waktu saat membuat koneksi ke port TCP agar dianggap berhasil. Kegagalan terhubung dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan load balancer untuk TargetServer.	0	Ya
Port	Opsional. Porta tempat koneksi TCP akan dibuat. Jika tidak ditentukan, port TCPMonitor adalah port TargetServer.	0	Tidak

HTTPMonitor

Contoh HealthMonitor yang menggunakan HTTPMonitor akan mengirimkan permintaan GET ke layanan backend sekali setiap lima detik. Contoh di bawah ini menambahkan header Otorisasi Dasar HTTP ke pesan permintaan. Konfigurasi Respons menentukan setelan yang akan dibandingkan dengan respons sebenarnya dari layanan backend. Pada contoh di bawah, respons yang diharapkan adalah kode respons HTTP 200 dan header HTTP kustom ImOK yang nilainya adalah YourOK. Jika responsnya tidak cocok, permintaan akan dianggap gagal oleh konfigurasi load balancer.

HTTPMonitor mendukung layanan backend yang dikonfigurasi untuk menggunakan HTTP dan protokol HTTPS satu arah. Namun, hal ini tidak mendukung hal berikut:

• HTTPS Dua arah (juga disebut TLS/SSL dua arah)
• Sertifikat yang ditandatangani sendiri.

Perlu diketahui bahwa semua setelan Request and Response dalam monitor HTTP akan bersifat khusus untuk layanan backend yang harus dipanggil.

    <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 dengan elemen konfigurasi HTTPMonitor

Tabel berikut menjelaskan elemen konfigurasi HTTPMonitor:

Nama	Deskripsi	Default	Wajib diisi?
IsEnabled	Boolean yang mengaktifkan atau menonaktifkan HealthMonitor.	false	Tidak
IntervalInSec	Interval waktu, dalam detik, antara setiap permintaan polling.	0	Ya
Request	Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh HealthMonitor ke TargetServers dalam rotasi. Jalur tidak mendukung variabel.	T/A	Ya
IsSSL	Menentukan apakah akan menggunakan HTTPS (HTTP aman) untuk memantau koneksi. Nilai potensial: true: HTTP digunakan. false: HTTP digunakan. Belum ditentukan: Menggunakan konfigurasi server target.	false	Tidak
ConnectTimeoutInSec	Waktu, dalam detik, saat handshake koneksi TCP ke layanan HTTP harus diselesaikan agar dianggap berhasil. Kegagalan terhubung dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan LoadBalancer untuk TargetServer.	0	Tidak
SocketReadTimeoutInSec	Waktu, dalam detik, saat data harus dibaca dari layanan HTTP agar dianggap berhasil. Kegagalan membaca dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan LoadBalancer untuk TargetServer.	0	Tidak
Port	Port tempat koneksi HTTP ke layanan backend akan dibuat.	T/A	Tidak
Verb	Kata kerja HTTP yang digunakan untuk setiap permintaan HTTP polling ke layanan backend .	T/A	Tidak
Path	Jalur yang ditambahkan ke URL yang ditentukan di TargetServer. Gunakan elemen jalur untuk mengonfigurasi 'endpoint polling' di layanan HTTP Anda.	T/A	Tidak
IncludeHealthCheckIdHeader	Memungkinkan Anda melacak permintaan health check di sistem upstream. IncludeHealthCheckIdHeader menggunakan nilai Boolean, dan secara default disetel ke false. Jika Anda menetapkannya ke true, maka akan ada Header bernama X-Apigee-Healthcheck-Id yang dimasukkan ke permintaan healthcheck. Nilai header ditetapkan secara dinamis, dan berbentuk ORG/ENV/SERVER_UUID/N, dengan ORG sebagai nama organisasi, ENV adalah nama lingkungan, SERVER_UUID adalah ID unik yang mengidentifikasi MP, dan N adalah jumlah milidetik yang berlalu sejak 1 Januari 1970. Contoh header permintaan yang dihasilkan: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	Tidak
Payload	Isi HTTP yang dihasilkan untuk setiap permintaan HTTP polling. Perhatikan bahwa elemen ini tidak diperlukan untuk permintaan GET.	T/A	Tidak
SuccessResponse	Opsi pencocokan untuk pesan respons HTTP masuk yang dihasilkan oleh layanan backend yang di-polling. Respons yang tidak cocok akan menambah jumlah kegagalan sebesar 1.	T/A	Tidak
ResponseCode	Kode respons HTTP yang diharapkan akan diterima dari TargetServer yang di-polling. Kode yang berbeda dari kode yang ditentukan akan menghasilkan kegagalan, dan jumlah meningkat untuk layanan backend yang di-polling. Anda dapat menentukan beberapa elemen ResponseCode.	T/A	Tidak
Headers	Daftar satu atau beberapa header dan nilai HTTP yang diharapkan akan diterima dari layanan backend yang di-polling. Header atau nilai HTTP apa pun pada respons yang berbeda dengan yang telah ditentukan akan menyebabkan kegagalan, dan jumlah untuk TargetServer yang di-polling bertambah 1. Anda dapat menentukan beberapa elemen Header.	T/A	Tidak