Halaman ini diterjemahkan oleh Cloud Translation API.

Layanan permintaan-respons

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 menyediakan 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 artikel 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 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 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"
}