Halaman ini meninjau jenis load balancer yang tersedia dari Cloud Load Balancing dan menjelaskan cara menggunakan metrik Cloud Monitoring yang diekspos olehnya sebagai SLI.
Layanan Cloud Load Balancing sering kali menyediakan titik entri pertama untuk aplikasi yang dihosting di Google Cloud. Load balancer otomatis diinstrumentasi untuk memberikan informasi tentang traffic, ketersediaan, dan latensi layanan Google Cloud yang ditampilkan. Oleh karena itu, load balancer sering kali berfungsi sebagai sumber metrik SLI yang sangat baik tanpa memerlukan instrumentasi aplikasi.
Saat memulai, Anda dapat memilih untuk berfokus pada ketersediaan dan latensi sebagai dimensi utama keandalan serta membuat SLI dan SLO untuk mengukur serta memberi tahu dimensi tersebut. Halaman ini memberikan contoh penerapan.
Untuk informasi tambahan, lihat referensi berikut:
- Konsep dalam pemantauan layanan
- Dokumentasi untuk Cloud Load Balancing
- Daftar jenis metrik
loadbalancing.googleapis.com
SLI dan SLO Ketersediaan
Untuk aplikasi non-UDP, SLI ketersediaan berbasis permintaan adalah yang paling tepat, karena interaksi layanan dipetakan dengan rapi ke permintaan.
Anda mengekspresikan SLI ketersediaan berbasis permintaan dengan menggunakan struktur TimeSeriesRatio untuk menyiapkan rasio permintaan baik terhadap total permintaan, seperti yang ditunjukkan dalam contoh ketersediaan berikut.
Untuk mendapatkan penentuan "baik" atau "valid" yang diinginkan, Anda memfilter
metrik menggunakan label yang tersedia.
Load balancer lapisan 7 (HTTP/S) eksternal
Load balancer HTTP/S digunakan untuk mengekspos aplikasi yang diakses melalui HTTP/S dan mendistribusikan traffic ke resource yang terletak di beberapa region.
Load Balancer Aplikasi Eksternal menulis data metrik ke Monitoring menggunakan jenis resource dan metrik yang dipantau https_lb_rule dengan awalan loadbalancing.googleapis.com. Jenis metrik yang paling relevan dengan SLO ketersediaan adalah https/request_count, yang dapat Anda filter menggunakan label metrik response_code_class.
Jika Anda memilih untuk tidak menghitung permintaan yang menghasilkan kode respons error 4xx sebagai "valid" karena dapat menunjukkan error klien, bukan error layanan atau aplikasi, Anda dapat menulis filter untuk "total" seperti ini:
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
Anda juga perlu menentukan cara menghitung permintaan "baik". Misalnya, jika memilih untuk hanya menghitung yang menampilkan kode respons status berhasil 200 OK, Anda dapat menulis filter untuk "baik" seperti ini:
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
Anda kemudian dapat mengekspresikan SLI berbasis permintaan seperti ini:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Untuk aplikasi yang traffic-nya disalurkan oleh beberapa backend, Anda dapat memilih untuk menentukan SLI untuk backend tertentu. Untuk membuat SLI ketersediaan untuk backend tertentu, gunakan metrik https/backend_request_count dengan label resource backend_target_name di filter Anda, seperti yang ditunjukkan dalam contoh ini:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\"
resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
resource.label.\"backend_target_name\"=\"my-app-backend\"
metric.label.\"response_code_class\"=\"200\"",
}
}
}
Load balancer lapisan 7 (HTTP/S) internal
Load Balancer Aplikasi Internal menulis data metrik ke Monitoring menggunakan jenis resource dan metrik yang dipantau internal_http_lb_rule dengan awalan loadbalancing.googleapis.com. Jenis metrik yang paling relevan dengan SLO ketersediaan adalah https/internal_request_count, yang dapat Anda filter menggunakan label metrik response_code_class.
Berikut ini contoh SLI ketersediaan berbasis permintaan:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"!=\"400\"",
"goodServiceFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
resource.type=\"internal_http_lb_rule\"
resource.label.\"url_map_name\"=\"my-internal-lb\"
metric.label.\"response_code_class\"=\"200\"",
}
}
},
Load balancer Lapisan 3 (TCP)
Load balancer TCP tidak memberikan metrik permintaan karena aplikasi yang
menggunakan metrik ini mungkin tidak didasarkan pada model respons permintaan. Tidak satu pun dari metrik loadbalancing.googleapis.com yang disediakan oleh load balancer ini yang cocok dengan SLI ketersediaan yang baik.
Untuk membuat SLI ketersediaan untuk load balancer ini, Anda harus membuat metrik kustom atau berbasis log. Untuk informasi selengkapnya, lihat Menggunakan metrik kustom atau Menggunakan metrik berbasis log.
SLI dan SLO Latensi
Untuk aplikasi permintaan-respons, ada dua cara untuk menulis SLO latensi:
- Sebagai SLO berbasis permintaan.
- Sebagai SLO berbasis jendela.
SLO latensi berbasis permintaan
SLO berbasis permintaan menerapkan nilai minimum latensi dan menghitung fraksi permintaan yang selesai di bawah nilai minimum tersebut dalam periode kepatuhan tertentu. Contoh SLO berbasis permintaan adalah "99% permintaan selesai dalam waktu kurang dari 100 md dalam rentang waktu satu jam".
Anda mengekspresikan SLI latensi berbasis permintaan menggunakan struktur DistributionCut, seperti yang ditunjukkan dalam contoh latensi berikut.
Satu SLO berbasis permintaan tidak dapat menangkap performa umum dan penurunan pengalaman pengguna, ketika permintaan "ekor" atau yang paling lambat mengalami waktu respons yang semakin lama. SLO untuk performa standar tidak mendukung pemahaman latensi tail. Untuk pembahasan tentang latensi tail, lihat bagian "Mengkhawatirkan Tentang Ekor Anda" dalam Bab 6: Memantau Sistem Terdistribusi dalam Site Reliability Engineering.
Untuk mengurangi batasan ini, Anda dapat menulis SLO kedua untuk berfokus secara khusus pada latensi tail, misalnya, "99,9% permintaan selesai dalam waktu kurang dari 1.000 md selama periode 1 jam yang bergulir". Kombinasi kedua SLO menangkap degradasi dalam pengalaman pengguna standar dan latensi tail.
SLO latensi berbasis jendela
SLO berbasis jendela menentukan kriteria kebaikan untuk jangka waktu pengukuran dan menghitung rasio interval "baik" terhadap jumlah total interval. Contoh SLO berbasis periode adalah "Metrik latensi persentil ke-95 kurang dari 100 md untuk setidaknya 99% periode satu menit, selama periode berjalan selama 28 hari":
- Periode pengukuran yang "baik" adalah durasi satu menit saat 95% permintaan memiliki latensi di bawah 100 milidetik.
- Ukuran kepatuhan adalah bagian dari periode "baik" tersebut. Layanan mematuhi kebijakan jika fraksi ini minimal 0,99, yang dihitung selama periode kepatuhan.
Anda harus menggunakan SLO berbasis jendela jika metrik mentah yang tersedia untuk Anda adalah persentil latensi; yaitu, jika kedua hal berikut berlaku:
- Data dikelompokkan ke dalam jangka waktu (misalnya, ke dalam interval satu menit).
- Data dinyatakan dalam grup persentil (misalnya, p50, p90, p95, p99).
Untuk jenis data ini, setiap grup persentil menunjukkan waktu yang membagi grup data di atas dan di bawah persentil tersebut. Misalnya, interval satu menit dengan metrik latensi p95 89 md menunjukkan bahwa, untuk menit tersebut, layanan merespons 95% permintaan dalam waktu 89 md atau kurang.
Load Balancer Aplikasi Eksternal
Load Balancer Aplikasi Eksternal menggunakan jenis metrik utama berikut untuk menangkap latensi:
https/total_latencies: distribusi latensi yang dihitung dari saat permintaan diterima oleh proxy hingga proxy mendapatkan ACK dari klien pada byte respons terakhir. Gunakan ketika pengalaman pengguna secara keseluruhan sangat penting.https/backend_latencies: distribusi latensi yang dihitung dari saat permintaan dikirim oleh proxy ke backend hingga proxy menerima byte respons terakhir dari backend. Gunakan untuk mengukur latensi backend tertentu yang menyalurkan traffic di belakang load balancer.
Metrik ini ditulis berdasarkan jenis resource pemantauan https_lb_rule.
Total latensi
Contoh SLO ini memperkirakan bahwa 99% permintaan akan memiliki total latensi antara 0 dan 100 md selama periode satu jam:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
resource.type=\"https_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Latensi backend
Contoh ini memperkirakan bahwa 98% permintaan ke target backend "my-app-backend" memiliki latensi antara 0 dan 100 md selama periode satu jam:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-app-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Load Balancer Aplikasi internal
Load Balancer Aplikasi Internal menggunakan dua jenis metrik utama untuk menangkap latensi:
https/internal/total_latencies: distribusi latensi yang dihitung dari saat permintaan diterima oleh proxy hingga proxy mendapatkan ACK dari klien pada byte respons terakhir. Gunakan ketika pengalaman pengguna secara keseluruhan sangat penting.https/internal/backend_latencies: distribusi latensi yang dihitung dari saat permintaan dikirim oleh proxy ke backend hingga proxy menerima byte respons terakhir dari backend. Gunakan untuk mengukur latensi backend tertentu yang menyalurkan traffic di belakang load balancer.
Metrik ini ditulis berdasarkan jenis resource yang dimonitor
internal_http_lb_rule.
Total latensi
Contoh ini SLO memperkirakan bahwa 99% permintaan akan memiliki total latensi antara 0 hingga 100 md selama periode satu jam:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
resource.type=\"internal_http_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Contoh ini SLO memperkirakan bahwa 99% permintaan akan memiliki total latensi antara 0 hingga 100 md selama periode satu jam.
Latensi backend
Contoh ini memperkirakan bahwa 98% permintaan ke target backend "my-internal-backend" memiliki latensi antara 0 dan 100 milidetik selama periode satu jam:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
resource.type=\"https_lb_rule\"
resource.label.\"backend_target_name\"=\"my-internal-backend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Load balancer lapisan 3 (TCP) eksternal
Load balancer TCP eksternal menggunakan satu jenis metrik,
l3/external/rtt_latencies, yang mencatat distribusi
waktu round-trip yang diukur melalui koneksi TCP untuk alur load-balancer eksternal.
Metrik ini ditulis berdasarkan resource tcp_lb_rule.
Contoh ini SLO memperkirakan bahwa 99% permintaan akan memiliki total latensi antara 0 hingga 100 md selama periode satu jam:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
resource.type=\"tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Load balancer lapisan 3 (TCP) internal
Load balancer TCP internal menggunakan satu jenis metrik, l3/internal/rtt_latencies, yang mencatat distribusi waktu round-trip yang diukur melalui koneksi TCP untuk alur load-balancer internal.
Metrik ini ditulis berdasarkan resource internal_tcp_lb_rule.
Contoh ini SLO memperkirakan bahwa 99% permintaan akan memiliki total latensi antara 0 hingga 100 md selama periode satu jam:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
resource.type=\"internal_tcp_lb_rule\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}