Ringkasan metrik yang ditentukan pengguna

Metrik buatan pengguna adalah semua metrik yang tidak ditentukan oleh Google Cloud. Hal ini mencakup metrik yang mungkin Anda tentukan, dan metrik yang ditentukan oleh aplikasi pihak ketiga. Metrik yang ditentukan pengguna memungkinkan Anda merekam data khusus aplikasi atau data sistem sisi klien. Metrik bawaan yang dikumpulkan oleh Cloud Monitoring dapat memberi Anda informasi tentang latensi backend atau penggunaan disk, tetapi tidak dapat memberi tahu Anda, misalnya, berapa banyak rutin latar belakang yang dihasilkan aplikasi Anda.

Anda juga dapat membuat metrik yang didasarkan pada konten entri log. Metrik berbasis log adalah class metrik yang ditentukan pengguna, tetapi Anda harus membuatnya dari Cloud Logging. Untuk mengetahui informasi selengkapnya tentang metrik berbasis log, lihat Ringkasan metrik berbasis log.

Metrik buatan pengguna terkadang disebut metrik kustom atau metrik khusus aplikasi. Metrik ini memungkinkan Anda, atau aplikasi pihak ketiga, menentukan dan mengumpulkan informasi yang tidak dapat dilakukan oleh metrik Cloud Monitoring bawaan. Anda dapat merekam metrik tersebut menggunakan API yang disediakan oleh library untuk menginstrumentasi kode Anda, lalu mengirimkan metrik ke aplikasi backend seperti Cloud Monitoring.

Anda dapat membuat metrik yang ditentukan pengguna, kecuali metrik berbasis log, dengan menggunakan Cloud Monitoring API secara langsung. Namun, sebaiknya gunakan OpenTelemetry. Untuk mengetahui informasi tentang cara membuat metrik yang ditentukan pengguna, lihat dokumen berikut:

  • Mengumpulkan metrik dan trace OTLP menjelaskan cara menggunakan Agen Operasional dan penerima OpenTelemetry Protocol (OTLP) agen untuk mengumpulkan metrik dan trace dari aplikasi yang diinstrumentasi menggunakan OpenTelemetry dan berjalan di Compute Engine.

  • Google Cloud Managed Service for Prometheus menjelaskan cara mengumpulkan metrik Prometheus dari aplikasi yang berjalan di Google Kubernetes Engine dan Kubernetes.

  • Mengumpulkan metrik Prometheus menjelaskan cara menggunakan Agen Operasional untuk mengumpulkan metrik Prometheus dari aplikasi yang berjalan di Compute Engine.

  • Membuat metrik yang ditentukan pengguna dengan API menjelaskan cara membuat metrik menggunakan Cloud Monitoring API dan cara menambahkan data metrik ke metrik tersebut. Dokumen ini menggambarkan cara menggunakan Monitoring API dengan contoh menggunakan APIs Explorer, bahasa pemrograman C#, Go, Java, Node.js, PHP, Python, dan Ruby.

  • Membuat metrik kustom di Cloud Run menunjukkan cara menggunakan OpenTelemetry Collector sebagai agen file bantuan dalam deployment Cloud Run.

Sejauh menyangkut Cloud Monitoring, Anda dapat menggunakan metrik yang ditentukan pengguna seperti metrik bawaan. Anda dapat membuat diagram, menyetel pemberitahuan, membaca, dan memantaunya. Untuk mengetahui informasi tentang cara membaca data metrik, lihat dokumen berikut:

  • Mencantumkan jenis metrik dan resource menjelaskan cara mencantumkan dan memeriksa jenis metrik bawaan dan yang ditentukan pengguna. Misalnya, Anda dapat menggunakan informasi dalam dokumen tersebut untuk mencantumkan semua deskriptor metrik yang ditentukan pengguna dalam project Anda.
  • Mengambil data deret waktu menjelaskan cara mengambil data deret waktu dari metrik menggunakan Monitoring API. Misalnya, dokumen ini menjelaskan cara Anda dapat menggunakan API untuk mendapatkan penggunaan CPU untuk instance virtual machine (VM) di project Anda. Google Cloud

Konsol Google Cloud menyediakan halaman khusus untuk membantu Anda melihat penggunaan metrik yang ditentukan pengguna. Untuk mengetahui informasi tentang isi halaman ini, lihat Melihat dan mengelola penggunaan metrik.

Deskriptor metrik untuk metrik buatan pengguna

Setiap jenis metrik harus memiliki deskripsi metrik yang menentukan cara data metrik diatur. Deskriptor metrik juga menentukan label untuk metrik dan nama metrik. Misalnya, daftar metrik menampilkan deskriptor metrik untuk semua jenis metrik bawaan.

