Tentang rasio metrik

Dokumen ini membantu Anda memilih pendekatan terbaik untuk membuat diagram atau memantau rasio data metrik. Dokumen ini juga menyertakan link ke contoh, mengidentifikasi kapan Anda dapat menghitung rasio, dan menjelaskan anomali yang mungkin Anda lihat saat membuat diagram rasio dua metrik yang berbeda. Anomali ini disebabkan oleh perbedaan dalam parameter tingkat pengambilan sampel atau penyelarasan.

Rasio memungkinkan Anda mengubah data metrik ke dalam bentuk yang berbeda, dan berpotensi lebih berguna. Misalnya, pertimbangkan jenis metrik yang menghitung jumlah respons HTTP berdasarkan kode respons. Data metrik melaporkan jumlah error, tetapi tidak melaporkan proporsi permintaan yang gagal. Namun, persyaratan performa sering kali ditentukan sebagai persentase, seperti "Tingkat error harus kurang dari 0,1%". Untuk menentukan tingkat error menggunakan data metrik, Anda menghitung rasio permintaan yang gagal terhadap jumlah total permintaan.

Praktik terbaik

Untuk memantau atau membuat diagram rasio data metrik, sebaiknya gunakan PromQL. Anda dapat menggunakan PromQL dengan Cloud Monitoring API dan dengan Google Cloud konsol. konsol menyertakan editor kode yang memberikan saran, deteksi error, dan dukungan lainnya untuk membuat kueri PromQL yang valid . Google Cloud

Untuk membuat kebijakan pemberitahuan yang memantau rasio metrik saat Anda tidak terbiasa dengan PromQL, gunakan Cloud Monitoring API dan sertakan filter deret waktu. Untuk contohnya, lihat Rasio metrik.

Untuk membuat diagram rasio data metrik saat Anda tidak terbiasa dengan PromQL, sebaiknya gunakan Google Cloud konsol dan gunakan antarmuka berbasis menu. Untuk petunjuk mendetail, lihat, Membuat diagram rasio metrik dan Menambahkan diagram dan tabel ke dasbor kustom.

Batasan dengan rasio

Saat Anda mengonfigurasi rasio, batasan berikut berlaku:

  • Setelah agregasi, label dalam deret waktu penyebut harus sama dengan, atau merupakan subset dari, label dalam deret waktu pembilang.

    Sebaiknya pilih opsi agregasi sehingga setelah agregasi, deret waktu pembilang dan penyebut memiliki label yang sama.

    Pertimbangkan konfigurasi saat deret waktu pembilang memiliki label method, quota_metric, dan project_id. Deret waktu penyebut memiliki label limit_name, quota_metric, dan project_id. Pilihan yang valid untuk pengelompokan penyebut bergantung pada pilihan untuk pembilang:

    • Pembilang dikelompokkan berdasarkan label method: Gabungkan deret waktu penyebut ke dalam satu deret waktu. Tidak ada pengelompokan lain yang menghasilkan label untuk deret waktu penyebut sebagai subset dari label untuk deret waktu pembilang.
    • Pembilang dikelompokkan berdasarkan label quota_metric: Kelompokkan penyebut berdasarkan label tersebut atau gabungkan semua deret waktu dalam penyebut ke dalam satu deret waktu.
    • Pembilang dikelompokkan berdasarkan label quota_metric dan project_id: Kelompokkan penyebut berdasarkan kedua label, berdasarkan satu label, atau gabungkan deret waktu penyebut ke dalam satu deret waktu.

    Opsi agregasi penyebut yang valid selalu menghapus label limit_name dari deret waktu yang dikelompokkan karena label tersebut tidak ada dalam deret waktu pembilang.

  • Periode penyelarasan harus sama untuk pembilang dan penyebut saat mengonfigurasi diagram menggunakankonsol; namun, kolom ini dapat berbeda saat menggunakan Cloud Monitoring API. Google Cloud

    Sebaiknya gunakan periode penyelarasan yang sama untuk pembilang dan penyebut, terlepas dari alat yang Anda gunakan untuk membuat diagram.

  • Pembilang dan penyebut harus memiliki jenis nilai yang sama . Misalnya, jika pembilang berjenis DOUBLE, penyebut juga harus berjenis DOUBLE.

    Rasio mengharuskan metrik pembilang dan penyebut memiliki jenis nilai DOUBLE atau INT64.

  • Deret waktu yang diselaraskan untuk pembilang dan penyebut harus memiliki jenis metrik yang sama. Jika kedua metrik memiliki jenis yang berbeda, Anda harus menggunakan penyelarasan untuk mengonversinya ke jenis yang sama.

    Pertimbangkan konfigurasi saat metrik DELTA dipilih untuk pembilang dan metrik GAUGE dipilih untuk penyebut. Dalam situasi ini, gunakan penyelarasan tarif, ALIGN_RATE, untuk mengonversi metrik DELTA ke metrik GAUGE. Untuk contohnya, lihat Kebijakan pemberitahuan rasio tentang penggunaan kuota tarif untuk satu batas.

  • Untuk rasio yang tidak ditentukan dengan PromQL, jenis resource yang dipantau harus sama untuk pembilang dan penyebut.

    Misalnya, jika resource untuk metrik pembilang adalah instance Compute Engine, resource untuk metrik penyebut juga harus berupa instance Compute Engine.

