Perilaku kebijakan pemberitahuan berbasis metrik

Dokumen ini menjelaskan cara periode penyelarasan dan periode pengujian ulang menentukan kapan kondisi terpenuhi, cara kebijakan pemberitahuan menggabungkan beberapa kondisi, dan cara kebijakan pemberitahuan mengganti titik data yang hilang. Laporan ini juga menjelaskan jumlah maksimum insiden terbuka untuk kebijakan, jumlah notifikasi per insiden, dan penyebab penundaan notifikasi.

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

Periode perataan dan periode pengujian ulang

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

Periode penyelarasan

Sebelum dipantau oleh kebijakan pemberitahuan, data deret waktu harus diregulasi sehingga kebijakan pemberitahuan memiliki data yang diatur secara berkala untuk dievaluasi. Proses regularisasi disebut penyelarasan.

Penyelarasan melibatkan dua langkah:

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

  • Menghitung satu nilai untuk titik dalam periode penyelarasan. Anda memilih cara penghitungan satu titik 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 perataan, lihat Perataan: regulasi dalam seri.

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

Pemantauan mengonfigurasi periode penyelarasan sebagai berikut:

Konsol Google Cloud

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

  • Periode bergulir: Menentukan rentang waktu yang akan dievaluasi.
  • Fungsi rolling window: Menentukan fungsi matematika yang akan dilakukan pada jendela titik data.

Untuk informasi selengkapnya tentang fungsi yang tersedia, lihat Aligner dalam referensi API. Beberapa fungsi penyelaras menyesuaikan 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 periode perataan dengan menetapkan kolom aggregations.alignmentPeriod dan aggregations.perSeriesAligner dalam struktur MetricThreshold dan MetricAbsence.

Untuk informasi selengkapnya tentang fungsi yang tersedia, lihat Aligner dalam referensi API. Beberapa fungsi penyelaras menyesuaikan data dan mengonversinya dari satu jenis atau jenis metrik ke jenis atau jenis metrik lainnya. Untuk penjelasan mendetail, lihat Jenis, jenis, 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 disetel ke lima menit dan penyelaras disetel ke sum. Selain itu, asumsikan bahwa kondisi terpenuhi saat nilai deret waktu yang diselaraskan lebih besar dari dua selama setidaknya tiga menit, dan kondisi tersebut dievaluasi setiap menit. Dalam contoh ini, periode perataan adalah dua menit, dan periode pengujian ulang, yang dijelaskan di bagian berikutnya, adalah tiga menit. Gambar berikut mengilustrasikan beberapa evaluasi berurutan terhadap kondisi:

Gambar yang menggambarkan efek periode penyelarasan pada periode/durasi pengujian ulang.

Setiap baris dalam gambar mengilustrasikan satu evaluasi kondisi. Data deret waktu akan ditampilkan. Titik dalam periode perataan ditampilkan dengan titik biru; 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 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 periode pengujian ulang, yang mencegah kondisi terpenuhi karena satu pengukuran atau perkiraan. Misalnya, asumsikan bahwa periode pengujian ulang kondisi ditetapkan ke 15 menit. Berikut ini penjelasan perilaku kondisi berdasarkan jenisnya:

  • Kondisi nilai minimum metrik terpenuhi jika, untuk satu deret waktu, setiap pengukuran yang diselaraskan dalam interval 15 menit melanggar nilai minimum.
  • Kondisi tidak adanya 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, insiden akan dibuka dan notifikasi akan dikirim saat kondisi terpenuhi. Insiden ini tetap terbuka selama kondisi terus terpenuhi.

Konsol Google Cloud

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

API

Anda mengonfigurasi periode pengujian ulang dengan menetapkan kolom yang disebut 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; tetapi, kondisinya 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 mereset periode pengujian ulang setiap kali pengukuran atau perkiraan tidak memenuhi kondisi. Perilaku ini diilustrasikan dalam contoh berikut:

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

Jika latensi respons HTTP lebih 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 menggambarkan pengaruh periode pengujian ulang terhadap evaluasi kondisi:

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

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

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

Tetapkan periode pengujian ulang agar cukup lama untuk meminimalkan positif palsu, tetapi cukup singkat untuk memastikan insiden dibuka secara tepat waktu.

