Perilaku kebijakan pemberitahuan berbasis metrik

Dokumen ini menjelaskan cara setelan periode penyelarasan dan durasi menentukan kapan suatu kondisi terpenuhi, cara kebijakan pemberitahuan menggabungkan beberapa kondisi, dan cara kebijakan pemberitahuan menggantikan titik data yang hilang. Bagian ini juga menjelaskan jumlah maksimum insiden terbuka untuk suatu kebijakan, jumlah notifikasi per insiden, dan apa yang menyebabkan penundaan notifikasi.

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

Setelan periode dan durasi perataan

Periode penyelarasan dan periode durasi adalah dua kolom yang Anda tetapkan saat menentukan kondisi untuk kebijakan pemberitahuan. Bagian ini memberikan ilustrasi singkat tentang arti kolom-kolom ini.

Periode penyelarasan

Catatan: Cloud Monitoring selalu menggunakan periode penyelarasan 24 jam untuk kondisi ketiadaan metrik.

Periode perataan adalah interval lihat-balik dari titik waktu tertentu. Perata adalah fungsi yang menggabungkan titik-titik ke dalam interval lihat-kembali menjadi nilai yang disejajarkan. Misalnya, saat periode penyelarasan adalah lima menit, pada pukul 13.00, periode perataan akan 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.

Konsol Google Cloud

Anda mengonfigurasi kolom perataan dengan menu Rolling window dan Rolling window function yang merupakan bagian dari dialog New condition.

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

API

Anda mengonfigurasi kolom perataan dengan menetapkan kolom aggregations.alignmentPeriod dan aggregations.perSeriesAligner di struktur MetricThreshold dan MetricAbsence.

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

Untuk menggambarkan efek periode penyelarasan pada suatu kondisi dalam kebijakan pemberitahuan, pertimbangkan kondisi batas metrik yang memantau metrik dengan periode pengambilan sampel satu menit. Asumsikan bahwa periode penyelarasan disetel ke lima menit dan aligner disetel ke sum. Selain itu, asumsikan bahwa kondisi terpenuhi saat nilai deret waktu yang diselaraskan lebih besar dari dua selama setidaknya tiga menit, dan bahwa kondisi tersebut dievaluasi setiap menit. Gambar berikut mengilustrasikan beberapa evaluasi berurutan kondisi:

Setiap baris dalam gambar menggambarkan satu evaluasi kondisi. Data deret waktu akan ditampilkan. Titik-titik pada periode penyelarasan ditampilkan dengan titik-titik biru; titik-titik yang lebih lama berwarna hitam. Setiap baris menampilkan nilai yang disejajarkan dan apakah nilai ini lebih besar dari nilai minimum dua. Untuk baris berlabel start, nilai yang disejajarkan dihitung menjadi satu, yang lebih kecil 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 durasi tersebut akan dimulai.

Jendela durasi

Anda menggunakan durasi, atau periode durasi, untuk mencegah suatu kondisi terpenuhi karena satu pengukuran atau perkiraan. Misalnya, kolom durasi untuk suatu kondisi disetel ke 15 menit. Hal berikut menjelaskan perilaku kondisi berdasarkan jenisnya:

• Kondisi batas metrik terpenuhi saat, untuk satu deret waktu, setiap pengukuran yang diselaraskan dalam interval 15 menit melanggar nilai minimum tersebut.
• Kondisi absensi metrik terpenuhi saat tidak ada data yang tiba untuk deret waktu dalam interval 15 menit.
• Kondisi perkiraan terpenuhi saat setiap perkiraan yang dihasilkan selama periode 15 menit memprediksi bahwa deret waktu akan melanggar batas dalam periode perkiraan.

Untuk kebijakan dengan satu kondisi, insiden dibuka dan notifikasi akan dikirim saat kondisi terpenuhi. Insiden ini tetap terbuka meskipun kondisi terus terpenuhi.

Konsol Google Cloud

Anda mengonfigurasi periode durasi menggunakan kolom Retest window pada langkah Configure trigger.

API

Anda mengonfigurasi jendela durasi dengan menetapkan kolom duration di struktur MetricThreshold dan MetricAbsence.

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

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

Suatu kondisi mereset periode durasinya setiap kali pengukuran atau perkiraan tidak memenuhi kondisi tersebut. Perilaku ini diilustrasikan dalam contoh berikut:

