Halaman ini diterjemahkan oleh Cloud Translation API.

Layanan permintaan-respons

Layanan permintaan-respons adalah layanan yang secara eksplisit diminta pelanggan untuk melakukan beberapa pekerjaan dan menunggu hingga pekerjaan tersebut berhasil diselesaikan. Contoh layanan tersebut yang paling umum 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 mengetahui informasi selengkapnya tentang SLI ketersediaan dan latensi, lihat Konsep dalam pemantauan layanan.

Anda menyatakan SLI ketersediaan berbasis permintaan dengan menggunakan struktur TimeSeriesRatio untuk menyiapkan rasio permintaan yang baik terhadap total permintaan. Anda memutuskan cara memfilter metrik berdasarkan menggunakan label yang tersedia untuk mendapatkan penentuan "baik" atau "valid" yang Anda inginkan.

Anda menyatakan SLI latensi berbasis permintaan menggunakan struktur DistributionCut.

Cloud Endpoints

Cloud Endpoints adalah layanan untuk mengelola API. Anda dapat mengambil API yang ada dan mengeksposnya dengan autentikasi, kuota, dan pemantauan.

Endpoints 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 diawali dengan awalan serviceruntime.googleapis.com.

Untuk informasi selengkapnya, lihat referensi berikut:

Dokumentasi untuk Cloud Endpoints.
Daftar serviceruntime.googleapis.com jenis metrik.

SLI Ketersediaan

Cloud Endpoints menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dipantau api dan jenis metrik api/request_count service-runtime, yang dapat Anda filter menggunakan label metrik response_code untuk menghitung permintaan "baik" dan "total".

Anda menyatakan SLI ketersediaan berbasis permintaan dengan membuat struktur TimeSeriesRatio untuk permintaan yang berhasil dibandingkan 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 Latensi

Cloud Endpoints menggunakan jenis metrik utama berikut untuk mencatat latensi:

api/request_latencies: distribusi latensi dalam detik untuk permintaan non-streaming. Gunakan saat pengalaman pengguna secara keseluruhan menjadi prioritas utama.
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. Digunakan 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

Endpoints 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 dengan menggunakan struktur DistributionCut, seperti yang ditunjukkan dalam contoh berikut.

Contoh SLO berikut mengharapkan bahwa 99% dari semua permintaan dalam project berada di antara 0 dan 100 md dalam total latensi 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 mengharapkan 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 terkelola sepenuhnya untuk men-deploy dan menskalakan aplikasi dalam container secara cepat dan aman. Tujuannya adalah untuk menghilangkan kerumitan semua pengelolaan infrastruktur dengan merespons perubahan traffic dengan menaikkan dan menurunkan skala secara otomatis dari nol hampir secara instan dan hanya menagih Anda untuk resource yang Anda gunakan.

Untuk informasi tambahan tentang kemampuan pengamatan Cloud Run, lihat artikel berikut:

Dokumentasi untuk Cloud Run.
Daftar run.googleapis.com jenis metrik.

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_codeatau response_code_class untuk menghitung permintaan "baik" dan "total".

"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 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 adalah distribusi latensi permintaan dalam milidetik yang mencapai revisi. Anda dapat memfilter data dengan menggunakan label metrik response_codeatau response_code_class jika Anda perlu mengukur latensi semua permintaan atau hanya permintaan yang berhasil secara eksplisit.

Anda menyatakan SLI latensi berbasis permintaan menggunakan struktur DistributionCut. Contoh SLO berikut mengharapkan 99% permintaan berada di antara 0 dan 100 md dalam total latensi 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"
}

Cloud Run Functions

Cloud Run functions 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 melayani permintaan HTTP/S.

Untuk mengetahui informasi tentang kemampuan pengamatan fungsi Cloud Run, lihat artikel berikut:

Dokumentasi untuk Cloud Run Functions.
Daftar run.googleapis.com jenis metrik.

SLI Ketersediaan

Fungsi Cloud Run menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dipantau cloud_function dan jenis metrik function/execution_time. Anda dapat memfilter data dengan menggunakan label metrik status untuk menghitung eksekusi "baik" dan "total".

"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 Latensi

Untuk mengukur latensi, fungsi Cloud Run menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dipantau cloud_function dan jenis metrik function/execution_times. Data 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 menyatakan SLI latensi berbasis permintaan menggunakan struktur DistributionCut. Contoh SLO berikut mengharapkan bahwa 99% dari semua eksekusi fungsi Cloud Run memiliki total latensi antara 0 dan 100 md 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 membangun dan menjalankan aplikasi. Anda memiliki pilihan dua lingkungan, standar atau fleksibel; untuk mengetahui informasi selengkapnya, lihat Memilih lingkungan App Engine.

Untuk mengetahui informasi selengkapnya tentang App Engine, lihat referensi berikut:

Dokumentasi untuk App Engine.
Daftar appengine.googleapis.com jenis metrik.

SLI 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 Latensi

Untuk mengukur latensi, App Engine menulis data metrik ke Cloud Monitoring menggunakan jenis resource yang dipantau 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 dengan menggunakan struktur DistributionCut. Contoh SLO berikut mengharapkan bahwa 99% dari semua permintaan berada di antara 0 dan 100 md dalam total latensi 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 terkelola dan aman 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 memberikan 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:

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 Latensi

Untuk mengukur latensi, Istio menulis data metrik ke Cloud Monitoring menggunakan jenis metrik service/server/response_latencies dan salah satu jenis resource yang dipantau 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 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 mengharapkan 99% dari semua permintaan ke layanan frontend berada di antara 0 dan 100 md dalam total latensi 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"
}

Layanan permintaan-respons Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Cloud Endpoints

SLI Ketersediaan

SLI Latensi

Cloud Run

SLI Ketersediaan

SLI Latensi

Cloud Run Functions

SLI Ketersediaan

SLI Latensi

App Engine

SLI Ketersediaan

SLI Latensi

GKE dan Istio

SLI Ketersediaan

SLI Latensi

Layanan permintaan-respons