Perilaku kebijakan pemberitahuan berbasis metrik

Dokumen ini menjelaskan cara setelan periode dan durasi penyelarasan menentukan kapan suatu kondisi terpicu, bagaimana kebijakan pemberitahuan menggabungkan beberapa kondisi, dan cara kebijakan pemberitahuan menggantikan titik data yang hilang. Bagian ini juga menjelaskan jumlah maksimum insiden terbuka untuk 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 penyelarasan

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

Periode perataan adalah interval lihat balik dari titik waktu tertentu; aligner adalah fungsi yang menggabungkan titik-titik ke dalam interval lihat-balik menjadi nilai yang disejajarkan. Misalnya, saat 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.

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 kondisi dalam kebijakan pemberitahuan, pertimbangkan kondisi batas metrik yang memantau metrik dengan periode pengambilan sampel satu menit. Asumsikan bahwa periode perataan disetel ke lima menit dan aligner disetel ke sum. Selain itu, asumsikan bahwa kondisi tersebut terpicu 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 untuk kondisi:

Gambar yang mengilustrasikan efek periode penyelarasan.

Setiap baris dalam gambar mengilustrasikan satu evaluasi kondisi. Data deret waktu akan ditampilkan. Titik-titik pada periode penyelarasan ditampilkan dengan titik biru, semua titik yang lebih lama berwarna hitam. Setiap baris menampilkan nilai yang diselaraskan dan apakah nilai ini lebih besar dari nilai minimum dua. Untuk baris berlabel start, nilai yang diselaraskan akan 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 ambang batas, timer untuk durasi tersebut akan dimulai.

Jendela durasi

Anda menggunakan duration, atau periode durasi, untuk mencegah kondisi dipicu karena satu pengukuran atau perkiraan. Misalnya, anggaplah kolom durasi untuk kondisi ditetapkan ke 15 menit. Berikut ini menjelaskan perilaku kondisi berdasarkan jenisnya:

  • Kondisi batas metrik dipicu saat, untuk satu deret waktu, setiap pengukuran yang diselaraskan dalam interval 15 menit melanggar batas tersebut.
  • Kondisi tidak adanya metrik dipicu saat tidak ada data yang tiba untuk deret waktu dalam interval 15 menit.
  • Kondisi perkiraan dipicu 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 dikirim saat kondisinya terpicu. Insiden ini akan tetap terbuka meskipun kondisinya terus terpenuhi.

Konsol Google Cloud

Anda mengonfigurasi periode durasi menggunakan kolom Periode pengujian ulang pada langkah Konfigurasi pemicu.

API

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

Gambar sebelumnya mengilustrasikan tiga evaluasi kondisi batas metrik. Pada saat start + 2 minutes, nilai yang diselaraskan lebih besar dari nilai minimum; tetapi kondisi tidak akan dipicu karena periode durasi disetel ke tiga menit. Gambar berikut mengilustrasikan hasil untuk evaluasi kondisi berikutnya:

Gambar yang mengilustrasikan efek interval durasi.

Meskipun nilai yang diselaraskan lebih besar dari nilai minimum pada waktu start + 2 minutes, kondisi tersebut tidak akan terpicu hingga 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 nilai minimum 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 ini mereset jendela durasi.
  4. Selama lima menit berturut-turut, latensi HTTP lebih besar dari dua detik, sehingga kondisi terpicu.

    Karena kebijakan pemberitahuan memiliki satu kondisi, insiden dibuka dan notifikasi dikirim saat kondisi dipicu.

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

Praktik terbaik untuk menetapkan periode penyelarasan dan periode durasi

Periode penyelarasan menentukan jumlah 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 penyelarasan ke 5 * 300 detik atau 1500 detik.

  • Nilai maksimum periode penyelarasan adalah 24 jam lebih sedikit keterlambatan 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 dipicu. Jika Anda menginginkan notifikasi yang lebih responsif, tetapkan durasi ke nilai yang lebih kecil. Untuk kondisi batas metrik, agar mendapatkan pemberitahuan yang paling responsif, tetapkan durasi ke nol. Satu nilai yang diselaraskan menyebabkan jenis kondisi ini dipicu.

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 kondisi

Kebijakan pemberitahuan dapat berisi maksimal 6 kondisi.

Jika menggunakan Cloud Monitoring API atau jika kebijakan pemberitahuan memiliki beberapa kondisi, Anda harus menentukan kapan insiden dibuka. Untuk mengonfigurasi bagaimana beberapa kondisi digabungkan, lakukan salah satu hal 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 Google Cloud Console, nilai yang setara dalam Cloud Monitoring API, dan deskripsi setiap setelan:

Konsol Google Cloud
Kebijakan memicu nilai
Nilai penggabung
Cloud Monitoring API
Arti
Semua kondisi terpenuhi OR Insiden dibuka jika ada resource yang menyebabkan 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 penggabungan yang paling ketat.

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

Contoh

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

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

Awalnya, asumsikan bahwa kedua kondisi bernilai false.

