Tentang rasio metrik

Dokumen ini membantu Anda memilih pendekatan terbaik untuk membuat diagram atau memantau rasio data metrik. Artikel ini juga mencakup link ke contoh, mengidentifikasi kapan Anda dapat menghitung rasio, dan menjelaskan anomali yang mungkin Anda lihat saat membuat diagram rasio dari dua metrik yang berbeda. Anomali ini disebabkan oleh perbedaan frekuensi sampling atau parameter 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 dengan kode respons. Data metrik melaporkan jumlah error, tetapi bukan proporsi permintaan yang gagal. Namun, persyaratan performa sering ditentukan dalam bentuk persentase, seperti "Tingkat error harus kurang dari 0,1%". Untuk menentukan tingkat error menggunakan data metrik, Anda harus menghitung rasio permintaan yang gagal dibandingkan dengan jumlah total permintaan.

Praktik terbaik

Untuk memantau atau membuat diagram rasio data metrik, sebaiknya gunakan Bahasa Kueri Monitoring (MQL). Anda dapat menggunakan MQL dengan Cloud Monitoring API dan dengan Konsol Google Cloud. Konsol Google Cloud dilengkapi editor kode yang memberikan saran, deteksi error, dan dukungan lain untuk membuat kueri MQL yang valid. Untuk mengetahui informasi selengkapnya dan contoh, lihat dokumen berikut:

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

Untuk membuat diagram rasio data metrik jika Anda tidak terbiasa dengan MQL, sebaiknya gunakan Konsol Google Cloud 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 akan berlaku:

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

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

    Pertimbangkan konfigurasi dengan 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:

    • Numerator yang dikelompokkan menurut label method: Gabungkan deret waktu penyebut menjadi satu deret waktu. Tidak ada pengelompokan lain yang menghasilkan label untuk deret waktu penyebut sebagai subset label untuk deret waktu pembilang.
    • Pembilang yang dikelompokkan menurut label quota_metric: Mengelompokkan penyebut menurut label tersebut atau menggabungkan semua deret waktu yang ada dalam penyebut menjadi satu deret waktu.
    • Numerator yang dikelompokkan menurut label quota_metric dan project_id: Mengelompokkan penyebut menurut kedua label, menurut satu label, atau menggabungkan denominator ke dalam 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.

    Misalnya, lihat contoh kebijakan pemberitahuan MQL.

  • Periode penyelarasan harus sama untuk pembilang dan penyebut saat mengonfigurasi diagram dengan menggunakan Konsol Google Cloud; tetapi, kolom ini bisa saja berbeda saat menggunakan Cloud Monitoring API.

    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 adalah jenis DOUBLE, penyebutnya juga harus berjenis DOUBLE.

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

  • Deret waktu yang disejajarkan untuk pembilang dan penyebut harus memiliki jenis metrik yang sama. Jika kedua metrik memiliki jenis yang berbeda, Anda harus menggunakan penyelaras untuk mengonversinya menjadi jenis yang sama.

    Pertimbangkan konfigurasi dengan metrik DELTA dipilih untuk pembilang dan metrik GAUGE dipilih untuk penyebut. Dalam situasi ini, gunakan penyelaras kecepatan, ALIGN_RATE, untuk mengonversi metrik DELTA menjadi metrik GAUGE. Sebagai contoh, lihat Kebijakan pemberitahuan rasio tentang penggunaan kuota kapasitas untuk satu batas.

  • Untuk rasio yang tidak ditentukan dengan MQL, jenis resource yang dimonitor 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, cara terbaik adalah menghitung rasio berdasarkan deret waktu yang dikumpulkan untuk satu jenis metrik, dengan menggunakan nilai label. Rasio yang dihitung dengan 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 dibandingkan total RPC. RPC yang gagal dihitung dalam deret waktu dari kedua jenis metrik. Oleh karena itu, ada kemungkinan bahwa, saat Anda menyelaraskan deret waktu, RPC yang gagal tidak akan muncul dalam interval perataan yang sama untuk kedua deret waktu. Perbedaan ini dapat terjadi karena beberapa alasan, termasuk:

  • Karena ada dua deret waktu berbeda yang merekam peristiwa yang sama, ada dua nilai penghitung dasar yang mengimplementasikan pengumpulan data tersebut, dan keduanya tidak diperbarui secara atomik.
  • Frekuensi sampling mungkin berbeda. Jika deret waktu diselaraskan dengan periode yang sama, jumlah untuk satu peristiwa dapat muncul dalam interval perataan yang berdekatan dalam deret waktu untuk metrik yang berbeda.

Perbedaan jumlah nilai dalam interval perataan 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 dapat memperoleh jumlah yang lebih besar melalui agregasi, baik dengan menggunakan periode perataan yang lebih panjang dari periode pengambilan sampel, atau dengan mengelompokkan data untuk label tertentu. Teknik ini meminimalkan efek perbedaan kecil pada jumlah titik pada interval tertentu. Artinya, selisih dua titik akan lebih signifikan jika jumlah titik yang diharapkan dalam sebuah interval adalah 3 daripada saat angka yang diharapkan adalah 300.

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

Jika Anda mendesain metrik kustom yang mungkin menghitung hal yang sama—seperti RPC yang menampilkan status error—dalam dua metrik berbeda, pertimbangkan satu metrik, yang menyertakan setiap jumlah hanya sekali. Misalnya, anggap Anda menghitung RPC dan ingin melacak rasio RPC yang gagal 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.

Langkah selanjutnya