Praktik terbaik untuk menetapkan periode penyelarasan dan periode pengujian ulang

Periode penyelarasan menentukan jumlah sampel yang digabungkan dengan penyelaras:

  • Nilai minimum periode penyelarasan untuk jenis metrik adalah periode sampling jenis metrik tersebut. Misalnya, jika jenis metrik diambil sampelnya setiap 300 detik, periode perataan harus minimal 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 dikurangi penundaan penyerapan jenis metrik. Misalnya, jika penundaan penyerapan untuk metrik adalah 6 jam, nilai maksimum periode penyelarasan adalah 18 jam.

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

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

Kebijakan dengan beberapa kondisi

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 menggabungkan beberapa kondisi, lakukan salah satu hal berikut:

Konsol Google Cloud

Anda mengonfigurasi opsi penggabungan di langkah Multi-condition trigger.

API

Anda mengonfigurasi opsi penggabungan 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:

Konsol Google Cloud
Nilai pemicu kebijakan		 Nilai penggabungan
Cloud Monitoring API		 Arti
Kondisi apa pun terpenuhi OR Insiden akan dibuka jika ada resource yang menyebabkan salah satu kondisi terpenuhi.
Semua kondisi terpenuhi
bahkan untuk resource
yang berbeda untuk setiap kondisi
(default)		 AND Insiden akan dibuka jika setiap kondisi terpenuhi, meskipun resource yang menyebabkan kondisi tersebut terpenuhi bersifat berbeda.
Semua kondisi terpenuhi AND_WITH_MATCHING_RESOURCE Insiden akan dibuka jika resource yang sama menyebabkan setiap kondisi terpenuhi. Setelan ini adalah pilihan penggabungan yang paling ketat.

Dalam konteks ini, istilah met berarti konfigurasi kondisi dievaluasi menjadi true. Misalnya, jika konfigurasinya adalah Any time series is greater than 10 for 5 minutes, maka saat pernyataan ini dievaluasi menjadi 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 apa pun lebih besar dari 100 md/s selama 1 menit.
  • Kondisi bernama Excessive utilization memantau penggunaan CPU instance. Kondisi ini terpenuhi jika penggunaan 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 selama satu menit, kondisi CPU usage is too high terpenuhi. Jika kondisi digabungkan dengan Any condition is met, insiden akan dibuat karena 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 penggabungan ini mengharuskan kedua kondisi terpenuhi.

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

  • Semua kondisi terpenuhi: Insiden 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, hal itu juga akan mengakibatkan 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 penggabungan ini memerlukan resource yang sama untuk 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

Jika data deret waktu berhenti diterima atau jika data tertunda, Pemantauan akan mengklasifikasikan data sebagai tidak ada. Data yang tidak ada dapat mencegah insiden ditutup. Keterlambatan data yang diterima dari penyedia cloud pihak ketiga dapat mencapai 30 menit, dengan keterlambatan 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, Pemantauan mungkin telah kehilangan beberapa histori kondisi terbaru. Pemeriksaan data deret waktu di lain waktu mungkin tidak mengungkapkan masalah ini karena tidak ada bukti keterlambatan setelah data tiba.

Konsol Google Cloud

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

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

  • Untuk mengonfigurasi cara Pemantauan menentukan nilai penggantian untuk data yang hilang, gunakan kolom Evaluasi data yang hilang yang Anda tetapkan di langkah Pemicu kondisi. Kolom ini dinonaktifkan jika periode pengujian ulang ditetapkan ke Tidak ada pengujian ulang.

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

  • Untuk mengonfigurasi waktu tunggu Monitoring sebelum menutup insiden yang terbuka setelah data berhenti masuk, gunakan kolom Durasi penutupan insiden otomatis. Anda menetapkan durasi penutupan otomatis di langkah Notifikasi. Durasi penutupan otomatis default adalah tujuh hari.

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

Konsol Google Cloud
Kolom "Evaluasi data yang tidak ada"		 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 masuk. Jika insiden terbuka untuk kondisi ini, insiden akan tetap terbuka. Saat insiden terbuka dan tidak ada data yang masuk, penghitung waktu tutup otomatis akan dimulai setelah penundaan minimal 15 menit. Jika timer berakhir, insiden akan ditutup.

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

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

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

