Perilaku kebijakan pemberitahuan berbasis metrik

Kebijakan pemberitahuan berbasis metrik di Cloud Monitoring memungkinkan Anda memantau data deret waktu, membuat pemberitahuan, dan mengirim notifikasi. Anda dapat mengontrol kapan kebijakan pemberitahuan membuat pemberitahuan dan mengirim notifikasi dengan mengonfigurasi periode penyelarasan, periode pengujian ulang, dan aturan multi-kondisi. Memahami cara kebijakan pemberitahuan menangani data yang hilang, batas untuk pemberitahuan dan notifikasi, serta penundaan notifikasi akan membantu Anda meminimalkan positif palsu dan menyesuaikan responsivitas pemberitahuan.

Konten ini tidak berlaku untuk kebijakan pemberitahuan berbasis log. Untuk mengetahui informasi tentang kebijakan pemberitahuan berbasis log, lihat Memantau log Anda.

Periode penyelarasan dan periode pengujian ulang

Cloud Monitoring mengevaluasi periode penyelarasan dan jendela pengujian ulang saat menentukan apakah kondisi kebijakan pemberitahuan telah terpenuhi.

Periode penyelarasan

Sebelum data deret waktu dipantau oleh kebijakan pemberitahuan, data tersebut harus diregularisasi agar kebijakan pemberitahuan memiliki data dengan interval yang teratur untuk dievaluasi. Proses regularisasi disebut penyelarasan.

Penyelarasan melibatkan dua langkah:

  • Membagi deret waktu menjadi interval waktu reguler, yang juga disebut pengelompokan data. Intervalnya adalah periode penyelarasan.

  • Menghitung satu nilai untuk titik-titik dalam periode penyelarasan. Anda memilih cara penghitungan titik tunggal tersebut; Anda dapat menjumlahkan semua nilai, atau menghitung rata-ratanya, atau menggunakan nilai maksimum. Fungsi yang menggabungkan titik data disebut aligner. Hasil kombinasi ini disebut nilai yang diselaraskan.

    Untuk mengetahui informasi selengkapnya tentang penyelarasan, lihat Penyelarasan: regularisasi dalam deret.

Misalnya, jika periode penyelarasan adalah lima menit, pada pukul 13.00, periode penyelarasan berisi sampel yang diterima antara pukul 12.55 dan 13.00. Pada pukul 13.01, periode penyelarasan bergeser satu menit dan berisi sampel yang diterima antara pukul 12.56 dan 13.01.

Monitoring mengonfigurasi periode penyelarasan sebagai berikut:

Konsol Google Cloud

Anda mengonfigurasi periode penyelarasan dengan memilih nilai untuk kolom berikut di halaman Kondisi pemberitahuan:

  • Periode pengamatan: Menentukan rentang waktu yang akan dievaluasi.
  • Rolling window function: Menentukan fungsi matematika yang akan dilakukan pada jendela titik data.

Untuk mengetahui informasi selengkapnya tentang fungsi yang tersedia, lihat Aligner dalam referensi API. Beberapa fungsi penyelarasan menyelaraskan data dan mengonversinya dari satu jenis atau tipe metrik ke jenis atau tipe metrik lainnya. Untuk penjelasan mendetail, lihat Jenis, tipe, dan konversi.

API

Anda mengonfigurasi periode penyelarasan dengan menetapkan kolom aggregations.alignmentPeriod dan aggregations.perSeriesAligner dalam struktur MetricThreshold dan MetricAbsence.

Untuk mengetahui informasi selengkapnya tentang fungsi yang tersedia, lihat Aligner dalam referensi API. Beberapa fungsi penyelarasan menyelaraskan data dan mengonversinya dari satu jenis atau tipe metrik ke jenis atau tipe metrik lainnya. Untuk penjelasan mendetail, lihat Jenis, tipe, dan konversi.

Untuk mengilustrasikan efek periode penyelarasan pada kondisi dalam kebijakan pemberitahuan, pertimbangkan kondisi nilai minimum metrik yang memantau metrik dengan periode pengambilan sampel satu menit. Asumsikan bahwa periode penyelarasan ditetapkan ke lima menit dan penyelaras ditetapkan ke sum. Selain itu, asumsikan bahwa kondisi terpenuhi jika nilai deret waktu yang diselaraskan lebih besar dari dua selama setidaknya tiga menit, dan kondisi tersebut dievaluasi setiap menit. Dalam contoh ini, periode pengujian ulang, yang dijelaskan di bagian berikutnya, adalah tiga menit. Gambar berikut mengilustrasikan beberapa evaluasi berurutan dari kondisi:

Gambar yang mengilustrasikan efek periode penyelarasan pada jendela/durasi pengujian ulang.

