Dokumen ini menjelaskan strategi yang dapat Anda gunakan untuk mengurangi biaya pemberitahuan.
Menggabungkan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource
Karena biaya $1,50 per kondisi, lebih hemat biaya untuk menggunakan satu kebijakan pemberitahuan guna memantau beberapa resource daripada menggunakan satu kebijakan pemberitahuan untuk memantau setiap resource. Perhatikan contoh berikut:
Contoh 1
Data
- 100 VM
- Setiap VM memunculkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- Satu kondisi pemberitahuan
- Kondisi digabungkan ke tingkat VM
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 per bulan
- Biaya deret waktu: 100 deret waktu yang ditampilkan per periode * 86.400 periode per bulan = 8,6 juta deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $3,02 per bulan
- Total biaya: $4,52 per bulan
Contoh 2
Data
- 100 VM
- Setiap VM memunculkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- 100 kondisi
- Setiap kondisi difilter dan digabungkan ke satu VM
- Periode eksekusi 30 detik
- Biaya kondisi: 100 kondisi * $1,50 per bulan = $150 per bulan
- Biaya deret waktu: 100 kondisi * 1 deret waktu yang ditampilkan per kondisi per periode * 86.400 periode per bulan = 8,6 juta deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $3,02 per bulan
- Total biaya: $153,02 per bulan
Dalam kedua contoh, Anda memantau jumlah resource yang sama. Namun, Contoh 2 menggunakan 100 kebijakan pemberitahuan, sedangkan Contoh 1 hanya menggunakan satu kebijakan pemberitahuan. Akibatnya, Contoh 1 hampir $150 lebih murah per bulan.
Menggabungkan hanya ke tingkat yang perlu Anda beri pemberitahuan
Agregasi ke tingkat perincian yang lebih tinggi akan menghasilkan biaya yang lebih tinggi daripada agregasi ke tingkat perincian yang lebih rendah. Misalnya, agregasi ke tingkat project Google Cloud lebih murah daripada agregasi ke tingkat cluster, dan agregasi ke tingkat cluster lebih murah daripada agregasi ke tingkat cluster dan namespace.
Perhatikan contoh berikut:
Contoh 1
Data
- 100 VM
- Setiap VM memunculkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- Satu kondisi pemberitahuan
- Kondisi digabungkan ke tingkat VM
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 per bulan
- Biaya deret waktu: 100 deret waktu yang ditampilkan per periode * 86.400 periode per bulan = 8,6 juta deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $3,02 per bulan
- Total biaya: $4,52 per bulan
Contoh 4
Data
- 100 VM, dengan setiap VM milik satu layanan
- Total lima layanan
- Setiap VM memunculkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- Satu kondisi
- Kondisi digabungkan ke tingkat layanan
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 per bulan
- Biaya deret waktu: 5 deret waktu yang ditampilkan per periode * 86.400 periode per bulan = 432.000 deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $0,14 per bulan
- Total biaya: $1,64 per bulan
Contoh 5
Data
- 100 VM
- Setiap VM memunculkan satu metrik,
metric_name metric_namememiliki 100 label dengan masing-masing 1.000 nilai
- Satu kondisi
- Kondisi digabungkan ke tingkat VM
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 per bulan
- Biaya deret waktu: 100 deret waktu yang ditampilkan per periode * 86.400 periode per bulan = 8,5 juta deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $3,02 per bulan
- Total biaya: $4,52 per bulan
Bandingkan Contoh 1 dengan Contoh 4: Kedua contoh beroperasi berdasarkan data dasar yang sama dan memiliki satu kebijakan pemberitahuan. Namun, karena kebijakan pemberitahuan dalam Contoh 4 digabungkan ke layanan, biayanya lebih murah daripada kebijakan pemberitahuan dalam Contoh 1, yang digabungkan secara lebih terperinci ke VM.
Selain itu, bandingkan Contoh 1 dengan Contoh 5: Dalam hal ini, kardinalitas metrik dalam Contoh 5 10.000 kali lebih tinggi daripada kardinalitas metrik dalam Contoh 1. Namun, karena kebijakan pemberitahuan dalam Contoh 1 dan Contoh 5 digabungkan ke VM, dan karena jumlah VM sama di kedua contoh, harganya setara.
Saat mengonfigurasi kebijakan pemberitahuan, pilih tingkat agregasi yang paling sesuai untuk kasus penggunaan Anda. Misalnya, jika Anda ingin mendapatkan pemberitahuan tentang penggunaan CPU, sebaiknya gabungkan ke tingkat VM dan CPU. Jika Anda ingin mendapatkan pemberitahuan tentang latensi menurut endpoint, sebaiknya gabungkan ke tingkat endpoint.
Jangan membuat pemberitahuan untuk data mentah yang tidak digabungkan
Pemantauan menggunakan sistem metrik dimensi, dengan setiap metrik memiliki total [cardinality][cardinality] yang sama dengan jumlah resource yang dimonitor dikalikan dengan jumlah kombinasi label pada metrik tersebut. Misalnya, jika Anda memiliki 100 VM yang memunculkan metrik, dan metrik tersebut memiliki 10 label dengan masing-masing 10 nilai, kardinalitas total Anda adalah 100 * 10 * 10 = 10.000.
Karena cara kardinalitas diskalakan, pemberitahuan pada data mentah dapat sangat mahal. Pada contoh sebelumnya, Anda memiliki 10.000 deret waktu yang ditampilkan untuk setiap periode eksekusi. Namun, jika Anda menggabungkan ke VM, Anda hanya memiliki 100 deret waktu yang ditampilkan per periode eksekusi, terlepas dari kardinalitas label data pokok.
Pemberian notifikasi pada data mentah juga membuat Anda berisiko mengalami peningkatan deret waktu saat metrik Anda menerima label baru. Pada contoh sebelumnya, jika pengguna menambahkan label baru ke metrik, kardinalitas total Anda akan meningkat menjadi 100 * 11 * 10 = 11.000 deret waktu. Dalam hal ini, jumlah deret waktu yang ditampilkan akan meningkat sebesar 1.000 setiap periode eksekusi meskipun kebijakan pemberitahuan Anda tidak berubah. Jika Anda menggabungkan ke VM, meskipun kardinalitas yang mendasarinya meningkat, Anda tetap hanya akan menampilkan 100 deret waktu.
Memfilter respons yang tidak perlu
Konfigurasikan kondisi Anda untuk hanya mengevaluasi data yang diperlukan untuk kebutuhan pemberitahuan Anda. Jika Anda tidak akan mengambil tindakan untuk memperbaiki sesuatu, kecualikan hal tersebut dari kebijakan pemberitahuan Anda. Misalnya, Anda mungkin tidak perlu memberi tahu VM pengembangan intern.
Untuk mengurangi notifikasi dan biaya yang tidak perlu, Anda dapat memfilter deret waktu yang tidak penting. Anda dapat menggunakan Google Cloud label metadata untuk memberi tag pada aset dengan kategori, lalu memfilter kategori metadata yang tidak diperlukan.
Menggunakan operator aliran teratas untuk mengurangi jumlah deret waktu yang ditampilkan
Jika kondisi Anda menggunakan kueri PromQL atau MQL, Anda dapat menggunakan operator aliran teratas untuk memilih sejumlah deret waktu yang ditampilkan dengan nilai tertinggi:
Misalnya, klausa topk(metric, 5) dalam kueri PromQL membatasi
jumlah deret waktu yang ditampilkan menjadi lima dalam setiap periode eksekusi.
Membatasi jumlah deret waktu teratas dapat menyebabkan data hilang dan pemberitahuan yang salah, seperti:
- Jika lebih dari N deret waktu melanggar nilai minimum, Anda akan kehilangan data di luar deret waktu N teratas.
- Jika deret waktu yang melanggar terjadi di luar deret waktu N teratas, insiden Anda mungkin ditutup secara otomatis meskipun deret waktu yang dikecualikan masih melanggar nilai minimum.
- Kueri kondisi Anda mungkin tidak menampilkan konteks penting seperti deret waktu dasar pengukuran yang berfungsi sebagaimana mestinya.
Untuk mengurangi risiko tersebut, pilih nilai besar untuk N dan gunakan operator top-stream hanya dalam kebijakan pemberitahuan yang mengevaluasi banyak deret waktu, seperti pemberitahuan untuk setiap penampung Kubernetes.
Meningkatkan durasi periode eksekusi (khusus PromQL)
Jika kondisi Anda menggunakan kueri PromQL, Anda dapat mengubah durasi
periode eksekusi dengan menetapkan
kolom evaluationInterval di
condition.
Interval evaluasi yang lebih lama akan menghasilkan lebih sedikit deret waktu yang ditampilkan per bulan; misalnya, kueri kondisi dengan interval 15 detik berjalan dua kali lebih sering daripada kueri dengan interval 30 detik, dan kueri dengan interval 1 menit berjalan setengah lebih sering daripada kueri dengan interval 30 detik.