Layanan permintaan-respons adalah layanan yang meminta layanan secara eksplisit untuk melakukan beberapa pekerjaan dan menunggu pekerjaan tersebut berhasil diselesaikan. Contoh paling umum dari layanan tersebut adalah:
- Aplikasi web yang berinteraksi langsung dengan pengguna manusia menggunakan browser.
- Aplikasi seluler yang terdiri dari aplikasi klien di ponsel pengguna dan backend API yang berinteraksi dengan klien.
- Backend API yang digunakan oleh layanan lain (bukan pengguna manusia).
Untuk semua layanan ini, pendekatan umum adalah memulai dengan SLI ketersediaan (mengukur rasio permintaan yang berhasil) dan latensi (mengukur rasio permintaan yang selesai dalam batas waktu). Untuk informasi selengkapnya tentang SLI ketersediaan dan latensi, lihat Konsep dalam pemantauan layanan.
Anda menyatakan SLI ketersediaan berbasis permintaan menggunakan
struktur TimeSeriesRatio untuk menyiapkan rasio
permintaan yang baik terhadap total permintaan. Anda dapat menentukan cara memfilter metrik dengan
menggunakan label yang tersedia untuk mendapatkan penentuan yang Anda inginkan
"baik" atau "valid".
Anda mengekspresikan SLI latensi berbasis permintaan menggunakan
struktur DistributionCut.
Cloud Endpoints
Cloud Endpoints adalah layanan untuk mengelola API. Dengan gateway API, Anda dapat mengambil API yang ada dan mengeksposnya dengan autentikasi, kuota, dan pemantauan.
Endpoint diimplementasikan sebagai proxy di depan server aplikasi gRPC. Dengan mengukur metrik di proxy, Anda dapat menangani kasus dengan benar
saat semua backend tidak tersedia dan pengguna melihat error.
Endpoint menulis data ke jenis metrik yang dimulai dengan
awalan serviceruntime.googleapis.com.
Untuk informasi selengkapnya, lihat referensi berikut:
- Dokumentasi untuk Cloud Endpoints.
- Daftar jenis metrik
serviceruntime.googleapis.com.
SLI Ketersediaan
Cloud Endpoints menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor api dan jenis metrik runtime layanan api/request_count, yang dapat Anda filter dengan menggunakan label metrik response_code untuk menghitung permintaan "baik" dan "total".
Anda menyatakan SLI ketersediaan berbasis permintaan dengan membuat
struktur TimeSeriesRatio untuk permintaan yang baik
terhadap total permintaan, seperti yang ditunjukkan dalam contoh berikut:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"serviceruntime.googleapis.com/api/request_count\"
resource.type=\"api\"
metric.label.\"response_code_class\"!=\"4xx\"",
"goodServiceFilter":
"metric.type=\"serviceruntime.googleapis.com/api/request_count\"
resource.type=\"api\"
(metric.label.\"response_code_class\"=\"1xx\"" OR
metric.label.\"response_code_class\"=\"2xx\""),
}
}
}
SLI berdasarkan Latensi
Cloud Endpoints menggunakan jenis metrik utama berikut untuk merekam latensi:
-
api/request_latencies: distribusi latensi dalam detik untuk permintaan non-streaming. Gunakan jika pengalaman pengguna keseluruhan merupakan hal yang paling penting. -
api/request_latencies_backend: distribusi latensi backend dalam detik untuk permintaan non-streaming. Gunakan untuk mengukur latensi backend secara langsung. -
api/request_latencies_overhead: distribusi latensi permintaan dalam detik untuk permintaan non-streaming, tidak termasuk backend. Gunakan untuk mengukur overhead yang diperkenalkan oleh proxy Endpoints.
Perhatikan bahwa total latensi permintaan adalah jumlah latensi backend dan overhead:
request_latencies = request_latencies_backend + request_latencies_overhead
Endpoint menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor api dan salah satu jenis metrik latensi permintaan.
Tidak ada jenis metrik ini yang memberikan label response_code atauresponse_code_class; oleh karena itu, metrik ini melaporkan latensi untuk semua permintaan.
Anda menyatakan SLI latensi berbasis permintaan menggunakan
struktur DistributionCut, seperti yang ditunjukkan dalam
contoh berikut.
Contoh SLO berikut memperkirakan bahwa 99% dari semua permintaan dalam project memiliki total latensi antara 0 dan 100 md selama periode satu jam bergulir:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
resource.type=\"api\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
Contoh SLO berikut memperkirakan bahwa 98% permintaan memiliki latensi backend antara 0 dan 100 md selama periode satu jam bergulir:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
resource.type=\"api\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.98,
"rollingPeriod": "3600s",
"displayName": "98% requests under 100 ms"
}
Cloud Run
Cloud Run adalah platform komputasi yang terkelola sepenuhnya untuk men-deploy dan menskalakan aplikasi dalam container secara cepat dan aman. Cloud Run dimaksudkan untuk memisahkan semua pengelolaan infrastruktur dengan merespons perubahan traffic dengan otomatis menaikkan dan menurunkan skala dari nol hampir secara instan, dan hanya menagih Anda sesuai resource yang Anda gunakan.
Untuk informasi tambahan tentang visibilitas Cloud Run, lihat referensi berikut:
- Dokumentasi untuk Cloud Run.
- Daftar jenis metrik
run.googleapis.com.
SLI Ketersediaan
Cloud Run menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor cloud_run_revision dan jenis metrik request_count. Anda dapat memfilter data menggunakan label metrik response_code atau response_code_class untuk menghitung permintaan "baik" dan "total".
Anda menyatakan SLI ketersediaan berbasis permintaan dengan membuat
struktur TimeSeriesRatio untuk permintaan yang baik
terhadap total permintaan, seperti yang ditunjukkan dalam contoh berikut:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"run.googleapis.com/request_count\"
resource.type=\"cloud_run_revision\"
metric.label.\"response_code_class\"!=\"4xx\"",
"goodServiceFilter":
"metric.type=\"run.googleapis.com/request_count\"
resource.type=\"cloud_run_revision\"
(metric.label.\"response_code_class\"=\"1xx\"" OR
metric.label.\"response_code_class\"=\"2xx\""),
}
}
}
SLI berdasarkan Latensi
Untuk mengukur latensi, Cloud Run menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor cloud_run_revision dan jenis metrik request_latencies. Data ini adalah distribusi latensi permintaan dalam milidetik yang mencapai revisi. Anda dapat memfilter data dengan menggunakan label metrik response_code atau response_code_class jika perlu mengukur latensi semua permintaan secara eksplisit atau hanya permintaan yang berhasil.
Anda mengekspresikan SLI latensi berbasis permintaan menggunakan
struktur DistributionCut. Contoh SLO
berikut memperkirakan bahwa 99% permintaan memiliki total latensi
antara 0 dan 100 md selama periode satu jam bergulir:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"run.googleapis.com/request_latencies\"
resource.type=\"cloud_run_revision"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
Fungsi Cloud Run
Fungsi Cloud Run adalah penawaran Functions as a Service bayar sesuai penggunaan yang skalabel yang menjalankan kode Anda tanpa perlu mengelola infrastruktur apa pun. Fungsi digunakan dalam banyak pola arsitektur untuk melakukan hal-hal seperti pemrosesan peristiwa, otomatisasi, dan menayangkan permintaan HTTP/S.
Untuk informasi tentang kemampuan observasi fungsi Cloud Run, lihat hal berikut:
- Dokumentasi untuk fungsi Cloud Run.
- Daftar jenis metrik
run.googleapis.com.
SLI Ketersediaan
Fungsi Cloud Run menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor cloud_function dan jenis metrik function/execution_time.
Anda dapat memfilter data menggunakan label metrik status untuk menghitung eksekusi "baik" dan "total".
Anda menyatakan SLI ketersediaan berbasis permintaan dengan membuat
struktur TimeSeriesRatio untuk permintaan yang baik
terhadap total permintaan, seperti yang ditunjukkan dalam contoh berikut:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
resource.type=\"cloud_function\"",
"goodServiceFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
resource.type=\"cloud_function\
metric.label.\"status\"=\"ok\"",
}
}
}
SLI berdasarkan Latensi
Untuk mengukur latensi, fungsi Cloud Run menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor cloud_function dan jenis metrik function/execution_times. Data ini adalah distribusi waktu eksekusi fungsi dalam nanodetik."
Anda dapat memfilter data menggunakan status jika perlu mengukur latensi semua eksekusi atau hanya eksekusi yang berhasil secara eksplisit.
Anda mengekspresikan SLI latensi berbasis permintaan menggunakan
struktur DistributionCut. Contoh SLO berikut mengharapkan bahwa 99% dari semua eksekusi fungsi Cloud Run memiliki latensi total antara 0 dan 100 mdtk selama periode satu jam bergulir:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
resource.type=\"cloud_function\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
App Engine
App Engine menyediakan platform serverless yang terkelola sepenuhnya untuk mem-build dan menjalankan aplikasi. Anda memiliki pilihan dua lingkungan, standar atau fleksibel; untuk informasi selengkapnya, lihat Memilih lingkungan App Engine.
Untuk informasi selengkapnya tentang App Engine, lihat referensi berikut:
- Dokumentasi untuk App Engine.
- Daftar jenis metrik
appengine.googleapis.com.
SLI berdasarkan Ketersediaan
App Engine menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor gae_app dan jenis metrik http/server/response_count.
Anda dapat memfilter data menggunakan label metrik response_code untuk menghitung respons "baik" dan "total".
Anda menyatakan SLI ketersediaan berbasis permintaan untuk App Engine
dengan membuat struktur TimeSeriesRatio
untuk permintaan yang baik terhadap total permintaan, seperti yang ditunjukkan dalam contoh
berikut:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_count\"
resource.type=\"gae_app\"
metric.label.\"response_code\">\"499\"
metric.label.\"response_code\"<\"399\"",
"goodServiceFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_count\"
resource.type=\"gae_app\"
metric.label.\"response_code\"<\"299\"",
}
}
}
SLI berdasarkan Latensi
Untuk mengukur latensi, App Engine menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor gae_app dan jenis metrik http/server/response_latencies.
Anda dapat memfilter data menggunakan label metrik response_code untuk menghitung eksekusi "baik" dan "total".
Anda menyatakan SLI latensi berbasis permintaan untuk App Engine
menggunakan struktur
DistributionCut. Contoh SLO berikut memperkirakan bahwa 99% dari semua permintaan memiliki
total latensi antara 0 dan 100 md selama periode satu jam bergulir:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
resource.type=\"gae_app\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}
GKE dan Istio
Google Kubernetes Engine (GKE) adalah layanan Kubernetes yang aman dan terkelola dari Google dengan penskalaan otomatis empat arah dan dukungan multi-cluster. Istio adalah mesh layanan open source yang memungkinkan Anda menghubungkan, mengamankan, mengontrol, dan mengamati layanan. Istio dapat diinstal di GKE sebagai add-on—Cloud Service Mesh—atau oleh pengguna dari project open source. Dalam kedua kasus tersebut, Istio menyediakan telemetri yang sangat baik, termasuk informasi tentang traffic, error, dan latensi untuk setiap layanan yang dikelola oleh mesh.
Untuk mengetahui daftar lengkap metrik Istio, lihat Jenis metrik istio.io.
SLI berdasarkan Ketersediaan
Istio menulis data metrik ke Cloud Monitoring menggunakan jenis metrik service/server/request_count dan salah satu jenis resource yang dimonitor berikut:
Anda dapat memfilter data menggunakan label metrik response_code untuk menghitung permintaan "baik" dan "total". Anda juga dapat menggunakan label metrik destination_service_name untuk menghitung permintaan untuk layanan tertentu.
Anda menyatakan SLI ketersediaan berbasis permintaan untuk layanan yang berjalan di GKE yang dikelola oleh mesh layanan Istio dengan membuat struktur TimeSeriesRatio untuk permintaan yang baik terhadap total permintaan, seperti yang ditunjukkan dalam contoh berikut:
"serviceLevelIndicator": {
"requestBased": {
"goodTotalRatio": {
"totalServiceFilter":
"metric.type=\"istio.io/service/server/request_count\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"",
"goodServiceFilter":
"metric.type=\istio.io/server/response_count\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"
metric.label.\"response_code\"<\"299\"",
}
}
}
SLI berdasarkan Latensi
Untuk mengukur latensi, Istio menulis data metrik ke Cloud Monitoring menggunakan jenis metrik service/server/response_latencies dan salah satu jenis resource yang dimonitor berikut:
Anda dapat memfilter data menggunakan label metrik response_code untuk menghitung label metrik "good" and "total" requests. You can also use thedestination_service_name` untuk menghitung permintaan untuk layanan tertentu.
Anda menyatakan SLI latensi berbasis permintaan untuk layanan yang berjalan di
GKE yang dikelola oleh mesh layanan Istio
dengan menggunakan struktur DistributionCut.
Contoh SLO berikut memperkirakan bahwa 99% dari semua permintaan ke layanan frontend
memiliki total latensi antara 0 dan 100 md selama periode satu jam
bergulir:
{
"serviceLevelIndicator": {
"requestBased": {
"distributionCut": {
"distributionFilter":
"metric.type=\"istio.io/server/response_latencies\"
resource.type=\"k8s_container\"
metric.label.\"destination_service_name\"=\"frontend\"",
"range": {
"min": 0,
"max": 100
}
}
}
},
"goal": 0.99,
"rollingPeriod": "3600s",
"displayName": "99% requests under 100 ms"
}