Layanan permintaan-respons adalah layanan saat pelanggan secara eksplisit meminta layanan untuk melakukan beberapa pekerjaan dan menunggu pekerjaan tersebut berhasil diselesaikan. Contoh paling umum dari layanan tersebut adalah:
- Aplikasi web yang berinteraksi dengan pengguna manusia secara langsung 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 umumnya adalah memulai dengan ketersediaan (mengukur rasio permintaan yang berhasil) dan latensi (mengukur rasio permintaan yang selesai di bawah batas waktu) SLI. Untuk mengetahui informasi selengkapnya tentang SLI ketersediaan dan latensi, lihat Konsep dalam pemantauan layanan.
Anda mengekspresikan SLI ketersediaan berbasis permintaan menggunakan
struktur TimeSeriesRatio untuk menyiapkan rasio
permintaan yang baik terhadap total permintaan. Anda memutuskan cara memfilter metrik menggunakan label yang tersedia untuk mendapatkan penentuan "baik" atau "valid" yang Anda inginkan.
Anda mengekspresikan SLI latensi berbasis permintaan menggunakan
struktur DistributionCut.
Cloud Endpoints
Cloud Endpoints adalah layanan untuk mengelola API. Dengan API ini, Anda dapat mengambil API yang sudah 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 mengalami 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 api/request_count layanan-runtime, yang dapat Anda filter menggunakan label metrik response_code untuk menghitung permintaan "baik" dan "total".
Anda mengekspresikan SLI ketersediaan berbasis permintaan dengan membuat
struktur TimeSeriesRatio untuk permintaan yang baik
hingga 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 menangkap latensi:
-
api/request_latencies: distribusi latensi dalam detik untuk permintaan non-streaming. Gunakan jika pengalaman pengguna secara keseluruhan adalah hal yang sangat penting. -
api/request_latencies_backend: distribusi latensi backend dalam hitungan detik untuk permintaan non-streaming. Gunakan untuk mengukur latensi backend secara langsung. -
api/request_latencies_overhead: distribusi latensi permintaan dalam hitungan detik untuk permintaan non-streaming, tidak termasuk backend. Gunakan untuk mengukur overhead yang diperkenalkan oleh proxy Endpoint.
Perlu diketahui bahwa total latensi permintaan adalah jumlah latensi backend dan overhead:
request_latencies = request_latencies_backend + request_latencies_overhead
Endpoints menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor api dan salah satu jenis metrik latensi permintaan.
Tidak satu pun dari jenis metrik ini yang memberikan label response_code atau response_code_class; oleh karena itu, jenis metrik tersebut melaporkan latensi untuk semua permintaan.
Anda mengekspresikan 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 milidetik selama periode satu jam yang 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": "98% requests under 100 ms"
}
Contoh SLO berikut memperkirakan bahwa 98% permintaan akan berada dalam latensi backend antara 0 dan 100 md selama periode satu jam yang berkelanjutan:
{
"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. Fitur ini dimaksudkan untuk memisahkan semua pengelolaan infrastruktur dengan merespons perubahan traffic dengan menaikkan dan menurunkan skala dari nol secara otomatis hampir secara instan dan hanya membebankan biaya sesuai resource yang Anda gunakan.
Untuk mengetahui informasi tambahan tentang kemampuan observasi Cloud Run, lihat artikel berikut:
- Dokumentasi untuk Cloud Run.
- Daftar jenis metrik
run.googleapis.com.
SLI Ketersediaan
Cloud Run menulis data metrik ke Cloud Monitoring menggunakan
cloud_run_revision jenis resource yang dipantau dan
request_count
jenis metrik. Anda dapat memfilter data menggunakan label metrik response_codeatau response_code_class untuk menghitung permintaan "baik" dan "total".
Anda mengekspresikan SLI ketersediaan berbasis permintaan dengan membuat
struktur TimeSeriesRatio untuk permintaan yang baik
hingga 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 dan jenis metrik request_latencies cloud_run_revision. Data tersebut adalah distribusi latensi permintaan
dalam milidetik yang mencapai revisi. Anda dapat memfilter data menggunakan label metrik response_codeatau response_code_class jika Anda 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 akan memiliki total latensi antara 0 dan 100 milidetik selama periode satu jam yang berkelanjutan:
{
"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": "98% requests under 100 ms"
}
Cloud Functions
Cloud Functions adalah penawaran Functions as a Service bayar sesuai penggunaan yang skalabel, yang menjalankan kode Anda tanpa perlu mengelola infrastruktur apa pun. Fungsi digunakan di banyak pola arsitektur untuk melakukan hal-hal seperti pemrosesan peristiwa, otomatisasi, dan melayani permintaan HTTP/S.
Untuk mengetahui informasi tentang kemampuan observasi Cloud Functions, lihat artikel berikut:
- Dokumentasi untuk Cloud Functions.
- Daftar jenis metrik
run.googleapis.com.
SLI Ketersediaan
Cloud Functions menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor dan cloud_function serta jenis metrik function/execution_time.
Anda dapat memfilter data menggunakan label metrik status untuk menghitung eksekusi "baik"
dan "total".
Anda mengekspresikan SLI ketersediaan berbasis permintaan dengan membuat
struktur TimeSeriesRatio untuk permintaan yang baik
hingga 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, Cloud Functions menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dipantau 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 secara eksplisit
mengukur latensi semua eksekusi atau hanya eksekusi yang berhasil.
Anda mengekspresikan SLI latensi berbasis permintaan menggunakan
struktur DistributionCut. Contoh SLO berikut memperkirakan bahwa 99% dari semua eksekusi Cloud Functions memiliki total latensi antara 0 dan 100 milidetik selama periode satu jam yang berkelanjutan:
{
"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": "98% requests under 100 ms"
}
App Engine
App Engine menyediakan platform serverless yang terkelola sepenuhnya untuk membangun dan menjalankan aplikasi. Anda memiliki dua pilihan, standar atau fleksibel. Untuk mengetahui informasi selengkapnya, baca Memilih lingkungan App Engine.
Untuk mengetahui informasi selengkapnya tentang App Engine, lihat referensi berikut:
- Dokumentasi untuk App Engine.
- Daftar jenis metrik
appengine.googleapis.com.
SLI Ketersediaan
App Engine menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dimonitor dan 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 mengekspresikan 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 dan gae_app serta jenis metrik http/server/response_latencies.
Anda dapat memfilter data menggunakan label metrik response_code untuk menghitung eksekusi "baik" dan "total".
Anda mengekspresikan SLI latensi berbasis permintaan untuk App Engine
dengan menggunakan struktur
DistributionCut. Contoh SLO berikut memperkirakan bahwa 99% dari semua permintaan akan memiliki total latensi antara 0 dan 100 milidetik selama periode satu jam yang berkelanjutan:
{
"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": "98% 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—Anthos 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 Ketersediaan
Istio menulis data metrik ke Cloud Monitoring menggunakan jenis metrik service/server/request_count dan salah satu jenis resource yang dimonitor berikut ini:
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 ke 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 ini:
Anda dapat memfilter data menggunakan label metrik response_code untuk menghitung label metrik "good" and "total" requests. You can also use thedestination_service_name` guna menghitung permintaan untuk layanan tertentu.
Anda menyatakan SLI latensi berbasis permintaan untuk layanan yang berjalan di
GKE yang dikelola oleh mesh layanan Istio
menggunakan struktur DistributionCut.
Contoh SLO berikut memperkirakan bahwa 99% dari semua permintaan ke layanan frontend
memiliki total latensi antara 0 dan 100 milidetik selama periode
satu jam yang 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": "98% requests under 100 ms"
}