Untuk kondisi yang terpenuhi, kondisi tersebut berhenti terpenuhi saat data berhenti masuk. Jika insiden terbuka untuk kondisi ini, insiden 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 insiden terbuka dan pengukuran yang diharapkan tidak tiba, apakah Anda ingin Pemantauan membiarkan insiden terbuka atau segera menutupnya? Demikian pula, saat data berhenti masuk dan tidak ada insiden yang terbuka, apakah Anda ingin insiden dibuka? Terakhir, berapa lama insiden harus tetap terbuka setelah data berhenti masuk?

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

  • Untuk mengonfigurasi cara Monitoring menentukan nilai penggantian 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 insiden yang 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 Insiden terbuka tetap terbuka.
Insiden baru tidak dibuka.

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

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

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

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

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

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

Anda dapat meminimalkan masalah karena data yang tidak ada dengan melakukan salah satu hal 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 karena membuat kebijakan pemberitahuan Anda kurang responsif.

  • Pilih metrik yang memiliki penundaan pengumpulan yang lebih rendah:

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

Untuk informasi selengkapnya, lihat Ringkasan agen pemantauan, Ringkasan metrik yang ditentukan pengguna, dan metrik berbasis log.

Saat Pemantauan mengirim notifikasi dan membuat insiden

Cloud Monitoring mengirim notifikasi saat deret waktu menyebabkan kondisi terpenuhi. Notifikasi dikirim ke semua saluran notifikasi. Anda tidak dapat membatasi notifikasi ke channel tertentu atau ke sebagian 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 yang terkait dengan satu kebijakan pemberitahuan jika salah satu hal berikut berlaku:

  • 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 menghasilkan kondisi terpenuhi, kebijakan pemberitahuan akan mengirim notifikasi dan membuat insiden.

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

    • Setiap kondisi terpenuhi: Kebijakan pemberitahuan mengirim 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 akan memberi tahu Anda saat kondisi terpenuhi dan saat kondisi berhenti terpenuhi. Kebijakan pemberitahuan yang dibuat menggunakan konsol Google Cloud tidak akan mengirim notifikasi saat kondisi berhenti terpenuhi, kecuali jika Anda telah mengaktifkan perilaku tersebut.

Saat Pemantauan tidak mengirim notifikasi atau membuat insiden

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

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

Kebijakan pemberitahuan yang dinonaktifkan

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

Saat Anda mengaktifkan kebijakan yang dinonaktifkan, Pemantauan 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, proses tersebut 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 tersebut belum aktif selama lima menit terakhir dan membuka insiden.

Insiden yang terkait dengan kebijakan pemberitahuan yang dinonaktifkan tetap terbuka hingga masa berlaku durasi penutupan otomatis kebijakan berakhir.

Menunda kebijakan pemberitahuan

Pemantauan tidak mengirim notifikasi atau membuat insiden untuk kebijakan pemberitahuan yang ditangguhkan. Sebaiknya tunda kebijakan pemberitahuan jika Anda ingin mencegah kebijakan pemberitahuan mengirim 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 insiden terbuka yang terkait dengan kebijakan tersebut. Pemantauan dapat membuka insiden baru setelah penundaan berakhir. Untuk mengetahui informasinya, lihat Menunda notifikasi dan pemberitahuan.

Batasan notifikasi dan insiden terbuka

Kebijakan pemberitahuan dapat diterapkan ke 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 sistem, jumlah insiden yang dapat dibuka oleh satu kebijakan secara bersamaan dibatasi hingga 1.000.

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

Akibat 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 terpisah.

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, Pemantauan tidak akan membuat insiden 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 selama 60 hingga 90 detik. Untuk metrik AWS CloudWatch, penundaan visibilitas dapat berlangsung beberapa menit. Untuk pemeriksaan waktu aktif, waktu ini dapat rata-rata dua menit (dari akhir periode pengujian ulang).

  • Retest window: Periode yang dikonfigurasi untuk kondisi. Kondisi hanya terpenuhi jika kondisi tersebut benar selama periode pengujian ulang. Misalnya, setelan periode pengujian ulang lima menit menyebabkan keterlambatan notifikasi setidaknya lima menit sejak peristiwa pertama kali terjadi.

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

Langkah selanjutnya