Setiap baris dalam gambar mengilustrasikan satu evaluasi kondisi. Data deret waktu akan ditampilkan. Titik dalam periode penyelarasan ditampilkan dengan titik biru; titik yang lebih lama berwarna hitam. Setiap baris menampilkan nilai yang selaras dan apakah nilai ini lebih besar dari nilai minimum dua. Untuk baris berlabel start, nilai yang diselaraskan dihitung menjadi satu, yang kurang dari nilai minimum. Pada evaluasi berikutnya, jumlah sampel dalam periode penyelarasan adalah dua. Pada evaluasi ketiga, jumlahnya adalah tiga, dan karena nilai ini lebih besar dari nilai minimum, timer untuk periode pengujian ulang dimulai.

Periode pengujian ulang

Kondisi kebijakan pemberitahuan memiliki jendela pengujian ulang, yang mencegah kondisi terpenuhi karena satu pengukuran atau perkiraan. Misalnya, asumsikan bahwa periode pengujian ulang suatu kondisi ditetapkan ke 15 menit. Berikut ini menjelaskan perilaku kondisi berdasarkan jenisnya:

  • Kondisi nilai minimum metrik terpenuhi jika, untuk satu deret waktu, setiap pengukuran yang selaras dalam interval 15 menit melanggar nilai minimum.
  • Kondisi ketiadaan metrik terpenuhi jika tidak ada data yang masuk untuk deret waktu dalam interval 15 menit.
  • Kondisi perkiraan terpenuhi jika setiap perkiraan yang dihasilkan selama periode 15 menit memprediksi bahwa deret waktu akan melanggar nilai minimum dalam periode perkiraan.

Untuk kebijakan dengan satu kondisi, pemberitahuan akan dibuka dan notifikasi akan dikirim saat kondisi terpenuhi. Notifikasi ini tetap terbuka selama kondisi terus terpenuhi.

Konsol Google Cloud

Anda dapat mengonfigurasi periode pengujian ulang menggunakan kolom Retest window di langkah Configure alert trigger.

API

Anda mengonfigurasi periode pengujian ulang dengan menetapkan kolom bernama duration dalam struktur MetricThreshold dan MetricAbsence.

Gambar sebelumnya mengilustrasikan tiga evaluasi kondisi nilai minimum metrik. Pada waktu start + 2 minutes, nilai yang diselaraskan lebih besar dari nilai minimum; namun, kondisi tidak terpenuhi karena periode pengujian ulang ditetapkan ke tiga menit. Gambar berikut mengilustrasikan hasil untuk evaluasi kondisi berikutnya:

Gambar yang mengilustrasikan efek periode pengujian ulang.

Meskipun nilai yang diselaraskan lebih besar dari nilai minimum pada waktu start + 2 minutes, kondisi tidak terpenuhi hingga nilai yang diselaraskan lebih besar dari nilai minimum selama tiga menit. Peristiwa tersebut terjadi pada waktu start + 5 minutes.

Kondisi akan mereset periode pengujian ulang setiap kali pengukuran atau perkiraan tidak memenuhi kondisi. Oleh karena itu, tetapkan jendela pengujian ulang yang cukup lama untuk meminimalkan positif palsu, tetapi cukup singkat untuk memverifikasi bahwa pemberitahuan dibuka tepat waktu. Perilaku ini diilustrasikan dalam contoh berikut:

Contoh

Kebijakan pemberitahuan ini berisi satu kondisi nilai minimum metrik yang menentukan periode pengujian ulang selama lima menit.

Jika latensi respons HTTP lebih dari dua detik,
dan jika latensi lebih besar dari nilai minimum selama lima menit,
buka pemberitahuan dan kirim email ke tim dukungan Anda.

Urutan berikut menggambarkan pengaruh periode pengujian ulang terhadap evaluasi kondisi:

  1. Latensi HTTP kurang dari dua detik.
  2. Selama tiga menit berikutnya, latensi HTTP lebih besar dari dua detik.
  3. Dalam pengukuran berikutnya, latensi kurang dari dua detik, sehingga kondisi mereset periode pengujian ulang.

  4. Selama lima menit berikutnya, latensi HTTP lebih dari dua detik, sehingga kondisi terpenuhi.

    Karena kebijakan pemberitahuan memiliki satu kondisi, Monitoring akan mengirimkan notifikasi saat kondisi tersebut terpenuhi.

Praktik terbaik untuk menetapkan periode penyelarasan dan periode pengujian ulang

Untuk mengonfigurasi kebijakan pemberitahuan yang mengevaluasi dengan andal tanpa pemberitahuan palsu, konfigurasikan periode penyelarasan dan jendela pengujian ulang berdasarkan kasus penggunaan Anda.

Menetapkan periode penyelarasan

