Ringkasan metrik yang ditentukan pengguna

Metrik yang ditentukan pengguna adalah semua metrik yang tidak ditentukan oleh Google Cloud. Metrik ini mencakup metrik yang mungkin Anda tentukan, dan mencakup metrik yang ditentukan aplikasi pihak ketiga. Metrik yang ditentukan pengguna memungkinkan Anda mengambil 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 yang didasarkan pada konten entri log. Metrik berbasis log adalah class metrik yang ditentukan pengguna, tetapi Anda harus membuatnya dari Cloud Logging. Untuk 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 mengambil metrik tersebut menggunakan API yang disediakan oleh library untuk menginstrumentasikan kode, lalu mengirim 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 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 Ops Agent 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 memetakan, menyetel pemberitahuan, membaca, dan memantaunya. Untuk 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 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 mendapatkan penggunaan CPU untuk 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, lihat Melihat dan mengelola penggunaan metrik.

Deskriptor metrik untuk metrik yang ditentukan pengguna

Setiap jenis metrik harus memiliki deskripsi metrik yang menentukan cara data metrik diatur. Deskripsi metrik juga menentukan label untuk metrik dan nama metrik. Misalnya, daftar metrik menampilkan deskripsi 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.

Contoh desain

Misalkan Anda memiliki program yang berjalan di satu komputer, 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 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 sesuai jika Anda tidak tertarik dengan kesamaan data antara aktivitas yang dipantau. Dalam contoh ini, aktivitas adalah frekuensi 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. Pemantauan membuat deret waktu untuk setiap kombinasi label 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 melebihi nilai minimum harus menggunakan filter yang hanya menyertakan titik data dengan nilai label A.

    Salah satu keunggulan model ini adalah mudahnya menghitung rasio. 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 kedua program. Namun, Anda tidak dapat membuat kebijakan pemberitahuan yang memenuhi tujuan karena data untuk dua program tidak dapat dipisahkan.

Dua desain pertama memungkinkan Anda memenuhi persyaratan analisis data; tetapi, 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 di project Google Cloud Anda dan harus menggunakan awalan yang menandai metrik sebagai metrik yang ditentukan pengguna. Untuk Pemantauan, 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 penggunaan CPU; tetapi, keduanya menggunakan model organisasi yang berbeda. Jika Anda memperkirakan akan memiliki banyak metrik yang ditentukan pengguna, sebaiknya Anda menggunakan struktur penamaan hierarkis seperti yang digunakan oleh 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 deskripsi 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 mewakili asal data, lalu menggunakannya untuk mendeskripsikan asal tertentu. 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 dipantau. Jenis metrik menjelaskan data, sedangkan resource yang dimonitor menjelaskan asal data.

Pertimbangkan resource yang dipantau sebelum membuat deskripsi metrik. Jenis resource yang dimonitor yang Anda gunakan memengaruhi label yang perlu disertakan dalam deskripsi 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 instance ID sehingga Anda tidak memerlukan label untuk instance ID dalam deskripsi metrik.

Setiap titik data metrik Anda harus dikaitkan dengan objek resource yang dipantau. Titik dari berbagai objek resource yang dipantau 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 mewakili resource fisik tempat kode aplikasi Anda berjalan. Pendekatan ini memiliki beberapa kelebihan:

  • 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 resource yang sama.

global dan resource umum

Jenis resource generic_task dan generic_node berguna dalam situasi saat 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 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 konflik dan menimpa 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 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 informasi tentang latensi yang terkait dengan penulisan data ke metrik yang ditentukan pengguna, lihat Latensi data metrik.

Langkah selanjutnya