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.
Server target memisahkan URL endpoint konkret dari konfigurasi endpoint target. Daripada menetapkan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa server target yang telah diberi nama. Kemudian, setiap server target dirujuk oleh nama dalam HTTPConnection endpoint target.
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 server target
Konfigurasi server target terdiri dari nama, host, protokol, dan port, dengan
elemen tambahan untuk
menunjukkan apakah server target diaktifkan atau dinonaktifkan. Server target juga dapat memiliki objek <sSLInfo>
opsional.
Kode berikut memberikan contoh konfigurasi server target:
{ "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 server target
Buat server target menggunakan UI atau API Apigee seperti yang dijelaskan di bagian berikut.
Apigee di Konsol Cloud
Untuk membuat server target menggunakan Apigee di Cloud Console:
- Login ke UI Apigee di Konsol Cloud.
- Pilih Pengelolaan > Lingkungan.
- Pilih lingkungan tempat Anda ingin menetapkan server target 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 server target menggunakan UI Apigee klasik:
- Login ke UI Apigee.
- Pilih Admin > Environments > TargetServers.
- Dari menu drop-down Environment, pilih lingkungan tempat Anda ingin menetapkan server target baru.
UI Apigee menampilkan daftar server target saat ini di lingkungan yang dipilih:
- Klik +Target server untuk menambahkan server target baru ke lingkungan yang dipilih.
Kotak dialog Add target server akan menampilkan:
- Klik Enabled untuk mengaktifkan server target 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 server target baru.
- Setelah membuat server target 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 server target.
- Membuat server target di lingkungan menggunakan API
- Mencantumkan server target di lingkungan menggunakan API
Untuk mengetahui informasi selengkapnya, lihat TargetServers API.
Membuat server target dalam lingkungan menggunakan API
Untuk membuat server target 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 server target kedua menggunakan panggilan API berikut. Dengan menentukan dua server target, Anda memberikan dua URL yang dapat digunakan endpoint target 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 server target dalam lingkungan menggunakan API
Untuk mencantumkan server target di 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 server target yang tersedia untuk digunakan oleh proxy API yang di-deploy di lingkungan test
. Untuk melakukan load balancing terhadap traffic di seluruh server target ini, konfigurasikan koneksi HTTP di endpoint target proxy API untuk menggunakan server target.
Mengonfigurasi endpoint target untuk melakukan load balancing di berbagai server target bernama
Setelah memiliki dua server target yang tersedia, Anda dapat memodifikasi elemen <HTTPTargetConnection>
endpoint target untuk mereferensikan kedua server target 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 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 endpoint target untuk semua server target. 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 server target lainnya.
Mengonfigurasi opsi load balancer
Anda dapat menyesuaikan ketersediaan dengan mengonfigurasi opsi untuk load balancing dan failover di tingkat load balancer dan server target 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 server target 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 server target. LoadBalancer tertimbang mendistribusikan permintaan ke server target dalam proporsi langsung dengan bobot setiap server target. Oleh karena itu, algoritma berbobot mengharuskan Anda menetapkan atribut weight
untuk setiap server target. 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 mengarahkan permintaan keluar ke server target dengan koneksi HTTP terbuka 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 server target sehingga permintaan dialihkan ke server target lainnya.
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 404
atau 500
), yang dihitung sebagai respons dari server target, dan penghitung kegagalan direset. Untuk 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.
Dalam contoh berikut, target1
akan dihapus dari rotasi setelah lima permintaan gagal, termasuk 404
dan 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>404</ResponseCode> <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 server target dari rotasi.
Sebaiknya gunakan MaxFailures > 0 dengan monitor kesehatan. Jika Anda mengonfigurasi MaxFailures > 0, server target akan dihapus dari rotasi saat target gagal mencapai jumlah yang Anda tunjukkan. Saat monitor kesehatan diterapkan, Apigee akan otomatis menempatkan server target kembali berputar setelah target aktif dan berjalan kembali, sesuai dengan konfigurasi pemantau kondisi tersebut. Lihat Pemantauan kesehatan untuk informasi selengkapnya.
Atau, jika Anda mengonfigurasi MaxFailures > 0 dan Anda tidak mengonfigurasi monitor kesehatan, Apigee akan otomatis mengeluarkan server target dari rotasi saat kegagalan pertama terdeteksi. Apigee akan memeriksa kondisi server target 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) server target yang dapat disetel sebagai server fallback. Server target penggantian tidak disertakan dalam rutinitas load balancing hingga semua server target lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua server target non-penggantian 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
.
Jika server penggantian tidak responsif, Apigee tidak akan mengarahkan traffic ke server tersebut.
Sebagai gantinya, panggilan API akan menampilkan error 503
"Layanan sementara tidak tersedia".
Jalur
Path menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh server target 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 server target untuk menentukan layanan backend, dan layanan backend
memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL dalam
definisi server target. Hal ini diperlukan karena tag host
tidak memungkinkan Anda
menentukan protokol koneksi.
Mengonfigurasi TLS/SSL satu arah
Gunakan konfigurasi berikut untuk menentukan server target dengan TLS/SSL satu arah. Dalam contoh ini, Apigee membuat permintaan HTTPS ke layanan backend:
{ "name": "target1", "host": "mocktarget.apigee.net", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true" } }
Mengonfigurasi penerapan SSL yang ketat
Untuk menentukan penerapan SSL yang ketat dalam definisi server target, tetapkan enforce
ke true
dalam blok sSLInfo
, seperti ditunjukkan dalam contoh berikut:
{ "name": "target1", "host": "mocktarget.apigee.net", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true", "enforce": "true" } }
Mengonfigurasi TLS/SSL dua arah
Jika layanan backend memerlukan TLS/SSL dua arah, atau bersama, Anda dapat mengonfigurasi server target dengan setelan konfigurasi TLS/SSL yang sama seperti endpoint target:
{ "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": [] } }
Mengonfigurasi SSL yang ketat menggunakan API
Untuk membuat server target dengan penerapan SSL yang ketat 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, "enforce":true, "clientAuthEnabled":true, "keyStore":"keystore-name", "keyAlias":"keystore-alias", "ciphers":[], "protocols":[], "clientAuthEnabled":true, "ignoreValidationErrors":false, "trustStore":"truststore-name" } }'
Pemantauan kesehatan
Dengan pemantauan kondisi, Anda dapat meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling pada URL layanan backend yang ditentukan dalam konfigurasi server target. Dengan mengaktifkan pemantauan kesehatan, server target yang tidak dapat dijangkau atau menampilkan respons error akan ditandai sebagai tidak responsif. Server target yang gagal akan otomatis dikembalikan ke rotasi saat monitor kesehatan menentukan bahwa server target aktif. Deployment ulang proxy tidak diperlukan.
Pemantau kesehatan 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
, atauDELETE
. 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 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 Apigee menentukan bahwa server responsif, Apigee akan melanjutkan pengiriman atau melanjutkan pengiriman permintaan ke server tersebut.
- 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
- Kegagalan: Server target dapat menggagalkan health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat server target:
- 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 server target gagal dalam health check, Apigee akan 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 monitor kesehatan
Guna membuat pemantauan kondisi untuk proxy API, tambahkan elemen <HealthMonitor>
ke konfigurasi elemen <HTTPTargetConnection
endpoint target untuk proxy tersebut.
Pemantau kesehatan tidak dapat dibuat 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.
Elemen konfigurasi <HealthMonitor>
Tabel berikut menjelaskan elemen konfigurasi <HealthMonitor>
:
Nama | Deskripsi | Default | Wajib? |
---|---|---|---|
IsEnabled |
Boolean yang mengaktifkan atau menonaktifkan pemantauan kondisi. | false | Tidak |
IntervalInSec |
Interval waktu, dalam detik, antara setiap permintaan TCP atau HTTP polling. | 0 | Ya |
HTTPMonitor atau TCPMonitor |
Definisi dari klien TCP atau HTTP yang akan digunakan untuk melakukan polling pada server target. | T/A | Ya |
Selain elemen-elemen tersebut, untuk mengaktifkan monitor kondisi, Anda harus menetapkan
elemen <MaxFailures>
dalam blok <HTTPTargetConnection>
elemen <TargetEndpoint>
ke nilai yang lebih besar dari 0.
<MaxFailures>
digunakan untuk menentukan jumlah maksimum permintaan yang gagal dari proxy API ke server target yang dapat terjadi sebelum permintaan dialihkan ke server target lainnya.
Secara default, <MaxFailures>
adalah 0, yang berarti Apigee tidak melakukan tindakan korektif. Saat mengonfigurasi monitor kondisi, pastikan Anda menetapkan
<MaxFailures>
ke nilai bukan nol.
Monitor kondisi menggunakan monitor TCP
Contoh monitor kondisi yang dijelaskan dalam konfigurasi berikut menggunakan monitor TCP untuk melakukan polling pada setiap server target dengan membuka koneksi pada port 80 setiap lima detik. (Porta bersifat opsional. Jika tidak ditentukan, porta monitor TCP adalah porta server target.)
Dalam contoh konfigurasi monitor kondisi ini:
- Jika koneksi gagal atau membutuhkan waktu lebih dari 10 detik untuk terhubung, jumlah kegagalan akan bertambah 1 untuk server target tersebut.
- Jika koneksi berhasil, jumlah kegagalan untuk server target direset ke 0.
Anda dapat menambahkan monitor kesehatan sebagai elemen turunan dari elemen <HTTPTargetConnection>
endpoint target, 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>
Elemen konfigurasi <TCPMonitor>
Tabel berikut menjelaskan elemen konfigurasi <TCPMonitor>
:
Nama | Deskripsi | Default | Wajib? |
---|---|---|---|
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 server target. | 0 | Ya |
Port |
Opsional. Porta tempat koneksi TCP akan dibuat. Jika tidak ditentukan, port monitor TCP adalah port server target. | 0 | Tidak |
Health monitor menggunakan monitor HTTP
Contoh monitor kondisi yang dijelaskan dalam konfigurasi berikut menggunakan monitor HTTP yang
mengirimkan permintaan GET
ke layanan
backend setiap lima detik sekali dan menambahkan header Otorisasi Dasar HTTP ke
pesan permintaan.
Dalam contoh konfigurasi monitor kondisi ini:
- Respons yang diharapkan dari layanan backend adalah kode respons HTTP
200
. - Nilai yang diharapkan untuk header Otorisasi Dasar HTTP kustom
ImOK
adalahYourOK
. - Elemen
<UseTargetServerSSLInfo>
disetel ketrue
untuk menggunakan parameter SSL dari blok<SSLInfo>
server target.
Dengan konfigurasi ini, kode respons dan nilai header yang diharapkan akan dibandingkan dengan respons sebenarnya dari layanan backend. Jika responsnya tidak cocok, permintaan akan dianggap gagal oleh konfigurasi load balancer.
Secara default, pemantau kesehatan tidak dapat mengakses keystore, truststore, atau parameter SSL lainnya dari server targetnya.
Untuk mengaktifkan akses ke parameter ini untuk pemantauan kondisi Anda agar dapat mendukung TLS bersama, misalnya,
tambahkan <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
dalam blok <Request>
.
<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> <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> <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? |
---|---|---|---|
Request |
Pesan permintaan keluar yang dikirim oleh monitor kondisi ke server target dalam rotasi. | T/A | Ya |
SuccessResponse |
(Opsional) Opsi pencocokan untuk pesan respons HTTP masuk yang dibuat oleh layanan backend yang di-polling. | T/A | Tidak |
Elemen konfigurasi <HTTPMonitor>/<Request>
Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh monitor kondisi ke server target 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, yang meningkatkan jumlah kegagalan LoadBalancer untuk server target. | 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 server target. | 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 server target. Gunakan elemen Path untuk
mengonfigurasi 'endpoint polling' di layanan HTTP Anda. Perhatikan bahwa elemen Path tidak mendukung variabel. |
T/A | Tidak |
UseTargetServerSSLInfo |
Jika UseTargetServerSSLInfo bernilai true, permintaan pemantau kondisi kesehatan ke server target akan menggunakan parameter SSL dari blok SSLInfo ("sSLInfo") server target. Jika tidak,
parameter SSL seperti protokol, keystore, truststore, dan sebagainya tidak akan tersedia untuk
pemantau kondisi. |
false | Tidak |
| 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 |
Header |
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 server target yang di-polling bertambah 1. Anda dapat menentukan beberapa elemen Header. | T/A | Tidak |
IsSSL |
Jika true (benar), menentukan bahwa permintaan pemantauan kondisi dikirim menggunakan HTTPS. | Salah | Tidak |
TrustAllSSL |
Menentukan apakah pemeriksaan monitor HTTP akan otomatis memercayai semua sertifikat SSL. | Salah | 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 server target 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 |
Header |
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 server target yang di-polling bertambah 1. Anda dapat menentukan beberapa elemen Header. | T/A | Tidak |