Periode penyelarasan menentukan jumlah sampel yang digabungkan oleh penyelarasan ke dalam pengukuran gabungan. Saat Anda menetapkan periode penyelarasan, pertimbangkan interval pengambilan sampel dan penundaan penyerapan metrik:

  • Periode penyelarasan minimum: Periode penyelarasan harus minimal 60 detik (1 menit) dan harus berupa kelipatan bilangan bulat dari 60 detik. Untuk memastikan bahwa setiap jendela penyelarasan menangkap data yang representatif, tetapkan periode penyelarasan setidaknya ke interval pengambilan sampel metrik, yang dibulatkan ke kelipatan 60 detik. Misalnya, untuk metrik yang mengambil sampel setiap 30 detik, tetapkan periode penyelarasan ke minimal 60 detik.

  • Penundaan penyerapan: Data metrik mengalami latensi pengumpulan dan penyerapan sebelum mencapai Monitoring. Saat mengevaluasi kebijakan pemberitahuan, Monitoring menggeser waktu evaluasi ke masa lalu untuk memperhitungkan perkiraan penundaan penyerapan setiap metrik—biasanya minimal 60 detik, dengan penundaan yang lebih singkat untuk metrik seperti cek uptime dan penundaan yang lebih lama untuk metrik latensi yang lebih tinggi seperti metrik cloud pihak ketiga atau berbasis log yang ditentukan pengguna. Namun, jika metrik eksternal atau pihak ketiga mengalami jeda penyerapan variabel yang melebihi penundaan bawaannya, pilih periode penyelarasan yang cukup luas untuk menangkap beberapa interval pengambilan sampel sehingga sampel yang tertunda tidak menghasilkan jendela penyelarasan yang kosong.

  • Periode penyelarasan maksimum: Untuk kondisi nilai minimum metrik, periode penyelarasan dapat berlangsung maksimal 25 jam. Untuk kondisi ketiadaan metrik, jumlah periode penyelarasan dan periode pengujian ulang tidak boleh melebihi 25 jam. Jika Anda perlu mengevaluasi tren historis selama periode lihat balik yang lebih lama dari 25 jam (hingga 2 tahun), gunakan PromQL. Aturan pemberitahuan PromQL yang melihat ke belakang lebih dari 25 jam memerlukan periode pengujian ulang (duration) menjadi nol, tidak mendukung metrik kustom atau metrik berbasis log, dan menerapkan interval evaluasi minimum yang meningkat seiring durasi lihat balik:

    • 25 jam 10 menit hingga 8 hari: 5 menit
    • 8 hari hingga 16 hari: 1 jam
    • 16 hari hingga 32 hari: 2 jam
    • 32 hari hingga 93 hari: 6 jam
    • 93 hari hingga 2 tahun: 12 jam

    Untuk mengetahui informasi selengkapnya, lihat Menggunakan PromQL untuk membuat kebijakan pemberitahuan.

Menetapkan periode pengujian ulang

Periode pengujian ulang (duration) menentukan durasi deret waktu harus terus-menerus melanggar nilai minimum kondisi sebelum Monitoring membuka pemberitahuan:

  • Responsivitas: Untuk kondisi nilai minimum metrik, menyetel periode pengujian ulang ke nol (ditampilkan di konsol Google Cloud sebagai No retest) akan menyebabkan pemberitahuan terbuka saat satu pengukuran yang selaras melanggar nilai minimum. Untuk kondisi ketiadaan metrik, data harus tidak ada selama seluruh periode pengujian ulang sebelum kondisi terpenuhi.

  • Hindari pemberitahuan palsu: Untuk menghindari pemberitahuan palsu yang disebabkan oleh lonjakan sementara, jitter evaluasi, atau varians pengumpulan metrik, tetapkan periode pengujian ulang ke setidaknya 180 detik (3 menit). Menetapkan periode pengujian ulang ke nol akan membuka pemberitahuan pada satu titik anomali.

Kondisi kebijakan pemberitahuan dievaluasi pada frekuensi tetap, kecuali jika Anda menggunakan PromQL. Untuk PromQL, frekuensi evaluasi dapat bervariasi berdasarkan durasi lihat balik kueri.

Kebijakan dengan beberapa kondisi

Kebijakan pemberitahuan dapat berisi hingga 6 kondisi.

Jika Anda menggunakan Cloud Monitoring API atau jika kebijakan pemberitahuan Anda memiliki beberapa kondisi, Anda harus menentukan kapan pemberitahuan dibuka. Untuk mengonfigurasi cara menggabungkan beberapa kondisi, lakukan salah satu hal berikut:

Konsol Google Cloud

Anda mengonfigurasi opsi penggabung di langkah Multi-condition trigger.

API

Anda mengonfigurasi opsi penggabung dengan kolom combiner dari struktur AlertPolicy.

Tabel ini mencantumkan setelan di konsol Google Cloud , nilai yang setara di Cloud Monitoring API, dan deskripsi setiap setelan:

Google Cloud console
Nilai pemicu kebijakan		 Nilai penggabung
Cloud Monitoring API		 Arti
Salah satu kondisi terpenuhi OR Pemberitahuan akan dibuka jika ada resource yang menyebabkan salah satu kondisi terpenuhi.
Semua kondisi terpenuhi
bahkan untuk resource
yang berbeda untuk setiap kondisi
(default)		 AND Pemberitahuan dibuka untuk setiap kondisi yang terpenuhi saat semua kondisi terpenuhi, meskipun resource yang berbeda menyebabkan kondisi tersebut terpenuhi.
Semua kondisi terpenuhi AND_WITH_MATCHING_RESOURCE Pemberitahuan dibuka untuk setiap kondisi yang terpenuhi saat semua kondisi terpenuhi, hanya jika resource yang sama menyebabkan setiap kondisi terpenuhi. Setelan ini adalah pilihan penggabungan yang paling ketat.

Dalam konteks ini, istilah terpenuhi berarti konfigurasi kondisi dievaluasi sebagai true. Misalnya, jika konfigurasinya adalah Any time series is greater than 10 for 5 minutes, maka saat pernyataan ini bernilai true, kondisi terpenuhi.

Contoh

Pertimbangkan project Google Cloud yang berisi dua instance VM, vm1 dan vm2. Selain itu, asumsikan bahwa Anda membuat kebijakan pemberitahuan dengan 2 kondisi:

  • Kondisi bernama CPU usage is too high memantau penggunaan CPU instance. Kondisi ini terpenuhi jika penggunaan CPU instance mana pun lebih besar dari 100 md/dtk selama 1 menit.
  • Kondisi bernama Excessive utilization memantau pemakaian CPU instance. Kondisi ini terpenuhi jika pemakaian CPU instance mana pun lebih besar dari 60% selama 1 menit.

Awalnya, asumsikan bahwa kedua kondisi bernilai false.

Selanjutnya, asumsikan bahwa penggunaan CPU vm1 melebihi 100 md/dtk selama 1 menit. Karena penggunaan CPU lebih besar dari nilai minimum selama satu menit, kondisi CPU usage is too high terpenuhi. Jika kondisi digabungkan dengan Any condition is met, pemberitahuan akan dibuat karena kondisi terpenuhi. Jika kondisi digabungkan dengan Semua kondisi terpenuhi atau Semua kondisi terpenuhi bahkan untuk resource yang berbeda untuk setiap kondisi, maka pemberitahuan tidak akan dibuat. Pilihan penggabung ini mengharuskan kedua kondisi terpenuhi.

Selanjutnya, asumsikan bahwa penggunaan CPU vm1 tetap lebih besar dari 100 md/dtk dan pemanfaatan CPU vm2 melebihi 60% selama 1 menit. Hasilnya adalah kedua kondisi terpenuhi. Berikut ini menjelaskan apa yang terjadi berdasarkan cara kondisi digabungkan:

  • Kondisi apa pun terpenuhi: Pemberitahuan dibuat saat resource menyebabkan kondisi terpenuhi. Dalam contoh ini, vm2 menyebabkan kondisi Excessive utilization terpenuhi.

    Jika vm2 menyebabkan kondisi CPU usage is too high terpenuhi, maka hal itu juga akan menyebabkan pemberitahuan dibuat. Pemberitahuan dibuat karena vm1 dan vm2 yang menyebabkan kondisi CPU usage is too high terpenuhi adalah peristiwa yang berbeda.

  • Semua kondisi terpenuhi, bahkan untuk resource yang berbeda untuk setiap kondisi: Pemberitahuan dibuat karena kedua kondisi terpenuhi.

  • Semua kondisi terpenuhi: Pemberitahuan tidak dibuat karena penggabung ini mengharuskan resource yang sama menyebabkan semua kondisi terpenuhi. Dalam contoh ini, tidak ada pemberitahuan yang dibuat karena vm1 menyebabkan CPU usage is too high terpenuhi, sedangkan vm2 menyebabkan Excessive utilization terpenuhi.

Data metrik parsial

Saat data deret waktu berhenti masuk atau saat data tertunda, Monitoring mengklasifikasikan data sebagai hilang. Data yang tidak ada dapat mencegah penutupan pemberitahuan. Penundaan kedatangan data dari penyedia cloud pihak ketiga dapat mencapai 30 menit, dengan penundaan 5-15 menit yang paling umum. Penundaan yang lama—lebih lama dari periode pengujian ulang—dapat menyebabkan kondisi memasuki status "tidak diketahui". Saat data akhirnya tiba, Monitoring mungkin telah kehilangan beberapa histori terbaru dari kondisi tersebut. Pemeriksaan data deret waktu di kemudian hari mungkin tidak akan mengungkapkan masalah ini karena tidak ada bukti penundaan setelah data tiba.

Konsol Google Cloud

Anda dapat mengonfigurasi cara Monitoring mengevaluasi kondisi nilai minimum metrik saat data berhenti masuk. Misalnya, saat pemberitahuan terbuka dan pengukuran yang diharapkan tidak muncul, apakah Anda ingin Monitoring membiarkan pemberitahuan tetap terbuka atau segera menutupnya? Demikian pula, saat data berhenti masuk dan tidak ada pemberitahuan yang terbuka, apakah Anda ingin pemberitahuan dibuka? Terakhir, berapa lama pemberitahuan harus tetap terbuka setelah data berhenti masuk?