Contoh: Kebijakan pemberitahuan ini berisi satu kondisi batas metrik yang menentukan periode durasi lima menit.

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

Urutan berikut mengilustrasikan bagaimana periode durasi memengaruhi evaluasi kondisi:

1. Latensi HTTP kurang dari dua detik.
2. Selama tiga menit berturut-turut, latensi HTTP lebih besar dari dua detik.
3. Pada pengukuran berikutnya, latensi kurang dari dua detik sehingga kondisi akan mereset periode durasi.

4. Selama lima menit berturut-turut, latensi HTTP lebih besar dari dua detik, sehingga kondisi terpenuhi.

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

Setel periode durasi menjadi cukup lama untuk meminimalkan positif palsu (PP), tetapi cukup singkat untuk memastikan bahwa insiden dibuka secara tepat waktu.

Praktik terbaik untuk menetapkan periode penyelarasan dan periode durasi

Periode penyelarasan menentukan berapa banyak sampel yang digabungkan dengan aligner:

• Nilai minimum periode penyelarasan untuk jenis metrik adalah periode pengambilan sampel jenis metrik tersebut. Misalnya, jika jenis metrik diambil sampelnya setiap 300 detik, periode penyelarasan minimal harus 300 detik. Namun, jika Anda ingin menggabungkan 5 sampel, tetapkan periode perataan ke 5 * 300 detik atau 1.500 detik.

• Nilai maksimum periode penyelarasan adalah 24 jam lebih sedikit penundaan penyerapan jenis metrik. Misalnya, jika penundaan penyerapan untuk metrik adalah 6 jam, nilai maksimum periode penyelarasan adalah 18 jam.

Gunakan periode durasi untuk menentukan tingkat respons notifikasi. Misalnya, jika Anda menetapkan periode durasi ke 20 menit untuk kondisi ketiadaan metrik, maka tidak boleh ada data selama 20 menit sebelum kondisi ini terpenuhi. Untuk kebijakan pemberitahuan yang lebih responsif, tetapkan durasi ke nilai yang lebih kecil. Untuk kondisi batas metrik, agar memiliki kebijakan pemberitahuan yang paling responsif, tetapkan durasi ke nol. Satu nilai yang disejajarkan menyebabkan jenis kondisi ini terpenuhi.

Kondisi kebijakan pemberitahuan dievaluasi pada frekuensi tetap. Pilihan yang Anda buat untuk periode penyelarasan dan periode durasi tidak menentukan seberapa sering kondisi dievaluasi.

Kebijakan dengan beberapa ketentuan

Kebijakan pemberitahuan dapat berisi hingga 6 kondisi.

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

Konsol Google Cloud

Anda mengonfigurasi opsi penggabung pada langkah Pemicu multi-kondisi.

API

Anda mengonfigurasi opsi penggabung dengan kolom combiner dari struktur AlertPolicy.

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

Google Cloud Console Nilai pemicu kebijakan	Nilai kombinasi Cloud Monitoring API	Arti
Semua kondisi terpenuhi	OR	Insiden dibuka jika ada resource yang menyebabkan salah satu kondisi terpenuhi.
Semua kondisi terpenuhi bahkan untuk resource yang berbeda untuk setiap kondisi (default)	AND	Insiden dibuka jika setiap kondisi terpenuhi, meskipun resource berbeda menyebabkan kondisi tersebut terpenuhi.
Semua kondisi terpenuhi	AND_WITH_MATCHING_RESOURCE	Insiden dibuka jika resource yang sama menyebabkan setiap kondisi terpenuhi. Setelan ini adalah pilihan gabungan yang paling ketat.
Catatan: Kebijakan pemberitahuan menggunakan nilai label untuk mengidentifikasi resource yang menyebabkan kondisi terpenuhi. Agar kebijakan pemberitahuan dengan penggabung ini dapat membuat insiden atau membuat notifikasi, hal berikut harus terpenuhi: Setiap kondisi harus memantau resource yang sama. Misalnya, untuk semua kondisi, jenis resource ditetapkan ke gce_instance. Label resource yang dimonitor yang tersedia setelah agregasi harus sama untuk semua kondisi. Misalnya, untuk resource gce_instance, labelnya adalah project_id, instance_id, dan zone. Jika satu kondisi dikelompokkan menurut zone, semua kondisi harus dikelompokkan menurut zone. Untuk mengetahui daftar resource yang dipantau dan labelnya, lihat Jenis resource yang dimonitor.

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