Cloud Monitoring dapat membuat deskripsi metrik untuk Anda, dengan menggunakan data metrik yang Anda tulis, atau Anda dapat membuat deskripsi metrik secara eksplisit, lalu menulis data metrik. Dalam kedua kasus tersebut, Anda harus memutuskan cara mengatur data metrik Anda.

Contoh desain

Misalkan Anda memiliki program yang berjalan di satu mesin, dan program ini memanggil program tambahan A dan B. Anda ingin menghitung seberapa sering program A dan B dipanggil. Anda juga ingin mengetahui kapan program A dipanggil lebih dari 10 kali per menit dan kapan program B dipanggil lebih dari 5 kali per menit. Terakhir, asumsikan bahwa Anda memiliki satu Google Cloud project dan Anda berencana menulis data terhadap resource yang dipantau global.

Contoh ini menjelaskan beberapa desain berbeda yang dapat Anda gunakan untuk metrik buatan pengguna:

  • Anda menggunakan dua metrik: Metric-type-A menghitung panggilan ke program A dan Metric-type-B menghitung panggilan ke program B. Dalam hal ini, Metric-type-A berisi 1 deret waktu, dan Metric-type-B berisi 1 deret waktu.

    Anda dapat membuat satu kebijakan pemberitahuan dengan dua kondisi, atau Anda dapat membuat dua kebijakan pemberitahuan, masing-masing dengan satu kondisi dengan mode data ini. Kebijakan pemberitahuan dapat mendukung beberapa kondisi, tetapi memiliki satu konfigurasi untuk saluran notifikasi.

    Model ini mungkin cocok jika Anda tidak tertarik dengan kesamaan data antara aktivitas yang dipantau. Dalam contoh ini, aktivitasnya adalah rasio panggilan ke program A dan B.

  • Anda menggunakan satu metrik dan menggunakan label untuk menyimpan ID program. Misalnya, label dapat menyimpan nilai A atau B. Monitoring membuat deret waktu untuk setiap kombinasi label yang unik. Oleh karena itu, ada deret waktu yang nilai labelnya adalah A dan deret waktu lain yang nilai labelnya adalah B.

    Seperti model sebelumnya, Anda dapat membuat satu kebijakan pemberitahuan atau dua kebijakan pemberitahuan. Namun, kondisi untuk kebijakan pemberitahuan lebih rumit. Kondisi yang menghasilkan insiden saat rasio panggilan untuk program A melampaui nilai minimum harus menggunakan filter yang hanya menyertakan titik data yang nilai labelnya adalah A.

    Salah satu keunggulan model ini adalah rasio yang mudah dihitung. Misalnya, Anda dapat menentukan berapa banyak total yang disebabkan oleh panggilan ke A.

  • Anda menggunakan satu metrik untuk menghitung jumlah panggilan, tetapi Anda tidak menggunakan label untuk mencatat program mana yang dipanggil. Dalam model ini, ada satu deret waktu yang menggabungkan data untuk dua program. Namun, Anda tidak dapat membuat kebijakan pemberitahuan yang memenuhi tujuan Anda karena data untuk dua program tidak dapat dipisahkan.

Dua desain pertama memungkinkan Anda memenuhi persyaratan analisis data; namun, desain terakhir tidak.

Untuk mengetahui informasi selengkapnya, lihat Membuat metrik yang ditentukan pengguna.

Nama metrik buatan pengguna

Saat membuat metrik yang ditentukan pengguna, Anda menentukan ID string yang mewakili jenis metrik. String ini harus unik di antara metrik yang ditentukan pengguna dalam projectGoogle Cloud Anda dan harus menggunakan awalan yang menandai metrik sebagai metrik yang ditentukan pengguna. Untuk Monitoring, awalan yang diizinkan adalah custom.googleapis.com/, workload.googleapis.com/, external.googleapis.com/user, dan external.googleapis.com/prometheus. Awalan diikuti dengan nama yang mendeskripsikan apa yang Anda kumpulkan. Untuk mengetahui detail tentang cara yang direkomendasikan untuk memberi nama metrik, lihat Konvensi penamaan metrik. Berikut adalah contoh dua jenis ID untuk jenis metrik:

    custom.googleapis.com/cpu_utilization
    custom.googleapis.com/instance/cpu/utilization

Dalam contoh sebelumnya, awalan custom.googleapis.com menunjukkan bahwa kedua metrik adalah metrik yang ditentukan pengguna. Kedua contoh tersebut adalah untuk metrik yang mengukur pemakaian CPU; namun, keduanya menggunakan model organisasi yang berbeda. Jika Anda memperkirakan akan memiliki banyak metrik yang ditentukan pengguna, sebaiknya gunakan struktur penamaan hierarkis seperti yang digunakan dalam contoh kedua.

