Perilaku kebijakan pemberitahuan berbasis metrik

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

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 tes 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 diregularisasi sehingga kebijakan pemberitahuan memiliki data yang berjarak teratur untuk dievaluasi. Proses regularisasi disebut penyelarasan.

Penyelarasan melibatkan dua langkah:

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

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

    Untuk mengetahui informasi selengkapnya tentang perataan, lihat Perataan: 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.

Pemantauan mengonfigurasi periode penyelarasan sebagai berikut:

Google Cloud console

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

  • Periode bergulir: Menentukan rentang waktu yang akan dievaluasi.
  • Fungsi jendela geser: 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 penyesuai 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 penyesuai 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 menggambarkan efek periode perataan pada 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 penyelarasan disetel ke sum. Selain itu, asumsikan bahwa kondisi terpenuhi jika nilai deret waktu yang selaras lebih besar dari dua selama setidaknya tiga menit, dan kondisi dievaluasi setiap menit. Dalam contoh ini, periode pengujian ulang, yang dijelaskan di bagian berikutnya, adalah tiga menit. Gambar berikut mengilustrasikan beberapa evaluasi berurutan kondisi:

Gambar yang menggambarkan efek periode penyelarasan pada jendela/durasi tes ulang.

Setiap baris dalam gambar mengilustrasikan satu evaluasi kondisi. Data deret waktu ditampilkan. Poin 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 daripada 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, anggaplah periode pengujian ulang suatu kondisi ditetapkan ke 15 menit. Berikut ini menjelaskan perilaku kondisi berdasarkan jenisnya:

  • Kondisi batas metrik terpenuhi jika, untuk satu deret waktu, setiap pengukuran yang selaras dalam interval 15 menit melanggar batas.
  • Kondisi tidak adanya metrik terpenuhi jika tidak ada data yang tiba 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 dikirim saat kondisi terpenuhi. Insiden ini tetap terbuka selama kondisi terus terpenuhi.

Google Cloud console

Anda mengonfigurasi periode pengujian ulang menggunakan kolom Periode pengujian ulang di langkah Konfigurasi pemicu pemberitahuan.

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 daripada nilai minimum; namun, kondisi tidak terpenuhi karena periode pengujian ulang ditetapkan ke tiga menit. Gambar berikut menggambarkan hasil untuk evaluasi kondisi berikutnya:

Gambar yang mengilustrasikan efek periode tes ulang.

Meskipun nilai yang diselaraskan lebih besar daripada nilai minimum pada waktu start + 2 minutes, kondisi tidak terpenuhi hingga nilai yang diselaraskan lebih besar daripada 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. 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 tes 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 jendela 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 mengirimkan notifikasi saat kondisi terpenuhi.

Tetapkan periode pengujian ulang yang cukup lama untuk meminimalkan positif palsu, tetapi cukup singkat untuk memverifikasi bahwa insiden dibuka tepat waktu.

Praktik terbaik untuk menetapkan periode penyelarasan dan periode pengujian ulang

Periode penyelarasan menentukan jumlah sampel yang digabungkan dengan penyelarasan:

  • Nilai minimum periode penyelarasan untuk jenis metrik adalah periode pengambilan sampel jenis metrik tersebut. Misalnya, jika jenis metrik diambil sampelnya setiap 300 detik, maka periode penyelarasan 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, maka nilai maksimum periode penyelarasan adalah 18 jam.

Gunakan periode pengujian ulang untuk menentukan responsivitas pemberitahuan. Misalnya, jika Anda menyetel periode pengujian ulang ke 20 menit untuk kondisi tidak adanya 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 kebijakan pemberitahuan paling responsif, tetapkan jendela pengujian ulang ke nol. Satu nilai yang selaras 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 Anda menggunakan Cloud Monitoring API atau jika kebijakan pemberitahuan Anda memiliki beberapa kondisi, Anda harus menentukan kapan insiden dibuka. Untuk mengonfigurasi cara menggabungkan beberapa kondisi, lakukan salah satu hal berikut:

Google Cloud console

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:

Nilai pemicu kebijakanGoogle Cloud console
 Nilai penggabung Cloud Monitoring API
 Arti
Kondisi apa pun terpenuhi OR Insiden dibuka jika ada resource yang menyebabkan salah satu kondisi terpenuhi.
Semua kondisi terpenuhi
meskipun untuk
resource yang berbeda untuk setiap kondisi
(default)		 AND Insiden dibuka untuk setiap kondisi yang terpenuhi saat semua kondisi terpenuhi, meskipun resource lain menyebabkan kondisi tersebut terpenuhi.
Semua kondisi terpenuhi AND_WITH_MATCHING_RESOURCE Insiden dibuka untuk setiap kondisi yang terpenuhi jika semua kondisi terpenuhi, hanya jika resource yang sama menyebabkan setiap kondisi terpenuhi. Setelan ini adalah setelan yang paling ketat untuk menggabungkan pilihan.

Dalam konteks ini, istilah terpenuhi berarti konfigurasi kondisi dievaluasi sebagai benar. Misalnya, jika konfigurasi adalah Any time series is greater than 10 for 5 minutes, maka saat pernyataan ini dievaluasi sebagai benar, 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/dtk selama 1 menit.
  • Kondisi bernama Excessive utilization memantau pemakaian CPU instance. Kondisi ini terpenuhi jika pemakaian CPU instance apa pun lebih dari 60% selama 1 menit.