Ada dua kolom yang dapat dikonfigurasi yang menentukan cara Monitoring mengevaluasi kondisi nilai minimum metrik saat data berhenti masuk:

  • Untuk mengonfigurasi cara Monitoring menentukan nilai pengganti untuk data yang tidak ada, gunakan kolom Evaluation of missing data yang Anda tetapkan di langkah Condition trigger. Kolom ini dinonaktifkan jika periode pengujian ulang ditetapkan ke Tidak ada pengujian ulang.

    Jendela pengujian ulang adalah kolom yang disebut durasi di Cloud Monitoring API.

  • Untuk mengonfigurasi durasi tunggu Monitoring sebelum menutup pemberitahuan terbuka setelah data berhenti masuk, gunakan kolom Alert autoclose duration. Anda menetapkan durasi penutupan otomatis di langkah Notification. Durasi penutupan otomatis default adalah tujuh hari.

Berikut ini penjelasan berbagai opsi untuk kolom data yang tidak ada:

Kolom "Evaluasi data yang tidak ada" diGoogle Cloud konsol
 Ringkasan Detail
Data tidak ada kosong Notifikasi yang terbuka akan tetap terbuka.
Notifikasi baru tidak dibuka.

Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti masuk. Jika pemberitahuan terbuka untuk kondisi ini, pemberitahuan akan tetap terbuka. Saat pemberitahuan terbuka dan tidak ada data yang masuk, timer penutupan otomatis akan dimulai setelah penundaan minimal 15 menit. Jika timer berakhir, pemberitahuan akan ditutup.

Untuk kondisi yang tidak terpenuhi, kondisi tersebut akan terus tidak terpenuhi saat data berhenti masuk.
Titik data yang tidak ada diperlakukan sebagai nilai yang melanggar kondisi kebijakan Notifikasi yang terbuka akan tetap terbuka.
Notifikasi baru dapat dibuka.

Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti masuk. Jika pemberitahuan terbuka untuk kondisi ini, pemberitahuan akan tetap terbuka. Jika pemberitahuan terbuka dan tidak ada data yang masuk selama durasi tutup otomatis ditambah 24 jam, pemberitahuan akan ditutup.

Untuk kondisi yang tidak terpenuhi, setelan ini menyebabkan kondisi nilai minimum metrik berperilaku seperti metric-absence condition. Jika data tidak masuk dalam waktu yang ditentukan oleh periode pengujian ulang, kondisi akan dievaluasi sebagai terpenuhi. Untuk kebijakan pemberitahuan dengan satu kondisi, kondisi yang terpenuhi akan menyebabkan pemberitahuan dibuka.
Titik data yang tidak ada diperlakukan sebagai nilai yang tidak melanggar kondisi kebijakan Notifikasi terbuka ditutup.
Notifikasi baru tidak dibuka.

Untuk kondisi yang terpenuhi, kondisi tersebut akan berhenti terpenuhi saat data berhenti masuk. Jika pemberitahuan terbuka untuk kondisi ini, pemberitahuan akan ditutup.

Untuk kondisi yang tidak terpenuhi, kondisi tersebut akan terus tidak terpenuhi saat data berhenti masuk.

API

Anda dapat mengonfigurasi cara Monitoring mengevaluasi kondisi nilai minimum metrik saat data berhenti masuk. Misalnya, saat pemberitahuan terbuka dan pengukuran yang diharapkan tidak muncul, apakah Anda ingin Monitoring membiarkan pemberitahuan tetap terbuka atau segera menutupnya? Demikian pula, saat data berhenti masuk dan tidak ada pemberitahuan yang terbuka, apakah Anda ingin pemberitahuan dibuka? Terakhir, berapa lama pemberitahuan harus tetap terbuka setelah data berhenti masuk?

Ada dua kolom yang dapat dikonfigurasi yang menentukan cara Monitoring mengevaluasi kondisi nilai minimum metrik saat data berhenti masuk:

  • Untuk mengonfigurasi cara Monitoring menentukan nilai pengganti untuk data yang hilang, gunakan kolom evaluationMissingData dari struktur MetricThreshold. Kolom ini diabaikan jika kolom duration bernilai nol.

  • Untuk mengonfigurasi berapa lama Monitoring menunggu sebelum menutup pemberitahuan terbuka setelah data berhenti masuk, gunakan kolom autoClose dalam struktur AlertStrategy.

Berikut ini penjelasan berbagai opsi untuk kolom data yang tidak ada:

Kolom API
evaluationMissingData		 Ringkasan Detail
EVALUATION_MISSING_DATA_UNSPECIFIED Notifikasi yang terbuka akan tetap terbuka.
Notifikasi baru tidak dibuka.

Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti masuk. Jika pemberitahuan terbuka untuk kondisi ini, pemberitahuan akan tetap terbuka. Saat pemberitahuan terbuka dan tidak ada data yang masuk, timer penutupan otomatis akan dimulai setelah penundaan setidaknya 15 menit. Jika timer berakhir, pemberitahuan akan ditutup.

Untuk kondisi yang tidak terpenuhi, kondisi tersebut akan terus tidak terpenuhi saat data berhenti masuk.
EVALUATION_MISSING_DATA_ACTIVE Notifikasi yang terbuka akan tetap terbuka.
Notifikasi baru dapat dibuka.

Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti masuk. Jika pemberitahuan terbuka untuk kondisi ini, pemberitahuan akan tetap terbuka. Jika pemberitahuan terbuka dan tidak ada data yang masuk selama durasi penutupan otomatis ditambah 24 jam, pemberitahuan akan ditutup.

Untuk kondisi yang tidak terpenuhi, setelan ini menyebabkan kondisi nilai minimum metrik berperilaku seperti metric-absence condition. Jika data tidak masuk dalam waktu yang ditentukan oleh kolom `duration`, kondisi tersebut akan dievaluasi sebagai terpenuhi. Untuk kebijakan pemberitahuan dengan satu kondisi, kondisi yang terpenuhi akan menyebabkan pemberitahuan dibuka.
EVALUATION_MISSING_DATA_INACTIVE Notifikasi terbuka ditutup.
Notifikasi baru tidak dibuka.

Untuk kondisi yang terpenuhi, kondisi tersebut akan berhenti terpenuhi saat data berhenti masuk. Jika pemberitahuan terbuka untuk kondisi ini, pemberitahuan akan ditutup.

Untuk kondisi yang tidak terpenuhi, kondisi tersebut akan terus tidak terpenuhi saat data berhenti masuk.

Evaluasi data yang tidak ada di seluruh siklus proses workload

Dalam kondisi nilai minimum metrik dan Monitoring Query Language, Anda dapat mengonfigurasi cara Monitoring mengevaluasi data yang tidak ada saat deret waktu berhenti melaporkan. Untuk mengonfigurasi evaluasi data yang tidak ada, kondisi harus memiliki jendela pengujian ulang bukan nol (duration). Kondisi PromQL tidak mendukung setelan evaluasi data yang tidak ada; sebagai gantinya, Monitoring menutup pemberitahuan PromQL yang terbuka setelah data tidak ada selama dua interval evaluasi ditambah masa tenggang.

Jika kondisi mengevaluasi data yang tidak ada dengan setelan default Missing data empty (EVALUATION_MISSING_DATA_NO_OP atau EVALUATION_MISSING_DATA_UNSPECIFIED), pemberitahuan yang telah dibuka akan tetap terbuka saat data metrik berhenti masuk. Misalnya, jika tugas atau container sementara mengalami lonjakan berkelanjutan yang memicu pemberitahuan, lalu workload dihentikan, pemberitahuan akan tetap aktif hingga durasi penutupan otomatis (default 7 hari) berakhir karena tidak ada titik data berikutnya yang masuk untuk menunjukkan bahwa metrik telah pulih di bawah nilai minimum.

Untuk menyelaraskan perilaku kebijakan pemberitahuan dengan siklus proses aplikasi Anda, pilih setelan evaluasi data yang tidak ada dan durasi penutupan otomatis berdasarkan jenis workload berikut:

Jenis workload Setelan data tidak ada yang direkomendasikan Durasi penutupan otomatis yang direkomendasikan Perilaku dan alasan siklus proses
Daemon dan infrastruktur berkelanjutan
(VM Compute Engine, instance Cloud SQL, node GKE)		 Data yang tidak ada kosong (EVALUATION_MISSING_DATA_NO_OP) atau Nilai yang melanggar kondisi (EVALUATION_MISSING_DATA_ACTIVE) Default (7 hari) atau 24 jam Infrastruktur berkelanjutan harus memancarkan telemetri metrik tanpa gangguan. Jika telemetri berhenti saat pemberitahuan terbuka, mempertahankan pemberitahuan terbuka akan memastikan bahwa partisi jaringan, error VM, atau kegagalan daemon menerima perhatian operator, bukan ditutup secara otomatis.
Workload sementara dan layanan penskalaan otomatis
(Pod GKE, tugas dan revisi Cloud Run, Cloud Tasks, worker Batch)		 Nilai yang tidak melanggar kondisi (EVALUATION_MISSING_DATA_INACTIVE) 30 menit hingga 2 jam Pod sementara dan container serverless dihentikan atau diskalakan ke nol setelah menyelesaikan pekerjaan. Menetapkan data yang tidak ada ke tidak aktif akan memastikan bahwa saat container sementara menghilang, kondisi akan berhenti dievaluasi sebagai dilanggar dan pemberitahuan akan ditutup. Mempersingkat durasi penutupan otomatis akan mencegah insiden sementara bertahan selama berhari-hari.
Workload berkala dan terjadwal
(Kueri batch harian, cron job per jam, analisis hari kalender)		 Nilai yang tidak melanggar kondisi (EVALUATION_MISSING_DATA_INACTIVE) 30 menit hingga 2 jam Workload batch berkala hanya melaporkan metrik selama eksekusi aktif. Karena durasi tutup otomatis diukur dari saat telemetri berhenti masuk, penggunaan EVALUATION_MISSING_DATA_INACTIVE dan durasi tutup otomatis yang dipersingkat (setidaknya 30 menit) akan mencegah pemberitahuan eksekusi tunggal bertahan di seluruh hari kalender.