Anomali karena ketidakcocokan pengambilan sampel dan penyelarasan

Secara umum, sebaiknya hitung rasio berdasarkan deret waktu yang dikumpulkan untuk satu jenis metrik, dengan menggunakan nilai label. Rasio yang dihitung dari dua jenis metrik yang berbeda dapat mengalami anomali karena periode pengambilan sampel dan periode penyelarasan yang berbeda.

Misalnya, Anda memiliki dua jenis metrik yang berbeda, jumlah total RPC dan jumlah error RPC, dan Anda ingin menghitung rasio RPC jumlah error terhadap total RPC. RPC yang tidak berhasil dihitung dalam deret waktu dari kedua jenis metrik. Oleh karena itu, ada kemungkinan bahwa, saat Anda menyelaraskan deret waktu, RPC yang tidak berhasil tidak muncul dalam interval penyelarasan yang sama untuk kedua deret waktu. Perbedaan ini dapat terjadi karena beberapa alasan, termasuk yang berikut:

  • Karena ada dua deret waktu yang berbeda yang mencatat peristiwa yang sama, ada dua nilai penghitung yang mendasarinya yang menerapkan koleksi, dan keduanya tidak diperbarui secara atomik.
  • Tingkat pengambilan sampel mungkin berbeda. Saat deret waktu diselaraskan ke periode umum, jumlah untuk satu peristiwa mungkin muncul dalam interval penyelarasan yang berdekatan dalam deret waktu untuk metrik yang berbeda.

Perbedaan jumlah nilai dalam interval penyelarasan yang sesuai dapat menyebabkan nilai rasio error/total yang tidak masuk akal seperti 1/0 atau 2/1.

Rasio angka yang lebih besar cenderung tidak menghasilkan nilai yang tidak masuk akal. Anda bisa mendapatkan angka yang lebih besar dengan agregasi, baik dengan menggunakan periode penyelarasan yang lebih lama dari periode pengambilan sampel, atau dengan mengelompokkan data untuk label tertentu. Teknik ini meminimalkan efek perbedaan kecil dalam jumlah titik dalam interval tertentu. Artinya, perbedaan dua titik lebih signifikan jika jumlah titik yang diharapkan dalam interval adalah 3 daripada jika jumlah yang diharapkan adalah 300.

Jika Anda menggunakan jenis metrik bawaan, Anda mungkin tidak punya pilihan selain menghitung rasio di seluruh jenis metrik untuk mendapatkan nilai yang Anda butuhkan.

Jika Anda mendesain metrik kustom yang mungkin menghitung hal yang sama—seperti RPC yang menampilkan status error—dalam dua metrik yang berbeda, pertimbangkan metrik tunggal, yang hanya menyertakan setiap hitungan satu kali. Misalnya, Anda menghitung RPC dan ingin melacak rasio RPC yang tidak berhasil terhadap semua RPC. Untuk mengatasi masalah ini, buat satu jenis metrik untuk menghitung RPC, dan gunakan label untuk mencatat status pemanggilan, termasuk status "OK". Kemudian, setiap nilai status, error, atau "OK", dicatat dengan memperbarui satu penghitung untuk kasus tersebut.

Insiden palsu karena anomali penghitungan rasio

Untuk menghindari insiden palsu karena error sementara atau data yang tidak ada, tetapkan durasi kueri PromQL Anda setidaknya dua kali interval evaluasi:

  • Google Cloud konsol: Tetapkan durasi di kolom Duration saat mengonfigurasi kondisi pemberitahuan.
  • Cloud Monitoring API atau Terraform: Tentukan durasi menggunakan kolom AlertPolicy.Condition.PrometheusQueryLanguageCondition.duration.

Langkah berikutnya