Mulai paling cepat 1 Mei 2026, Cloud Monitoring akan mulai mengenakan biaya untuk penggunaan kebijakan pemberitahuan. Untuk mengetahui informasi tentang model harga, lihat Ringkasan harga Cloud Monitoring.
Dokumen ini menjelaskan strategi yang dapat Anda gunakan untuk mengurangi biaya pemberitahuan.
Menggabungkan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource
Karena biaya per kondisi adalah $0,10, maka lebih hemat biaya menggunakan satu kebijakan pemberitahuan untuk memantau beberapa resource daripada menggunakan satu kebijakan pemberitahuan untuk memantau setiap resource. Perhatikan contoh berikut:
Contoh 1
Data
- 100 VM
- Setiap VM memancarkan 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 * $0,10 per bulan = $0,10 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: $3,12 per bulan
Contoh 2
Data
- 100 VM
- Setiap VM memancarkan 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 * $0,10 per bulan = $10 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: $13,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 $10 lebih murah per bulan.
Gabungkan hanya ke tingkat yang perlu Anda beri tahu
Menggabungkan ke tingkat perincian yang lebih tinggi akan menghasilkan biaya yang lebih tinggi daripada menggabungkan ke tingkat perincian yang lebih rendah. Misalnya, menggabungkan ke level project Google Cloud lebih murah daripada menggabungkan ke level cluster, dan menggabungkan ke level cluster lebih murah daripada menggabungkan ke level cluster dan namespace.
Perhatikan contoh berikut:
Contoh 1
Data
- 100 VM
- Setiap VM memancarkan 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 * $0,10 per bulan = $0,10 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: $3,12 per bulan
Contoh 4
Data
- 100 VM, dengan setiap VM termasuk dalam satu layanan
- Total lima layanan
- Setiap VM memancarkan 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 * $0,10 per bulan = $0,10 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: $0,24 per bulan
Contoh 5
Data
- 100 VM
- Setiap VM memancarkan 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 * $0,10 per bulan = $0,10 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: $3,12 per bulan
Bandingkan Contoh 1 dengan Contoh 4: Kedua contoh beroperasi pada data pokok yang sama dan memiliki satu kebijakan pemberitahuan. Namun, karena kebijakan pemberitahuan dalam Contoh 4 digabungkan ke layanan, kebijakan tersebut 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 sama-sama digabungkan ke VM, dan karena jumlah VM sama dalam kedua contoh, harga kedua contoh tersebut setara.
Saat mengonfigurasi kebijakan pemberitahuan, pilih tingkat agregasi yang paling sesuai untuk kasus penggunaan Anda. Misalnya, jika Anda ingin mendapatkan pemberitahuan tentang pemakaian CPU, Anda mungkin ingin melakukan agregasi ke tingkat VM dan CPU. Jika Anda memperhatikan pemberitahuan tentang latensi menurut endpoint, sebaiknya gabungkan ke tingkat endpoint.
Jangan membuat pemberitahuan untuk data mentah yang tidak diagregasi
Monitoring menggunakan sistem metrik dimensi, di mana setiap metrik memiliki kardinalitas total yang sama dengan jumlah resource yang dipantau dikalikan dengan jumlah kombinasi label pada metrik tersebut. Misalnya, jika Anda memiliki 100 VM yang memancarkan metrik, dan metrik tersebut memiliki 10 label dengan 10 nilai masing-masing, maka kardinalitas total Anda adalah 100 * 10 * 10 = 10.000.
Akibat penskalaan kardinalitas, pemberitahuan tentang data mentah bisa sangat mahal. Dalam contoh sebelumnya, Anda memiliki 10.000 deret waktu yang ditampilkan untuk setiap periode eksekusi. Namun, jika Anda melakukan agregasi ke VM, maka hanya 100 deret waktu yang ditampilkan per periode eksekusi, terlepas dari kardinalitas label data pokok.
Membuat pemberitahuan tentang data mentah juga membuat Anda berisiko mengalami peningkatan deret waktu saat metrik Anda menerima label baru. Dalam contoh sebelumnya, jika pengguna menambahkan label baru ke metrik Anda, total kardinalitas Anda akan meningkat menjadi 100 * 11 * 10 = 11.000 deret waktu. Dalam hal ini, jumlah deret waktu yang ditampilkan akan bertambah 1.000 setiap periode eksekusi meskipun kebijakan pemberitahuan Anda tidak berubah. Jika Anda menggabungkan ke VM, meskipun kardinalitas yang mendasarinya meningkat, Anda tetap hanya memiliki 100 deret waktu yang ditampilkan.
Memfilter respons yang tidak perlu
Konfigurasi kondisi Anda untuk mengevaluasi hanya 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 membuat pemberitahuan di VM pengembangan intern.
Untuk mengurangi insiden dan biaya yang tidak perlu, Anda dapat memfilter deret waktu yang tidak penting. Anda dapat menggunakan label metadata Google Cloud 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, Anda dapat menggunakan operator aliran teratas untuk memilih sejumlah deret waktu yang ditampilkan dengan nilai tertinggi:
- PromQL:
topk
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 insiden salah, seperti:
- Jika lebih dari N deret waktu melanggar nilai minimum, Anda akan kehilangan data di luar N deret waktu teratas.
- Jika deret waktu yang melanggar terjadi di luar deret waktu N teratas, maka insiden Anda dapat ditutup secara otomatis meskipun deret waktu yang dikecualikan masih melanggar nilai minimum.
- Kueri kondisi Anda mungkin tidak menampilkan konteks penting seperti deret waktu dasar 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 insiden 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 panjang 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.