Semua jenis metrik memiliki ID unik secara global yang disebut nama resource. Struktur nama resource untuk jenis metrik adalah:

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

dengan METRIC_TYPE adalah ID string jenis metrik. Jika contoh metrik sebelumnya dibuat di project my-project-id, nama resource untuk metrik ini adalah sebagai berikut:

    projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
    projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization

Nama atau jenis? Dalam deskriptor metrik, kolom name menyimpan nama resource jenis metrik dan kolom type menyimpan string METRIC_TYPE.

Jenis resource yang dimonitor untuk metrik buatan pengguna

Saat menulis data ke deret waktu, Anda harus menunjukkan asal data. Untuk menentukan sumber data, Anda memilih jenis resource yang dipantau yang menunjukkan asal data Anda, lalu menggunakannya untuk mendeskripsikan asal tertentu. Resource yang dimonitor bukan bagian dari jenis metrik. Sebagai gantinya, time series yang Anda tulis datanya menyertakan referensi ke jenis metrik dan referensi ke resource yang dipantau. Jenis metrik menjelaskan data, sedangkan resource yang dipantau menjelaskan asal data.

Pertimbangkan resource yang dipantau sebelum membuat deskriptor metrik. Jenis resource yang dipantau yang Anda gunakan memengaruhi label yang perlu disertakan dalam deskriptor metrik. Misalnya, resource VM Compute Engine berisi label untuk project ID, ID instance, dan zona instance. Oleh karena itu, jika Anda berencana menulis metrik terhadap resource VM Compute Engine, label resource akan menyertakan ID instance sehingga Anda tidak memerlukan label untuk ID instance dalam deskriptor metrik.

Setiap titik data metrik Anda harus dikaitkan dengan objek resource yang dipantau. Titik dari objek resource yang dipantau berbeda disimpan dalam deret waktu yang berbeda.

Anda harus menggunakan salah satu jenis resource yang dipantau berikut dengan metrik yang ditentukan pengguna:

Praktik umum adalah menggunakan objek resource yang dipantau yang merepresentasikan resource fisik tempat kode aplikasi Anda berjalan. Pendekatan ini memiliki beberapa keunggulan:

  • Anda mendapatkan performa yang lebih baik dibandingkan dengan menggunakan satu jenis resource.
  • Anda menghindari data yang tidak berurutan yang disebabkan oleh beberapa proses yang menulis ke deret waktu yang sama.
  • Anda dapat mengelompokkan data metrik yang ditentukan pengguna dengan data metrik lainnya dari sumber yang sama.

global dan resource umum

Jenis resource generic_task dan generic_node berguna dalam situasi ketika tidak ada jenis resource yang lebih spesifik yang sesuai. Jenis generic_task berguna untuk menentukan resource seperti tugas, misalnya aplikasi. Jenis generic_node berguna untuk menentukan resource seperti node, misalnya mesin virtual. Kedua jenis generic_* memiliki beberapa label umum yang dapat Anda gunakan untuk menentukan objek resource unik, sehingga memudahkan penggunaannya dalam filter metrik untuk agregasi dan pengurangan.

Sebaliknya, jenis resource global hanya memiliki label project_id. Jika Anda memiliki banyak sumber metrik dalam project, penggunaan objek resource global yang sama dapat menyebabkan tabrakan dan penimpaan data metrik Anda.

Metode API yang mendukung metrik buatan pengguna

Tabel berikut menunjukkan metode mana di Monitoring API yang mendukung metrik yang ditentukan pengguna dan metode mana yang mendukung metrik bawaan:

Metode Monitoring API Digunakan dengan
metrik buatan pengguna		 Menggunakan metrik bawaan
monitoredResourceDescriptors.get ya ya
monitoredResourceDescriptors.list ya ya
metricDescriptors.get ya ya
metricDescriptors.list ya ya
timeSeries.list ya ya
timeSeries.create ya
metricDescriptors.create ya
metricDescriptors.delete ya

Batas dan latensi

Untuk mengetahui batas yang terkait dengan metrik yang ditentukan pengguna dan retensi data, lihat Kuota dan batas.

Untuk menyimpan data metrik Anda di luar periode retensi, Anda harus menyalin data secara manual ke lokasi lain, seperti Cloud Storage atau BigQuery.

Untuk mengetahui informasi tentang latensi yang terkait dengan penulisan data ke metrik yang ditentukan pengguna, lihat Latensi data metrik.

Langkah berikutnya