Ringkasan metrik yang ditentukan pengguna

Metrik yang ditentukan pengguna adalah semua metrik yang tidak ditentukan oleh Google Cloud. Hal ini mencakup metrik yang mungkin Anda tentukan dan mencakup 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, jumlah rutinitas latar belakang yang dihasilkan aplikasi Anda. Anda juga dapat membuat metrik berdasarkan isi entri log. Untuk mengetahui informasi tentang jenis metrik tersebut, lihat Ringkasan metrik berbasis log.

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

Anda dapat membuat metrik buatan pengguna dengan langsung menggunakan Cloud Monitoring API. 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 diinstrumentasikan dengan 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.

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

  • Artikel Membuat metrik buatan 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 bahasa pemrograman APIs Explorer, C#, Go, Java, Node.js, PHP, Python, dan Ruby.

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

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

  • Metrik daftar dan jenis resource menjelaskan cara mencantumkan dan memeriksa jenis metrik bawaan dan yang ditetapkan pengguna. Misalnya, Anda dapat menggunakan informasi dalam dokumen tersebut untuk mencantumkan semua deskripsi 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 mengetahui pemakaian CPU instance virtual machine (VM) di project Google Cloud Anda.

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

Deskripsi metrik untuk metrik yang ditentukan pengguna

Setiap jenis metrik harus memiliki deskripsi metrik yang menentukan cara pengaturan data metrik. Deskripsi 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, dengan menggunakan data metrik yang Anda tulis, atau Anda dapat secara eksplisit membuat deskriptor metrik, 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 tahu kapan program A dipanggil lebih dari 10 kali per menit dan kapan B program dipanggil lebih dari 5 kali per menit. Terakhir, asumsikan Anda memiliki satu project Google Cloud dan berencana untuk menulis data pada 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 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 tepat jika Anda tidak tertarik dengan kesamaan data antara aktivitas yang dipantau. Dalam contoh ini, aktivitasnya adalah kecepatan 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 insiden saat tingkat panggilan untuk program A melebihi nilai minimum harus menggunakan filter yang hanya menyertakan titik data yang nilai labelnya A.

    Salah satu keuntungan dari model ini adalah kemudahan penghitungan rasio. Misalnya, Anda dapat menentukan berapa banyak dari total yang disebabkan oleh panggilan ke A.

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

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

Untuk 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 di project Google 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 item yang Anda kumpulkan. Untuk mengetahui detail tentang cara yang direkomendasikan untuk menamai metrik, lihat Konvensi penamaan metrik. Berikut adalah contoh dari 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 merupakan metrik yang ditentukan pengguna. Kedua contoh tersebut ditujukan untuk metrik yang mengukur penggunaan CPU. Namun, keduanya menggunakan model organisasi yang berbeda. Jika Anda mengantisipasi adanya banyak metrik yang ditentukan pengguna, sebaiknya gunakan struktur penamaan hierarkis seperti yang digunakan oleh 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 dari 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 deskripsi metrik, kolom name menyimpan nama resource jenis metrik dan kolom type menyimpan string METRIC_TYPE.

Jenis resource yang dipantau untuk metrik yang ditentukan pengguna

Saat menulis data ke deret waktu, Anda harus menunjukkan asal data tersebut. Untuk menentukan sumber data, pilih jenis resource yang dimonitor yang mewakili asal data, lalu gunakan jenis resource tersebut untuk mendeskripsikan asal tertentu. Resource yang dipantau bukan bagian dari jenis metrik. Sebaliknya, deret waktu tempat Anda menulis data akan menyertakan referensi ke jenis metrik dan referensi ke resource yang dimonitor. Jenis metrik mendeskripsikan data, sedangkan resource yang dipantau menjelaskan asal data.

Pertimbangkan resource yang dimonitor 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 untuk menulis metrik terhadap resource VM Compute Engine, label resource akan menyertakan ID instance sehingga Anda tidak memerlukan label untuk ID instance di 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 dipantau berikut dengan metrik yang ditentukan pengguna:

Praktik umumnya adalah menggunakan objek resource yang dimonitor yang mewakili resource fisik tempat kode aplikasi Anda dijalankan. Pendekatan ini memiliki beberapa keuntungan:

  • Anda mendapatkan performa yang lebih baik dibandingkan dengan menggunakan jenis resource tunggal.
  • Anda menghindari data 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 resource yang sama.

global dan resource umum

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

Sebaliknya, jenis resource global hanya memiliki label project_id dan location. Jika Anda memiliki banyak sumber metrik dalam suatu project, penggunaan objek resource global yang sama dapat menyebabkan konflik dan penulisan data metrik yang berlebih.

Metode API yang mendukung metrik yang ditentukan pengguna

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

Metode Monitoring API Gunakan dengan
metrik yang ditentukan pengguna		 Gunakan 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 terkait 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 selanjutnya