Contoh

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

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

Pada awalnya, asumsikan bahwa kedua kondisi tersebut bernilai false.

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

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

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

  Jika vm2 menyebabkan kondisi CPU usage is too high terpenuhi, insiden juga akan dibuat. Insiden 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: Insiden dibuat karena kedua kondisi terpenuhi.

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

Data metrik sebagian

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

Konsol Google Cloud

Anda dapat mengonfigurasi cara Monitoring mengevaluasi kondisi batas metrik saat data berhenti masuk. Misalnya, saat insiden terbuka dan pengukuran yang diharapkan tidak muncul, apakah Anda ingin Monitoring membiarkan insiden terbuka atau langsung menutupnya? Demikian pula, ketika data berhenti tiba dan tidak ada insiden yang terbuka, apakah Anda ingin membuka insiden? Terakhir, berapa lama insiden harus tetap terbuka setelah data berhenti tiba?

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

• Untuk mengonfigurasi cara Monitoring menentukan nilai pengganti untuk data yang hilang, gunakan kolom Evaluasi data yang hilang yang Anda tetapkan pada langkah Pemicu kondisi. Kolom ini dinonaktifkan jika periode pengujian ulang disetel ke No retest.

• Untuk mengonfigurasi waktu tunggu Monitoring sebelum menutup insiden yang terbuka setelah data berhenti masuk, gunakan kolom Incident autoclose duration. Anda menetapkan durasi penutupan otomatis pada langkah Notification. Durasi tutup otomatis default adalah tujuh hari.

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

Google Cloud Console Kolom "Evaluasi data yang hilang"	Ringkasan	Detail
Data tidak ada kosong	Insiden terbuka tetap terbuka. Insiden baru tidak dibuka.	Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti tiba. Jika terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang diterima, timer tutup otomatis akan dimulai setelah penundaan setidaknya 15 menit. Jika timer berakhir, insiden akan ditutup. Untuk kondisi yang tidak terpenuhi, kondisi tersebut tetap tidak akan terpenuhi saat data berhenti tiba.
Titik data yang tidak ada diperlakukan sebagai nilai yang melanggar ketentuan kebijakan	Insiden terbuka tetap terbuka. Insiden baru dapat dibuka.	Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti tiba. Jika terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang masuk untuk durasi penutupan otomatis ditambah 24 jam, insiden tersebut akan ditutup. Untuk kondisi yang tidak terpenuhi, setelan ini menyebabkan kondisi batas metrik berperilaku seperti metric-absence condition. Jika data tidak muncul pada waktu yang ditentukan oleh periode pengujian ulang, kondisi akan dievaluasi sebagai terpenuhi. Untuk kebijakan pemberitahuan dengan satu kondisi, kondisi yang terpenuhi menyebabkan insiden dibuka.
Titik data yang tidak ada diperlakukan sebagai nilai yang tidak melanggar ketentuan kebijakan	Insiden terbuka ditutup. Insiden baru tidak dibuka.	Untuk kondisi yang terpenuhi, kondisi akan berhenti terpenuhi saat data berhenti tiba. Jika terbuka untuk kondisi ini, berarti insiden tersebut ditutup. Untuk kondisi yang tidak terpenuhi, kondisi tersebut tetap tidak akan terpenuhi saat data berhenti tiba.

API

Anda dapat mengonfigurasi cara Monitoring mengevaluasi kondisi batas metrik saat data berhenti masuk. Misalnya, saat insiden terbuka dan pengukuran yang diharapkan tidak muncul, apakah Anda ingin Monitoring membiarkan insiden terbuka atau langsung menutupnya? Demikian pula, ketika data berhenti tiba dan tidak ada insiden yang terbuka, apakah Anda ingin membuka insiden? Terakhir, berapa lama insiden harus tetap terbuka setelah data berhenti tiba?

Ada dua kolom yang dapat dikonfigurasi yang menentukan cara Monitoring mengevaluasi kondisi batas 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 adalah nol.

• Untuk mengonfigurasi waktu tunggu Monitoring sebelum menutup insiden yang terbuka setelah data berhenti masuk, gunakan kolom autoClose di struktur AlertStrategy.

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

