Praktik terbaik untuk kebijakan pemberitahuan MQL

Halaman ini berisi indeks praktik terbaik untuk pemberitahuan kebijakan dengan kondisi berbasis Bahasa Kueri Monitoring (MQL). Anda dapat menggunakan informasi yang dikumpulkan di sini sebagai referensi cepat terkait hal yang perlu diperhatikan saat mengonfigurasi kebijakan pemberitahuan dengan kondisi berbasis MQL.

Halaman ini tidak menjelaskan dasar-dasar cara menggunakan kueri MQL dalam kebijakan pemberitahuan. Jika Anda adalah pengguna baru, lihat Kebijakan pemberitahuan dengan MQL.

Evaluasi kebijakan pemberitahuan melibatkan beberapa layanan internal. Karena cara layanan ini berinteraksi dengan MQL, sebaiknya gunakan operasi MQL tertentu, bukan operasi lainnya. Misalnya, jika Anda menggunakan delta, bukan delta_gauge, notifikasi mungkin dipicu pada waktu yang salah.

Tabel berikut menampilkan daftar operasi yang harus dihindari dan operasi yang direkomendasikan untuk digunakan.

Hindari Direkomendasikan
adjacent_rate rate
adjacent_delta delta_gauge
delta delta_gauge
window sliding

Menggunakan pernyataan every 30s dengan kebijakan pemberitahuan

Kebijakan pemberitahuan mengevaluasi kondisinya setiap 30 detik. Rentang waktu ini disebut jendela output. Sebaiknya kondisi Anda menyertakan operasi every 30s eksplisit sebagai pengingat visual dari periode ini.

Misalnya, kueri MQL kebijakan pemberitahuan berikut menyertakan pernyataan every 30s eksplisit:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 30s

Jika Anda menyimpan kebijakan pemberitahuan dengan kueri MQL yang menggunakan nilai berbeda untuk operasi every, Cloud Monitoring akan tetap menggunakan nilai 30 detik saat kebijakan pemberitahuan aktif. Misalnya, kebijakan pemberitahuan dengan kueri berikut masih memiliki periode output 30 detik:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 90s

Meningkatkan efisiensi kueri

Kueri berjalan lambat saat memproses data dalam volume besar. Untuk meningkatkan efisiensi kueri, Anda dapat mencoba mengurangi jumlah data yang diproses oleh kueri. Bagian berikut menyediakan beberapa opsi untuk mengurangi volume data yang dievaluasi kueri Anda.

Menempatkan filter lebih awal di kueri

Jika Anda menempatkan filter di awal kueri, filter tersebut dapat memfilter data yang tidak diperlukan sebelum kueri menjalankan operasi pada data. Misalnya, pertimbangkan kueri berikut:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by [resource.zone], .sum
| filter zone = 'us-west1-b'
| condition val() > 5'GBy'

Kueri dapat berjalan lebih cepat jika Anda memindahkan operasi filter sebelum operasi group_by:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| filter zone = 'us-west1-b'
| group_by [resource.zone], .sum
| condition val() > 5'GBy'

Mengurangi jendela perataan kueri

Saat kueri menggunakan operasi align, jendela perataan yang lebih kecil akan menampilkan rentang waktu yang lebih singkat yang dievaluasi Cloud Monitoring untuk setiap titik dalam deret waktu. Dengan demikian, Anda dapat mencoba meningkatkan efisiensi kueri dengan mengurangi nilai operasi align. Misalnya, kueri berikut memiliki periode penyelarasan dua jam:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(2h)
| every 30s
| condition val() > 2'GBy'

Namun, jika hanya perlu melihat data untuk periode 1 jam, Anda dapat mengurangi periode perataan menjadi 1 jam:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(1h)
| every 30s
| condition val() > 2'GBy'

Untuk informasi selengkapnya, lihat Perataan.

Mengurangi periode durasi kebijakan pemberitahuan

Periode durasi kebijakan pemberitahuan mewakili jangka waktu saat setiap tindakan harus melanggar kondisi sebelum pemberitahuan dikirim. Jika Anda mengurangi periode durasi kebijakan pemberitahuan tanpa meningkatkan periode penyelarasan kueri, Cloud Monitoring memiliki lebih sedikit poin yang harus dievaluasi terkait kondisi kebijakan pemberitahuan Anda.

Untuk informasi selengkapnya, lihat Periode durasi.

Menetapkan nilai default ke metadata null

Jika nilai metadata null, kueri Anda mungkin memberikan hasil yang tidak diharapkan. Anda dapat menghindari hasil yang tidak diharapkan dengan menggunakan fungsi or_else untuk menetapkan nilai default ke metadata yang seharusnya memiliki nilai null.

Misalnya, Anda menjalankan kueri yang menggabungkan semua data bersama-sama:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Kueri memberikan hasil 10 MBy. Selanjutnya, jalankan kueri untuk memverifikasi cara distribusi 10 MBy di seluruh zona node:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Kueri distribusi menampilkan hasil berikut:

node_zone egress_byte_count
us-central1-f 7,3MBy
us-west1-b 2,5 MBy

Hasil ini menunjukkan total 9,8MBy bukan 10MBy yang diharapkan. Perbedaan ini dapat terjadi jika salah satu label metadata gabungan memiliki nilai null, seperti dalam set data berikut:

value nilai metadata
7,3MBy us-central1-f
2,5 MBy us-west1-b
0,2 MBy

Untuk menghindari masalah dari metadata null, Anda dapat menggabungkan referensi metadata dalam operasi or_else, yang memungkinkan Anda menentukan nilai default jika kolom metadata tidak memiliki nilai. Misalnya, kueri berikut menggunakan or_else untuk menetapkan nilai metadata no zone untuk setiap kolom metadata yang tidak memiliki nilai:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Kueri baru ini memberikan hasil berikut, yang berjumlah 10 MBy:

node_zone egress_byte_count
us-central1-f 7,3MBy
us-west1-b 2,5 MBy
tidak ada zona 0,2 MBy