Awalnya, asumsikan bahwa kedua kondisi bernilai salah (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 Kondisi apa pun terpenuhi, maka insiden dibuat karena suatu kondisi terpenuhi. Jika kondisi digabungkan dengan Semua kondisi terpenuhi atau Semua kondisi terpenuhi meskipun untuk resource yang berbeda untuk setiap kondisi, maka insiden tidak akan dibuat. Pilihan penggabung ini mengharuskan kedua kondisi terpenuhi.

Selanjutnya, asumsikan bahwa penggunaan CPU vm1 tetap lebih besar dari 100 ms/s dan bahwa pemakaian 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: 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, maka hal 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 meskipun 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 sementara vm2 menyebabkan Excessive utilization terpenuhi.

Data metrik sebagian

Jika data deret waktu berhenti tiba atau jika data tertunda, Monitoring mengklasifikasikan data sebagai tidak ada. Data yang tidak ada dapat mencegah penutupan insiden. Keterlambatan kedatangan data dari penyedia cloud pihak ketiga bisa mencapai 30 menit, dengan keterlambatan 5-15 menit menjadi 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 selanjutnya mungkin tidak mengungkapkan masalah ini karena tidak ada bukti keterlambatan setelah data tiba.

Google Cloud console

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

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

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

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

  • Untuk mengonfigurasi berapa lama Pemantauan menunggu sebelum menutup insiden terbuka setelah data berhenti tiba, gunakan kolom Durasi penutupan insiden otomatis. Anda menetapkan durasi penutupan otomatis di langkah Notifikasi. Durasi tutup otomatis default adalah tujuh hari.

Berikut ini penjelasan berbagai opsi untuk kolom data yang hilang:

Google Cloud konsol
Kolom "Evaluasi data yang tidak ada"		 Ringkasan Detail
Data yang tidak ada kosong Insiden terbuka akan 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, maka insiden akan tetap terbuka. Jika 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 akan terus tidak terpenuhi saat data berhenti tiba.
Titik data yang tidak ada diperlakukan sebagai nilai yang melanggar kondisi kebijakan Insiden terbuka akan 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, maka insiden akan tetap terbuka. Jika insiden dibuka dan tidak ada data yang masuk selama durasi tutup 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, maka kondisi 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 berhenti terpenuhi saat data berhenti tiba. Jika insiden terbuka untuk kondisi ini, maka insiden ditutup.

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

API

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

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 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 tiba, gunakan kolom autoClose dalam struktur AlertStrategy.

Berikut ini penjelasan berbagai opsi untuk kolom data yang hilang:

Kolom
evaluationMissingData API		 Ringkasan Detail
EVALUATION_MISSING_DATA_UNSPECIFIED Insiden terbuka akan 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 akan tetap terbuka. Jika insiden terbuka dan tidak ada data yang masuk, timer tutup otomatis akan dimulai setelah penundaan setidaknya 15 menit. Jika timer berakhir, insiden akan ditutup.

Untuk kondisi yang tidak terpenuhi, kondisi tersebut akan terus tidak terpenuhi saat data berhenti tiba.
EVALUATION_MISSING_DATA_ACTIVE Insiden terbuka akan 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 akan tetap terbuka. Jika insiden terbuka dan tidak ada data yang tiba selama durasi tutup 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`, maka 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 berhenti terpenuhi saat data berhenti tiba. Jika insiden terbuka untuk kondisi ini, maka insiden ditutup.

Untuk kondisi yang tidak terpenuhi, kondisi tersebut akan terus tidak 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 pengujian ulang yang lebih panjang dalam kondisi Anda. Menggunakan periode pengujian ulang yang lebih panjang memiliki kekurangan 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 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.

Waktu Monitoring mengirimkan notifikasi dan membuat insiden

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

Jika Anda mengonfigurasi notifikasi berulang, maka 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 terjadi:

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

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

    • Kondisi apa pun 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 tidak lagi terpenuhi. Kebijakan pemberitahuan yang dibuat menggunakan konsol Google Cloud tidak mengirimkan notifikasi saat kondisi tidak lagi terpenuhi, kecuali jika Anda telah mengaktifkan perilaku tersebut.

Saat Monitoring 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 mengirimkan pembuatan insiden atau mengirimkan 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 dapat mencakup data yang diambil sebelum, selama, dan setelah kebijakan diaktifkan. Kondisi kebijakan yang dinonaktifkan dapat dipenuhi segera setelah melanjutkan kebijakan, bahkan dengan periode pengujian ulang yang besar.

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

Insiden 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 insiden untuk kebijakan pemberitahuan yang ditunda. 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 insiden terbuka yang terkait dengan kebijakan tersebut. Pemantauan dapat membuka insiden baru setelah penundaan berakhir. Untuk mengetahui informasi, lihat Menunda notifikasi dan insiden.

Batasan notifikasi dan insiden terbuka

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 terpenuhi.

Untuk mencegah kelebihan beban sistem, jumlah insiden 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. Pemantauan membatasi jumlah insiden terbuka hingga 1.000. Kondisi yang terpenuhi lainnya 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 menjadi terlihat sebagai data deret waktu. Latensi memengaruhi waktu pengiriman notifikasi. Misalnya, jika metrik yang dipantau memiliki latensi hingga 180 detik, maka Monitoring tidak akan membuat insiden hingga 180 detik setelah kondisi kebijakan pemberitahuan dievaluasi sebagai benar. Untuk mengetahui informasi selengkapnya, lihat Latensi data metrik.

Peristiwa dan setelan berikut berkontribusi terhadap 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. Penghitungan kebijakan pemberitahuan memerlukan penundaan tambahan hingga 5 menit 30 detik. Untuk metrik AWS CloudWatch, penundaan visibilitas dapat terjadi selama beberapa menit. Untuk pemeriksaan waktu aktif, ini bisa berupa rata-rata dua menit (dari akhir periode pengujian ulang).

  • Periode pengujian ulang: Periode yang dikonfigurasi untuk kondisi. Kondisi hanya terpenuhi jika kondisi benar selama periode pengujian ulang. Misalnya, setelan periode tes ulang lima menit menyebabkan penundaan notifikasi setidaknya lima menit dari saat peristiwa pertama kali terjadi.

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

Langkah berikutnya