Kolom API evaluationMissingData	Ringkasan	Detail
EVALUATION_MISSING_DATA_UNSPECIFIED	Insiden terbuka tetap terbuka. Insiden baru tidak dibuka.	Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti tiba. Jika terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang diterima, timer tutup otomatis akan dimulai setelah penundaan setidaknya 15 menit. Jika timer berakhir, insiden akan ditutup. Untuk kondisi yang tidak terpenuhi, kondisi tersebut tetap tidak akan terpenuhi saat data berhenti tiba.
EVALUATION_MISSING_DATA_ACTIVE	Insiden terbuka tetap terbuka. Insiden baru dapat dibuka.	Untuk kondisi yang terpenuhi, kondisi tersebut akan terus terpenuhi saat data berhenti tiba. Jika terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang diterima untuk durasi penutupan otomatis ditambah 24 jam, insiden tersebut akan ditutup. Untuk kondisi yang tidak terpenuhi, setelan ini menyebabkan kondisi batas metrik berperilaku seperti metric-absence condition. Jika data tidak muncul pada waktu yang ditentukan oleh kolom `duration`, kondisi akan dievaluasi sebagai terpenuhi. Untuk kebijakan pemberitahuan dengan satu kondisi, kondisi yang terpenuhi menyebabkan insiden dibuka.
EVALUATION_MISSING_DATA_INACTIVE	Insiden terbuka ditutup. Insiden baru tidak dibuka.	Untuk kondisi yang terpenuhi, kondisi akan berhenti terpenuhi saat data berhenti tiba. Jika terbuka untuk kondisi ini, berarti insiden tersebut ditutup. Untuk kondisi yang tidak terpenuhi, kondisi tersebut tetap tidak akan terpenuhi saat data berhenti tiba.

Anda dapat meminimalkan masalah karena data yang hilang dengan melakukan salah satu hal berikut:

• Hubungi penyedia cloud pihak ketiga Anda untuk mengidentifikasi cara mengurangi latensi pengumpulan metrik.
• Gunakan periode berdurasi lebih lama dalam kondisi Anda. Menggunakan jangka waktu yang lebih lama dapat merugikan karena kebijakan pemberitahuan Anda kurang responsif.

• Pilih metrik yang memiliki penundaan pengumpulan lebih rendah:

  • Metrik agen pemantauan, terutama ketika agen dijalankan pada 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 pemantauan, Ringkasan metrik yang ditentukan pengguna, dan metrik berbasis log.

Notifikasi dan insiden per kebijakan

Agar Monitoring tidak membuat insiden dan mengirim notifikasi untuk kebijakan pemberitahuan, buat tunda dan sertakan kebijakan pemberitahuan dalam kriteria tunda. Saat penundaan aktif, kebijakan pemberitahuan tidak membuat insiden atau mengirim notifikasi.

Jika kebijakan diaktifkan dan tidak cocok dengan kriteria penundaan aktif, insiden dapat dibuat dan notifikasi dapat dikirim. Bagian ini menjelaskan batas jumlah insiden terbuka per kebijakan dan kapan Anda mungkin melihat beberapa notifikasi untuk insiden yang sama.

Jumlah insiden terbuka per kebijakan

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

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

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

Catatan: Jika Anda membuka insiden untuk kebijakan pemberitahuan dan deret waktu yang menyebabkan insiden melampaui batas kondisi lagi, saat insiden masih terbuka, insiden lain tidak akan dibuka. Monitoring hanya mempertahankan satu insiden terbuka untuk setiap deret waktu dalam kebijakan pemberitahuan.

Jumlah notifikasi per kebijakan

Secara default, notifikasi dikirim saat deret waktu menyebabkan suatu kondisi terpenuhi. Anda mungkin menerima beberapa notifikasi jika salah satu dari hal berikut berlaku:

• Kondisi memantau beberapa deret waktu.