Selanjutnya, asumsikan bahwa penggunaan CPU vm1 melebihi 100 md/s 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 terpenuhi. Berikut ini menjelaskan apa yang terjadi berdasarkan bagaimana 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, itu juga akan menyebabkan insiden 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 hilang; data yang hilang dapat menyebabkan kebijakan tidak memberikan pemberitahuan dan insiden tidak ditutup. Penundaan data yang diterima dari penyedia cloud pihak ketiga dapat berlangsung paling lama 30 menit, dengan penundaan 5-15 menit adalah yang paling umum. Penundaan yang lama—lebih lama dari rentang durasi—dapat menyebabkan kondisi memasuki status "tidak diketahui". Ketika data akhirnya tiba, Monitoring mungkin kehilangan beberapa histori kondisi terbaru. Pemeriksaan data deret waktu di kemudian hari 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 tiba. 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 insiden dibuka? 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 tiba:

  • Untuk mengonfigurasi cara Monitoring menentukan nilai penggantian untuk data yang hilang, gunakan kolom Evaluation of missing data yang Anda tetapkan pada langkah Condition trigger. Kolom ini dinonaktifkan saat jendela pengujian ulang disetel ke No retest.

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

Berikut ini penjelasan yang berbeda untuk kolom data yang tidak ada:

Konsol Google Cloud
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 insiden terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang masuk, timer tutup otomatis akan dimulai setelah penundaan minimal 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 insiden terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Jika 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 tiba dalam waktu yang ditentukan oleh periode uji ulang, kondisi ini 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 insiden terbuka untuk kondisi ini, maka insiden tersebut akan 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 tiba. 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 insiden dibuka? 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 tiba:

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

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

Berikut ini penjelasan yang berbeda 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 insiden terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang masuk, timer tutup otomatis akan dimulai setelah penundaan minimal 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 insiden terbuka untuk kondisi ini, insiden tersebut akan tetap terbuka. Jika 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 tiba dalam waktu yang ditentukan oleh kolom `duration`, maka kondisinya 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 insiden terbuka untuk kondisi ini, maka insiden tersebut akan 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 dengan durasi yang lebih lama dalam kondisi Anda. Menggunakan periode durasi yang lebih lama memiliki kerugian karena membuat kebijakan pemberitahuan Anda kurang responsif.
  • Pilih metrik yang memiliki keterlambatan pengumpulan lebih rendah:

    • Memantau metrik agen, terutama saat agen berjalan pada instance VM di cloud pihak ketiga.
    • Metrik kustom, saat Anda menulis datanya langsung ke Cloud Monitoring.
    • Metrik berbasis log, jika pengumpulan 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 akan 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, pertimbangkan kebijakan yang berlaku untuk 2.000 (atau 20.000) instance Compute Engine, dan setiap instance menyebabkan kondisi pemberitahuan terpenuhi. Pemantauan membatasi jumlah insiden terbuka hingga 1.000. Kondisi lainnya yang terpenuhi akan diabaikan sampai beberapa insiden terbuka untuk kebijakan tersebut ditutup.

Jumlah notifikasi per kebijakan

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

  • Suatu kondisi memantau beberapa deret waktu.

  • Kebijakan berisi beberapa ketentuan:

    • Semua kondisi terpenuhi: Jika semua kondisi terpicu, maka untuk setiap deret waktu yang menyebabkan kondisi dipicu, kebijakan pemberitahuan akan mengirimkan notifikasi dan membuat insiden. Misalnya, anggap Anda memiliki kebijakan dengan dua kondisi dan setiap kondisi memantau satu deret waktu. Jika semua kondisi terpicu, Anda akan menerima dua notifikasi dan akan melihat dua insiden.

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

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

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.

Saat 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. Kebijakan dapat langsung dipicu setelah dilanjutkan, meskipun dengan jendela berdurasi panjang.

Misalnya, Anda memiliki kebijakan pemberitahuan yang memantau proses tertentu dan menonaktifkan kebijakan ini. Pada minggu berikutnya, prosesnya akan berhenti berjalan, dan Anda tidak akan menerima notifikasi karena kebijakan pemberitahuan dinonaktifkan. Jika Anda memulai ulang proses dan segera mengaktifkan kebijakan pemberitahuan, Monitoring akan mengetahui bahwa prosesnya belum berjalan selama lima menit terakhir dan akan membuka insiden.

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

Notifikasi untuk kebijakan yang cocok dengan kriteria penundaan aktif

Jika Anda ingin mencegah kebijakan pemberitahuan 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 tunda.

Jika kondisi kebijakan pemberitahuan dipicu dan kebijakan tersebut cocok dengan kriteria penundaan aktif, tidak akan ada insiden yang dibuat dan notifikasi tidak akan dikirim. Saat penundaan berakhir, kebijakan pemberitahuan dapat membuat insiden dan mengirim notifikasi.

Mengirim notifikasi berulang

Untuk mengingatkan penerima notifikasi tentang insiden yang terbuka dan dikonfirmasi, 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 yang 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.

Konsol Google Cloud

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

API

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

  • renotifyInterval: Jumlah waktu, dalam detik, di 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 akan 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, baca 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 lebih lanjut 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 dievaluasi ke true. Untuk mengetahui informasi selengkapnya, lihat Latensi data metrik.

Peristiwa dan setelan berikut berkontribusi pada latensi:

  • Penundaan pengumpulan metrik: Waktu yang diperlukan Cloud Monitoring untuk mengumpulkan nilai metrik. Untuk nilai Google Cloud, sebagian besar metrik tidak terlihat selama 60 detik setelah pengumpulan. Namun, keterlambatan bergantung pada metrik. Komputasi kebijakan pemberitahuan memerlukan penundaan tambahan antara 60 hingga 90 detik. Untuk metrik AWS CloudWatch, penundaan visibilitas dapat berlangsung selama beberapa menit. Untuk cek uptime, rata-ratanya adalah dua menit (dari akhir periode durasi).

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

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

Langkah selanjutnya