Anda dapat meminimalkan masalah akibat data yang tidak ada dengan melakukan salah satu tindakan berikut:

  • Hubungi penyedia cloud pihak ketiga Anda untuk mengidentifikasi cara mengurangi latensi pengumpulan metrik.
  • Gunakan periode pengujian ulang yang lebih lama dalam kondisi Anda. Menggunakan periode pengujian ulang yang lebih lama memiliki kelemahan, yaitu membuat kebijakan pemberitahuan Anda menjadi kurang responsif.

  • Pilih metrik yang memiliki penundaan pengumpulan lebih rendah:

    • Metrik agen Monitoring, terutama saat agen berjalan di instance VM di cloud pihak ketiga.
    • Metrik kustom, saat Anda menulis datanya langsung ke Monitoring.
    • Metrik berbasis log, jika pengumpulan entri log tidak tertunda.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan Agen Operasional, Ringkasan metrik yang ditentukan pengguna, dan metrik berbasis log.

Kapan Monitoring mengirimkan notifikasi dan membuat pemberitahuan

Cloud Monitoring mengirimkan notifikasi saat deret waktu menyebabkan kondisi terpenuhi. Notifikasi dikirim ke semua saluran notifikasi. Anda tidak dapat membatasi notifikasi ke saluran tertentu atau ke subset saluran kebijakan Anda.

Jika Anda mengonfigurasi notifikasi berulang, notifikasi yang sama akan dikirim ulang ke saluran notifikasi tertentu untuk kebijakan pemberitahuan Anda.

Anda mungkin menerima beberapa notifikasi unik terkait satu kebijakan pemberitahuan jika salah satu hal berikut terjadi:

  • Suatu kondisi memantau beberapa deret waktu.

  • Kebijakan berisi beberapa kondisi. Dalam hal ini, notifikasi yang Anda terima bergantung pada nilai pemicu multi-kondisi kebijakan pemberitahuan:

    • Semua kondisi terpenuhi: Jika semua kondisi terpenuhi, untuk setiap deret waktu yang menyebabkan kondisi terpenuhi, kebijakan pemberitahuan akan mengirimkan notifikasi dan membuat pemberitahuan.

      Anda tidak dapat mengonfigurasi Cloud Monitoring untuk membuat hanya satu pemberitahuan dan mengirim hanya satu notifikasi jika kebijakan pemberitahuan berisi beberapa kondisi.

    • Setiap kondisi terpenuhi: Kebijakan pemberitahuan mengirimkan notifikasi saat deret waktu menyebabkan kondisi terpenuhi.

    Untuk mengetahui informasi selengkapnya, lihat Kebijakan dengan beberapa kondisi.

Kebijakan pemberitahuan yang dibuat menggunakan Cloud Monitoring API juga memberi tahu Anda saat kondisi terpenuhi dan saat kondisi berhenti terpenuhi. Kebijakan pemberitahuan yang dibuat menggunakan konsol Google Cloud tidak mengirimkan notifikasi saat kondisi berhenti terpenuhi, kecuali jika Anda telah mengaktifkan perilaku tersebut.

Saat Monitoring tidak mengirimkan notifikasi atau membuat pemberitahuan

Dalam situasi berikut, Monitoring tidak membuat pemberitahuan atau mengirim notifikasi saat kondisi kebijakan pemberitahuan terpenuhi:

  • Kebijakan pemberitahuan dinonaktifkan.
  • Kebijakan pemberitahuan ditunda.
  • Monitoring telah mencapai batas jumlah maksimum pemberitahuan terbuka.

Kebijakan pemberitahuan yang dinonaktifkan

Monitoring tidak membuat pemberitahuan atau mengirim notifikasi untuk kebijakan pemberitahuan yang dinonaktifkan. Namun, Monitoring terus mengevaluasi kondisi kebijakan pemberitahuan yang dinonaktifkan.

Saat Anda mengaktifkan kebijakan yang dinonaktifkan, Monitoring akan mengevaluasi nilai semua kondisi selama periode pengujian ulang terbaru. Periode pengujian ulang terbaru mungkin mencakup data yang diambil sebelum, selama, dan setelah kebijakan diaktifkan. Kondisi kebijakan yang dinonaktifkan dapat segera dipenuhi setelah melanjutkan kebijakan, bahkan dengan periode pengujian ulang yang besar.