• Kebijakan berisi beberapa ketentuan:

  • Semua kondisi terpenuhi: Jika semua kondisi terpenuhi, lalu untuk setiap deret waktu yang menghasilkan kondisi terpenuhi, Monitoring akan mengirimkan notifikasi dan membuat insiden. Misalnya, anggap Anda memiliki kebijakan dengan dua kondisi dan setiap kondisi memantau satu deret waktu. Saat semua kondisi terpenuhi, Anda akan menerima dua notifikasi dan akan melihat dua insiden.

  • Setiap kondisi terpenuhi: kebijakan pemberitahuan akan mengirim notifikasi setiap kali kondisi terpenuhi. Misalnya, anggap Anda memiliki kebijakan dengan dua kondisi dan setiap kondisi memantau satu deret waktu. Asumsikan bahwa kondisi pertama terpenuhi. Hal ini menyebabkan insiden dibuka dan notifikasi akan dikirim. Jika insiden masih terbuka saat pengukuran berikutnya menyebabkan kondisi kedua terpenuhi, notifikasi lain akan dikirim.

Catatan: Jika kebijakan pemberitahuan memiliki beberapa kondisi, Anda tidak dapat mengonfigurasinya untuk mengirim satu notifikasi dan membuat satu insiden.

Kebijakan pemberitahuan yang dibuat menggunakan Cloud Monitoring API akan memberi tahu Anda saat kondisi terpenuhi dan saat kondisi berhenti terpenuhi. Secara default, kebijakan pemberitahuan yang dibuat menggunakan Konsol Google Cloud akan memberi tahu Anda saat terjadi insiden. Perangkat tersebut tidak akan memberi tahu Anda saat insiden ditutup. Anda dapat mengaktifkan notifikasi saat penutupan insiden.

Catatan: Anda tidak dapat mengubah pengiriman notifikasi penutupan insiden dengan menggunakan Monitoring API.

Notifikasi untuk kebijakan pemberitahuan yang dinonaktifkan

Saat Anda menonaktifkan kebijakan pemberitahuan, kebijakan pemberitahuan akan terus mengevaluasi kondisinya. Namun, insiden tidak dibuat dan notifikasi tidak dikirim.

Jika Anda mengaktifkan kebijakan yang dinonaktifkan, Monitoring akan memeriksa nilai semua kondisi selama periode durasi terbaru. Durasi terbaru dapat mencakup data yang diambil sebelum, selama, dan setelah kebijakan diaktifkan. Kondisi kebijakan yang dinonaktifkan dapat segera terpenuhi setelah melanjutkan kebijakan, meskipun dengan periode durasi yang panjang.

Misalnya, Anda memiliki kebijakan pemberitahuan yang memantau proses tertentu dan Anda menonaktifkan kebijakan ini. Pada minggu berikutnya, prosesnya akan berhenti, 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 belum berjalan selama lima menit terakhir dan membuka insiden.

Saat Anda menonaktifkan kebijakan pemberitahuan, insiden yang terbuka akan tetap terbuka hingga durasi penutupan otomatis berakhir. Saat Anda menunda kebijakan pemberitahuan, semua insiden terbuka yang terkait dengan kebijakan tersebut akan ditutup. Namun, saat penundaan berakhir, insiden baru mungkin terbuka. Untuk mendapatkan informasi, lihat Menunda notifikasi dan pemberitahuan.

Notifikasi untuk kebijakan yang cocok dengan kriteria penundaan aktif

Jika Anda ingin mencegah kebijakan pemberitahuan agar tidak mengirim notifikasi dalam interval singkat, sebaiknya buat penundaan, bukan menonaktifkan kebijakan pemberitahuan. Misalnya, sebelum melakukan pemeliharaan pada virtual machine (VM), Anda dapat membuat penundaan dan menambahkan kebijakan pemberitahuan yang memantau instance ke kriteria penundaan.

Saat kondisi kebijakan pemberitahuan terpenuhi dan kebijakan tersebut memenuhi kriteria penundaan aktif, tidak akan ada insiden yang dibuat dan notifikasi yang dikirim. Saat penundaan berakhir, kebijakan pemberitahuan dapat membuat insiden dan mengirim notifikasi.

Kirim notifikasi berulang

Untuk mengingatkan penerima notifikasi tentang insiden yang terbuka dan diakui, siapkan notifikasi berulang. Fitur ini berguna untuk memberi tahu kebijakan yang memantau resource penting yang, jika habis, dapat menyebabkan layanan gagal. Misalnya, Anda dapat menyiapkan notifikasi berulang untuk kebijakan pemberitahuan yang memantau jumlah kapasitas disk kosong.

