Halaman ini diterjemahkan oleh Cloud Translation API.

Load balancing di berbagai server backend

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Baca dokumentasi Apigee Edge.

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

TargetServers memisahkan URL endpoint konkret dari konfigurasi TargetEndpoint. Daripada menetapkan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa TargetServers yang bernama. Kemudian, setiap TargetServer direferensikan dengan nama dalam HTTPConnection TargetEndpoint.

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.

Tentang konfigurasi TargetServer

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

Kode berikut memberikan contoh konfigurasi TargetServer:

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

Untuk informasi lebih lanjut tentang API TargetServers, lihat organizations.environments.targetservers.

Lihat skema untuk TargetServer dan entity lainnya di GitHub.

Membuat TargetServers

Buat TargetServer menggunakan UI atau API Apigee seperti yang dijelaskan di bagian berikut.

Apigee di Konsol Cloud

Untuk membuat TargetServer menggunakan Apigee di Konsol Cloud:

Login ke https://console.cloud.google.com/apigee.
Pilih Management > Environments > TargetServers.
Pilih lingkungan tempat Anda ingin menetapkan TargetServer baru.
Klik Target Servers di bagian atas panel.
Klik + Create Target Server.
Masukkan nama, host, protokol, dan port di kolom yang disediakan. Opsi untuk Protocol adalah: HTTP untuk server target berbasis REST, gRPC - Target untuk server target berbasis gRPC, atau gRPC - External callout. Lihat Membuat proxy gRPC API untuk informasi tentang dukungan proxy gRPC.
Anda juga dapat memilih Aktifkan SSL. Lihat Ringkasan sertifikat SSL.
Klik Create.

Apigee Klasik

Untuk membuat TargetServers menggunakan UI Apigee klasik:

Login ke UI Apigee.
Pilih Admin > Environments > TargetServers.
Dari menu drop-down Environment, pilih lingkungan tempat Anda ingin menetapkan TargetServer baru.
UI Apigee menampilkan daftar TargetServer saat ini di lingkungan yang dipilih:
Klik +Target server untuk menambahkan TargetServer baru ke lingkungan yang dipilih.
Kotak dialog Add target server akan menampilkan:
Klik Enabled untuk mengaktifkan TargetServer baru. definisinya segera setelah Anda membuatnya.
Masukkan nama, host, protokol, dan port di kolom yang disediakan. Opsi untuk Protokol adalah HTTP atau GRPC.

Jika ingin, Anda dapat memilih kotak centang SSL. Untuk mengetahui informasi selengkapnya tentang kolom ini, lihat TargetServers (video 4MV4D).
Klik Tambahkan.
Apigee membuat definisi TargetServer baru.
Setelah membuat TargetServer baru, Anda dapat mengedit proxy API dan mengubah elemen <HTTPTargetConnection> untuk merujuk definisi baru.

API Apigee

Bagian berikut memberikan contoh penggunaan Apigee API untuk membuat dan membuat daftar TargetServer.

Membuat TargetServer di lingkungan menggunakan API
Mencantumkan TargetServers di lingkungan menggunakan API

Untuk mengetahui informasi selengkapnya, lihat TargetServers API.

Membuat TargetServer dalam lingkungan menggunakan API

Untuk membuat TargetServer bernama target1 yang terhubung ke 1.mybackendservice.com pada port 80, gunakan panggilan API berikut:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Dengan $TOKEN ditetapkan ke token akses OAuth 2.0, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk deskripsi tentang variabel lingkungan yang digunakan, lihat Menetapkan variabel lingkungan untuk permintaan Apigee API.

Berikut ini memberikan contoh respons:

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

Buat TargetServer kedua menggunakan panggilan API berikut. Dengan menentukan dua TargetServer, Anda memberikan dua URL yang dapat digunakan TargetEndpoint untuk load balancing:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Berikut ini memberikan contoh respons:

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

Mencantumkan TargetServers di lingkungan menggunakan API

Untuk mencantumkan TargetServers dalam lingkungan, gunakan panggilan API berikut:

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Berikut ini memberikan contoh respons:

[ "target2", "target1" ]

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

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

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

Untuk mengetahui informasi selengkapnya, lihat TargetEndpoint.

Mengonfigurasi opsi load balancer

Anda dapat menyesuaikan ketersediaan dengan mengonfigurasi opsi untuk load balancing dan failover di tingkat load balancer dan TargetServer seperti yang dijelaskan di bagian berikut.