Misalnya, Anda memiliki kebijakan pemberitahuan yang memantau proses tertentu dan Anda menonaktifkan kebijakan ini. Minggu berikutnya, prosesnya menurun, dan karena kebijakan pemberitahuan dinonaktifkan, Anda tidak akan diberi tahu. Jika Anda memulai ulang proses dan segera mengaktifkan kebijakan pemberitahuan, Monitoring akan mengenali bahwa proses tersebut belum aktif selama lima menit terakhir dan membuka pemberitahuan.

Pemberitahuan yang terkait dengan kebijakan pemberitahuan yang dinonaktifkan akan tetap terbuka hingga durasi penutupan otomatis kebijakan berakhir.

Kebijakan pemberitahuan yang ditunda

Monitoring tidak mengirimkan notifikasi atau membuat pemberitahuan untuk kebijakan pemberitahuan yang disenyapkan. Sebaiknya tunda kebijakan pemberitahuan jika Anda ingin mencegah kebijakan pemberitahuan mengirimkan notifikasi hanya untuk interval singkat. Misalnya, sebelum melakukan pemeliharaan pada virtual machine (VM), Anda dapat membuat penundaan dan menambahkan kebijakan pemberitahuan yang memantau instance ke kriteria penundaan.

Saat Anda menunda kebijakan pemberitahuan, Monitoring akan menutup semua pemberitahuan terbuka yang terkait dengan kebijakan tersebut. Monitoring dapat membuka pemberitahuan baru setelah masa tunda berakhir. Untuk mengetahui informasinya, lihat Menunda notifikasi dan pemberitahuan.

Batas notifikasi dan pemberitahuan terbuka

Kebijakan pemberitahuan dapat berlaku untuk banyak resource, dan masalah yang memengaruhi semua resource dapat menyebabkan kebijakan pemberitahuan membuka pemberitahuan untuk setiap resource. Notifikasi dibuka untuk setiap deret waktu yang menyebabkan kondisi terpenuhi.

Untuk mencegah sistem kelebihan beban, jumlah pemberitahuan yang dapat dibuka secara bersamaan oleh satu kebijakan dibatasi hingga 1.000.

Misalnya, pertimbangkan kebijakan yang berlaku untuk 2.000 instance Compute Engine, dan setiap instance menyebabkan kondisi pemberitahuan terpenuhi. Monitoring membatasi jumlah pemberitahuan terbuka hingga 1.000. Kondisi lainnya yang terpenuhi akan diabaikan hingga beberapa pemberitahuan terbuka untuk kebijakan tersebut ditutup.

Sebagai akibat dari batas ini, satu saluran notifikasi dapat menerima hingga 1.000 notifikasi sekaligus. Jika kebijakan pemberitahuan Anda memiliki beberapa saluran notifikasi, batas ini berlaku untuk setiap saluran notifikasi secara independen.

Latensi

Latensi mengacu pada penundaan antara saat Monitoring mengambil sampel metrik dan saat titik data metrik terlihat sebagai data deret waktu. Latensi memengaruhi waktu pengiriman notifikasi. Misalnya, jika metrik yang dipantau memiliki latensi hingga 180 detik, Monitoring tidak akan membuat pemberitahuan hingga 180 detik setelah kondisi kebijakan pemberitahuan bernilai benar. Untuk mengetahui informasi selengkapnya, lihat Latensi data metrik.

Peristiwa dan setelan berikut berkontribusi pada latensi:

  • Penundaan pengumpulan metrik: Waktu yang diperlukan Monitoring untuk mengumpulkan nilai metrik. Untuk nilai Google Cloud , sebagian besar metrik tidak terlihat selama 60 detik setelah pengumpulan; namun, penundaan bergantung pada metrik. Komputasi kebijakan pemberitahuan memerlukan penundaan tambahan hingga 5 menit dan 30 detik. Untuk metrik AWS CloudWatch, penundaan visibilitas dapat berlangsung beberapa menit. Untuk cek uptime, waktu ini dapat mencapai rata-rata dua menit (dari akhir periode pengujian ulang).

  • Periode pengujian ulang: Periode yang dikonfigurasi untuk kondisi tersebut. Kondisi hanya terpenuhi jika kondisi tersebut benar di sepanjang jendela pengujian ulang. Misalnya, setelan periode pengujian ulang selama lima menit akan menyebabkan penundaan notifikasi setidaknya lima menit sejak peristiwa pertama kali terjadi.

  • Waktu kedatangan notifikasi: Saluran notifikasi, seperti email dan SMS, mungkin mengalami latensi jaringan atau latensi lainnya (tidak terkait dengan apa yang dikirimkan), terkadang mendekati menit. Di beberapa saluran—seperti SMS dan Slack—tidak ada jaminan bahwa pesan akan terkirim.

Langkah berikutnya