Secara default, kebijakan pemberitahuan mengirimkan satu notifikasi ke setiap saluran notifikasi saat insiden dibuka. Namun, Anda dapat mengubah perilaku default dan mengonfigurasi kebijakan pemberitahuan untuk mengirim ulang notifikasi ke semua atau beberapa saluran notifikasi kebijakan pemberitahuan. Notifikasi berulang ini dikirim untuk insiden dengan status Terbuka atau Dikonfirmasi. Interval notifikasi ini harus setidaknya 30 menit dan tidak lebih dari 24 jam, yang dinyatakan dalam detik.

Catatan: Anda tidak dapat menyiapkan notifikasi berulang untuk pemberitahuan berbasis log.

Konsol Google Cloud

Anda tidak dapat mengonfigurasi notifikasi berulang di Konsol Google Cloud. Gunakan Google Cloud CLI atau API sebagai gantinya.

API

Tambahkan minimal satu objek NotificationChannelStrategy ke objek AlertStrategy Anda. Objek NotificationChannelStrategy memiliki dua kolom:

• renotifyInterval: Jumlah waktu, dalam detik, antara notifikasi berulang.

  Anda dapat mengubah nilai kolom renotifyInterval kapan saja. Jika insiden yang terkait dengan kebijakan pemberitahuan terbuka saat Anda mengubah interval, kebijakan pemberitahuan akan mengirimkan notifikasi lain untuk insiden tersebut, lalu memulai ulang periode interval.

• notificationChannelNames: Array nama resource saluran notifikasi, yang merupakan string dalam format projects/PROJECT_ID/notificationChannels/CHANNEL_ID Saluran notifikasi ini menerima notifikasi berulang pada interval yang ditentukan oleh nilai renotifyInterval.

  ID saluran nama resource adalah nilai numerik. Untuk mengetahui informasi tentang cara mengambil ID saluran, lihat Mencantumkan saluran notifikasi dalam project.

Misalnya, contoh JSON berikut menunjukkan strategi pemberitahuan yang dikonfigurasi untuk mengirim notifikasi berulang setiap 1800 detik (30 menit) ke saluran notifikasi yang tercantum:

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

Untuk mengetahui informasi selengkapnya tentang cara membuat kebijakan pemberitahuan dengan API, lihat Membuat kebijakan pemberitahuan dengan API.

Untuk menghentikan notifikasi berulang selama jangka waktu tertentu, nonaktifkan atau buat penundaan untuk kebijakan pemberitahuan. Untuk sepenuhnya menghentikan notifikasi berulang, edit kebijakan pemberitahuan menggunakan API dan hapus objek NotificationChannelStrategy.

Latensi

Latensi mengacu pada penundaan antara saat Monitoring mengambil sampel metrik dan saat titik data metrik terlihat sebagai data deret waktu. Latensi memengaruhi kapan notifikasi dikirim. Misalnya, jika metrik yang dipantau memiliki latensi hingga 180 detik, Monitoring tidak akan membuat insiden hingga 180 detik setelah kondisi kebijakan pemberitahuan bernilai true (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 60 hingga 90 detik. Untuk metrik AWS CloudWatch, penundaan visibilitas dapat berlangsung selama beberapa menit. Untuk cek uptime, nilai ini dapat berupa rata-rata dua menit (dari akhir periode durasi).

• Periode durasi: Jendela yang dikonfigurasi untuk kondisi tersebut. Kondisi hanya terpenuhi jika suatu kondisi benar (true) selama jangka waktu durasi. Misalnya, setelan periode durasi lima menit menyebabkan keterlambatan dalam notifikasi selama setidaknya lima menit sejak peristiwa pertama kali terjadi.

• Waktu penerimaan notifikasi: Saluran notifikasi, seperti email dan SMS, mungkin mengalami latensi jaringan atau latensi lainnya (tidak terkait dengan konten yang dikirimkan), terkadang hampir mencapai hitungan menit. Di beberapa saluran, seperti SMS dan Slack, tidak ada jaminan bahwa pesan akan dikirim.

Langkah selanjutnya

• Untuk mengetahui informasi tentang cara membuat kebijakan pemberitahuan, lihat dokumen berikut:

  • Membuat kebijakan pemberitahuan batas metrik
  • Membuat kebijakan pemberitahuan yang tidak ada metrik
  • Membuat kebijakan pemberitahuan nilai metrik yang diperkirakan
  • Membuat kebijakan pemberitahuan menggunakan Monitoring API

• Untuk mengetahui berbagai kebijakan pemberitahuan, lihat Contoh kebijakan.