Algoritma

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

Panggilan acak

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 TargetServer. 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 TargetServer, 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. Apigee 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 TargetServer.

<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. Ini berarti Apigee selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus TargetServer 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 akan otomatis mengeluarkan TargetServer dari rotasi saat kegagalan pertama terdeteksi. Apigee akan memeriksa kondisi TargetServer setiap lima menit dan mengembalikannya ke rotasi saat merespons secara normal.

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 fallback. 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 target1 dan target2 hingga target1 dan target2 tidak tersedia. Jika target1 dan target2 tidak tersedia, semua traffic akan dialihkan ke target3.

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 TargetServer 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. Di bawah ini adalah definisi TargetServer untuk TLS/SSL satu arah tempat Apigee membuat permintaan HTTPS ke layanan backend:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Catatan: Jika Anda menentukan blok sSLInfo di definisi TargetEndpoint dan TargetServer, yang ada di TargetServer akan diprioritaskan.

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

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Untuk membuat TargetServer dengan SSL menggunakan panggilan API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

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, TargetServers yang tidak dapat dijangkau atau menampilkan respons error akan ditandai sebagai tidak responsif. TargetServer yang gagal akan otomatis dikembalikan ke rotasi saat HealthMonitor menentukan bahwa TargetServer aktif. Deployment ulang proxy tidak diperlukan.

Anda harus menetapkan <MaxFailures> lebih besar dari 0 saat menggunakan HealthMonitor. Nilai <MaxFailures> 0 mengonfigurasi Apigee agar selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus TargetServer dari rotasi.

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

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

Health check dapat memiliki salah satu dari dua kemungkinan hasil:

Berhasil: TargetServer dianggap responsif jika health check berhasil terjadi. Hal ini biasanya disebabkan oleh satu atau beberapa hal berikut:
- TargetServer menerima koneksi baru ke port yang ditentukan, merespons permintaan pada port tersebut, lalu menutup port dalam jangka waktu yang ditentukan. Respons dari TargetServer berisi Connection: close
- TargetServer merespons permintaan health check dengan 200 (OK) atau kode status HTTP lain yang Anda anggap dapat diterima.
- TargetServer merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.
Saat Apigee menentukan bahwa server responsif, Apigee akan melanjutkan pengiriman atau melanjutkan pengiriman permintaan ke server tersebut.
Kegagalan: TargetServer dapat menggagalkan health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat TargetServer:
- Menolak koneksi dari Apigee 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 TargetServer gagal dalam health check, Apigee menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melampaui ambang batas yang telah ditentukan (<MaxFailures>), Apigee 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 Apigee. 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 Apigee 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>
</TargetEndpoint>

HealthMonitor dengan elemen konfigurasi TCPMonitor

Tabel berikut menjelaskan elemen konfigurasi TCPMonitor:

Nama	Deskripsi	Default	Wajib?
`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, layanan ini tidak mendukung HTTPS dua arah, juga disebut TLS/SSL dua arah, atau sertifikat yang ditandatangani sendiri.

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

    <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>
          <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>
      </HTTPTargetConnection>
    </TargetEndpoint>

Elemen konfigurasi <HTTPMonitor>

Tabel berikut menjelaskan elemen konfigurasi <HTTPMonitor> tingkat atas:

Nama	Deskripsi	Default	Wajib?
`IsEnabled`	Boolean yang mengaktifkan atau menonaktifkan HealthMonitor.	false	Tidak
`IntervalInSec`	Interval waktu, dalam detik, antara setiap permintaan polling.	0	Ya

Elemen konfigurasi <HTTPMonitor>/<Request>

Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh HealthMonitor ke TargetServers dalam rotasi. Perhatikan bahwa <Request> adalah elemen yang diperlukan.

Nama	Deskripsi	Default	Wajib?
`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.	Port server target	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 `Path` untuk mengonfigurasi 'endpoint polling' di layanan HTTP Anda. Perhatikan bahwa elemen `Path` tidak mendukung variabel.	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

Elemen konfigurasi <HTTPMonitor>/<SuccessResponse>

(Opsional) Opsi pencocokan untuk pesan respons HTTP masuk yang dibuat oleh layanan backend yang di-polling. Respons yang tidak cocok akan menambah jumlah kegagalan sebesar 1.

Nama	Deskripsi	Default	Wajib?
`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