Ringkasan metrik yang ditentukan pengguna

Metrik yang ditentukan pengguna (juga disebut metrik kustom) di Cloud Monitoring memungkinkan Anda menangkap telemetri sisi klien atau khusus aplikasi yang tidak dikumpulkan oleh metrik Google Cloud bawaan. Misalnya, Anda dapat mencatat jumlah rutinitas latar belakang yang dihasilkan aplikasi, lalu membuat diagram, membaca, dan memberi tahu metrik tersebut seperti metrik bawaan.

Cara mengumpulkan dan membaca metrik yang ditentukan pengguna

Untuk melengkapi kode dan mengumpulkan metrik yang ditentukan pengguna, sebaiknya gunakan OpenTelemetry, meskipun Anda juga dapat menggunakan Prometheus atau Cloud Monitoring API secara langsung. Untuk mendapatkan metrik dari entri log, buat metrik berbasis log di Cloud Logging. Anda dapat memantau penyerapan metrik di halaman Metrics Management di konsol Google Cloud .

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 mengilustrasikan 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 metrik dan jenis 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 menggunakan API untuk mendapatkan pemakaian CPU untuk instance virtual machine (VM) di project Google Cloud Anda.

Deskriptor metrik untuk metrik yang ditentukan pengguna

Setiap jenis metrik harus memiliki deskriptor 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 deskriptor metrik untuk Anda, menggunakan data metrik yang Anda tulis, atau Anda dapat membuat deskriptor metrik secara eksplisit, lalu menulis data metrik. Dalam kedua kasus tersebut, Anda harus memutuskan cara mengatur data metrik.

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 project Google Cloud dan berencana menulis data terhadap resource yang dimonitor global.

Contoh ini menjelaskan beberapa desain berbeda yang dapat Anda gunakan untuk metrik yang ditentukan 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 yang masing-masing memiliki satu kondisi dengan model data ini. Kebijakan pemberitahuan dapat mendukung beberapa kondisi, tetapi memiliki satu konfigurasi untuk saluran notifikasi.

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

  • Anda menggunakan satu metrik dan menggunakan label untuk menyimpan ID program. Misalnya, label mungkin 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 pemberitahuan saat tingkat panggilan untuk program A melebihi nilai minimum harus menggunakan filter yang hanya menyertakan titik data yang nilai labelnya adalah A.

    Salah satu keunggulan model ini adalah kemudahannya dalam menghitung rasio. Misalnya, Anda dapat menentukan berapa banyak dari 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 kedua program. Namun, Anda tidak dapat membuat kebijakan pemberitahuan yang memenuhi tujuan Anda karena data untuk kedua program tersebut 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 yang ditentukan 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 menjelaskan 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

Pada contoh sebelumnya, awalan custom.googleapis.com menunjukkan bahwa kedua metrik tersebut 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 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 yang ditentukan pengguna

Saat menulis data ke deret waktu, Anda harus menunjukkan dari mana data tersebut berasal. Untuk menentukan sumber data, pilih jenis resource yang dimonitor yang merepresentasikan asal data Anda, lalu gunakan jenis tersebut untuk mendeskripsikan asal spesifiknya. Resource yang dimonitor bukan bagian dari jenis metrik. Sebagai gantinya, deret waktu tempat Anda menulis data menyertakan referensi ke jenis metrik dan referensi ke resource yang dimonitor. Jenis metrik menjelaskan data, sedangkan resource yang dimonitor menjelaskan asal data.

Pertimbangkan resource yang dimonitor sebelum membuat deskriptor metrik. Jenis resource yang dimonitor yang Anda gunakan memengaruhi label yang perlu Anda sertakan 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 berbagai objek resource yang dimonitor disimpan dalam deret waktu yang berbeda.

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

Praktik yang umum adalah menggunakan objek resource yang dimonitor yang mewakili resource fisik tempat kode aplikasi Anda berjalan. Pendekatan ini memiliki beberapa manfaat:

  • Anda akan 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 lain dari resource yang sama.

Resource global dan 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, seperti aplikasi. Jenis generic_node berguna untuk menentukan resource mirip node seperti virtual machine. Kedua jenis generic_* memiliki beberapa label umum yang dapat Anda gunakan untuk menentukan objek resource yang 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 sebuah project, penggunaan objek resource global yang sama dapat menyebabkan tabrakan dan penimpaan data metrik Anda.

Metode API yang mendukung metrik yang ditentukan 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 Menggunakan dengan
metrik yang ditentukan pengguna		 Menggunakan dengan
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 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