Load balancing lintas server backend

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

Apigee Edge meningkatkan ketersediaan API Anda dengan memberikan 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 pemilihan rute 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 menggunakan server target	Merutekan 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 seluruh server target pada 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 dari 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 untuk 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 membuat daftar 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 TargetServers, 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 tanggapan:

[ "target2", "target1" ]

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

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

Mengonfigurasi TargetEndpoint untuk load balancing di seluruh TargetServers bernama

Setelah memiliki dua TargetServers yang tersedia, Anda dapat memodifikasi setelan koneksi HTTP TargetEndpoint untuk mereferensikan kedua TargetServers tersebut berdasarkan nama:

<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 mendukung tiga algoritma load balancing, yaitu Round Robin, Berbobot, dan Koneksi Terkecil. Round Robin adalah algoritma {i>default<i}. Karena tidak ada algoritme 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 basepath URI TargetEndpoint untuk semua server target. Kolom ini hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, akan diabaikan. Dalam contoh di atas, permintaan yang menjangkau "target1" adalah 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 level 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

Algoritme 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

Algoritme load balancing berbobot memungkinkan Anda mengonfigurasi beban traffic yang proporsional untuk TargetServers Anda. LoadBalancer berbobot mendistribusikan permintaan ke TargetServers Anda secara proporsional dengan setiap bobot TargetServer. Oleh karena itu, algoritme 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 diarahkan ke target2 untuk setiap satu permintaan yang diarahkan ke target1.

Koneksi Terkecil

LoadBalancers yang dikonfigurasi untuk menggunakan algoritma koneksi yang paling sedikit mengarahkan 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 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 Anda. 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 ketika target gagal sebanyak yang Anda tentukan. Saat HealthMonitor diterapkan, Apigee otomatis menempatkan TargetServer kembali dalam rotasi 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 menempatkan kembali TargetServer. Lihat Men-deploy proxy API.

Coba lagi

Jika percobaan ulang diaktifkan, permintaan akan dicoba lagi setiap kali 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>

Penggantian

Satu (dan hanya satu) TargetServer dapat disetel sebagai server 'penggantian'. TargetServer penggantian tidak disertakan dalam rutinitas load balancing hingga semua TargetServers 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 dirutekan ke target 3.

Path

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 Anda menggunakan TargetServer untuk menentukan layanan backend, dan layanan backend memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL di definisi TargetServer. Hal ini diperlukan karena tag <Host> tidak mengizinkan Anda menentukan protokol koneksi. Di bawah ini 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 mengonfigurasi TargetServer menggunakan setelan konfigurasi TLS/SSL yang sama dengan TargetEndpoints:

<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 mengetahui informasi tentang properti <SSLInfo>, seperti <Ciphers> dan <ClientAuthEnabled>, lihat informasi tentang cara menetapkan properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API untuk Private Cloud.

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

Skema TargetServer

Lihat skema untuk TargetServer dan entity lainnya di GitHub.

Pemantauan kesehatan

Pemantauan kondisi memungkinkan Anda untuk meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling URL layanan backend yang ditentukan dalam konfigurasi TargetServer. Jika pemantauan kondisi diaktifkan, TargetServer yang gagal akan otomatis diputar kembali saat HealthMonitor menentukan bahwa TargetServer aktif.

Pemantauan kondisi berfungsi dengan <MaxFailures>. Jika pemantauan kondisi tidak diaktifkan, <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 sampai Anda men-deploy ulang proxy.

Jika pemantauan kondisi diaktifkan, TargetServer yang gagal akan otomatis dialihkan kembali dan deployment ulang proxy tidak diperlukan.

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

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

Keberhasilan dan kegagalan

Jika 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 yang berhasil. Hal ini biasanya terjadi karena 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 “Koneksi: tutup”
  • Server target merespons permintaan health check dengan kode status HTTP 200 (OK) atau lainnya 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 responsif, Edge akan melanjutkan atau melanjutkan pengiriman permintaan ke server.

• Kegagalan: Server target dapat menggagalkan health check dengan cara yang berbeda, 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 terduga.
  • Merespons dengan isi pesan yang tidak cocok dengan isi pesan yang diharapkan.

  Jika server target gagal dalam health check, Edge akan menambahkan jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melebihi nilai minimum yang telah ditentukan (<MaxFailures>), Edge akan berhenti mengirim permintaan ke server tersebut.

Mengaktifkan HealthMonitor

Untuk membuat HealthMonitor, tambahkan elemen <HealthMonitor> ke konfigurasi HTTPConnection di TargetEndpoint untuk proxy. Anda tidak dapat melakukannya di UI. Sebagai gantinya, buat konfigurasi proxy dan upload 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 ditetapkan sebelumnya. Untuk mengetahui informasi selengkapnya, lihat Referensi Konfigurasi Proxy API.

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

TCPMonitor

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

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

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

<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, di antara setiap permintaan TCP polling.	0	Ya
ConnectTimeoutInSec	Waktu saat koneksi ke port TCP harus dibuat 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

Pemantauan HTTP

Contoh HealthMonitor yang menggunakan HTTPMonitor akan mengirimkan permintaan GET ke layanan backend setiap lima detik sekali. 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. Dalam contoh di bawah, respons yang diharapkan adalah kode respons HTTP 200 dan header HTTP kustom ImOK yang nilainya adalah YourOK. Jika respons tidak cocok, permintaan akan dianggap sebagai kegagalan oleh konfigurasi load balancer.

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

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

Perhatikan bahwa semua setelan Permintaan dan Respons dalam pemantau HTTP akan bersifat khusus untuk layanan backend yang harus dipanggil.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <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, di antara setiap permintaan polling.	0	Ya
Request	Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh HealthMonitor ke TargetServers pada rotasi. Jalur tidak mendukung variabel.	T/A	Ya
ConnectTimeoutInSec	Waktu, dalam detik, saat handshake koneksi TCP ke layanan HTTP harus selesai 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 dalam 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 ditetapkan 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 mengambil nilai Boolean, dan secara default ditetapkan ke false. Jika Anda menetapkannya ke true, akan ada Header bernama X-Apigee-Healthcheck-Id yang dimasukkan ke dalam permintaan healthcheck. Nilai header ditetapkan secara dinamis dan berbentuk ORG/ENV/SERVER_UUID/N, dengan ORG sebagai nama organisasi, ENV sebagai 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 dibuat 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 mengakibatkan kegagalan, dan jumlahnya bertambah 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. Setiap header atau nilai HTTP pada respons yang berbeda dengan yang ditentukan akan mengakibatkan kegagalan, dan jumlah untuk TargetServer yang di-polling bertambah 1. Anda dapat mendefinisikan beberapa elemen Header.	T/A	Tidak