Tentang rasio metrik

Dokumen ini membantu Anda memilih pendekatan terbaik untuk membuat diagram atau memantau rasio data metrik. Bagian 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 perataan atau rasio pengambilan sampel.

Rasio memungkinkan Anda mengubah data metrik menjadi bentuk yang berbeda, dan berpotensi lebih berguna. Misalnya, pertimbangkan jenis metrik yang menghitung jumlah respons HTTP menurut kode respons. Data metrik melaporkan jumlah error, tetapi bukan proporsi permintaan yang gagal. Namun, persyaratan performa sering kali ditentukan sebagai persentase, seperti "Tingkat error harus kurang dari 0,1%". Untuk menentukan tingkat error dengan 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 konsol Google Cloud . Konsol Google Cloud mencakup editor kode yang memberikan saran, deteksi error, dan dukungan lainnya untuk membuat kueri PromQL yang valid.

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

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

Batasan dengan rasio

Saat Anda mengonfigurasi rasio, batasan berikut berlaku:

  • Setelah penggabungan, 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 numerator dan denominator 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, danproject_id. Pilihan yang valid untuk pengelompokan penyebut bergantung pada pilihan untuk pembilang:

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

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

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

    Sebaiknya gunakan periode penyesuaian 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 numerator dan denominator 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 rasio, ALIGN_RATE, untuk mengonversi metrik DELTA menjadi metrik GAUGE. Untuk melihat contohnya, lihat Kebijakan pemberitahuan rasio pada penggunaan kuota kecepatan untuk satu batas.

  • Untuk rasio yang tidak ditentukan dengan PromQL, jenis resource yang dimonitor harus sama untuk numerator dan denominator.

    Misalnya, jika resource untuk metrik pembilang adalah instance Compute Engine, maka 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 perataan yang berbeda.

Misalnya, anggaplah 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 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:

  • Karena ada dua deret waktu yang berbeda yang mencatat peristiwa yang sama, ada dua nilai penghitung pokok yang menerapkan pengumpulan, dan nilai tersebut tidak diperbarui secara atomik.
  • Frekuensi pengambilan sampel mungkin berbeda. Jika deret waktu diselaraskan dengan periode yang sama, 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 jendela penyelarasan yang lebih panjang daripada 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 poin lebih signifikan jika jumlah poin 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, sebaiknya gunakan satu metrik saja, yang menyertakan setiap hitungan hanya sekali. 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.

Pemberitahuan palsu karena anomali perhitungan rasio

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

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

Langkah berikutnya