Mengelola biaya pemberitahuan

Mulai April 2025, Cloud Monitoring akan mulai mengenakan biaya atas penggunaan kebijakan pemberitahuan. Untuk informasi tentang model harga. Harga untuk pemberitahuan.

Dokumen ini menjelaskan strategi yang dapat Anda gunakan untuk mengurangi biaya pemberitahuan.

Mengonsolidasikan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource

Karena biayanya $1,50 per kondisi, lebih hemat biaya penggunaan 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 menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi pemberitahuan
  • Menggabungkan kondisi ke level VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • 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 menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • 100 kondisi
  • Setiap kondisi difilter dan digabungkan ke dalam satu VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • 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 tersebut, 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.

Gabungkan ke level yang perlu Anda buat notifikasinya

Penggabungan ke tingkat perincian yang lebih tinggi menghasilkan biaya yang lebih tinggi daripada mengagregasikan ke tingkat perincian yang lebih rendah. Misalnya, menggabungkan ke level project Google Cloud lebih murah daripada tingkat cluster, dan menggabungkan ke tingkat cluster lebih murah daripada menggabungkan ke tingkat cluster dan namespace.

Perhatikan contoh berikut:

Contoh 1

Data

  • 100 VM
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi pemberitahuan
  • Menggabungkan kondisi ke level VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • 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 termasuk dalam satu layanan
  • Lima layanan total
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi
  • Menggabungkan kondisi ke tingkat layanan
  • Periode eksekusi selama 30 detik
Hasil biaya
  • 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 menghasilkan satu metrik, metric_name
  • metric_name memiliki 100 label yang masing-masing berisi 1.000 nilai
Kebijakan pemberitahuan
  • Satu kondisi
  • Menggabungkan kondisi ke level VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • 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 pada data pokok yang sama dan memiliki satu peringatan lebih lanjut. Namun, karena kebijakan pemberitahuan di Contoh 4 digabungkan ke layanan, lebih murah daripada kebijakan pemberitahuan di Contoh 1, yang secara lebih terperinci ke VM.

Selain itu, bandingkan Contoh 1 dengan Contoh 5: Dalam hal ini, kardinalitas metrik di Contoh 5 10.000 kali lebih tinggi dari kardinalitas metrik di Contoh 1. Namun, karena kebijakan pemberitahuan di Contoh 1 dan dalam Contoh 5 digabungkan ke VM, dan karena jumlah VM di kedua contoh itu sama, contohnya setara harga.

Saat mengonfigurasi kebijakan pemberitahuan, pilih tingkat agregasi yang paling cocok untuk kasus penggunaan Anda. Misalnya, jika Anda ingin memberi peringatan pada CPU tingkat pemakaian, maka Anda mungkin ingin menggabungkan ke level VM dan CPU. Jika Anda memperhatikan pemberitahuan latensi oleh endpoint, maka Anda mungkin ingin ke level endpoint.

Jangan beri tahu tentang data mentah yang tidak diagregasi

Pemantauan menggunakan sistem metrik dimensi, di mana setiap metrik memiliki total [kardinalitas][kardinalitas] sama dengan jumlah resource yang dipantau dikalikan dengan jumlah kombinasi label pada metrik tersebut. Sebagai jika Anda memiliki 100 VM yang memunculkan metrik, dan metrik tersebut memiliki 10 label dengan masing-masing 10 nilai, maka total kardinalitas Anda adalah 100 * 10 * 10 = 10.000.

Karena bagaimana kardinalitas melakukan penskalaan, pemberitahuan data mentah bisa sangat mahal. Pada contoh sebelumnya, Anda memiliki 10.000 deret waktu yang ditampilkan untuk setiap periode eksekusi. Namun, jika Anda melakukan agregasi ke VM, maka Anda memiliki hanya 100 deret waktu yang ditampilkan per periode eksekusi, terlepas dari labelnya kardinalitas data pokok.

Memberi tahu 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, maka total kardinalitas Anda akan meningkat menjadi 100 * 11 * 10 = 11.000 deret waktu. Dalam hal ini, jumlah pengembalian deret waktu meningkat 1.000 setiap periode eksekusi meskipun pemberitahuan kebijakan tidak berubah. Jika Anda memilih melakukan agregasi ke VM, meskipun peningkatan kardinalitas dasar, Anda tetap hanya memiliki 100 deret waktu yang ditampilkan.

Memfilter respons yang tidak perlu

Konfigurasi kondisi Anda untuk hanya mengevaluasi data yang diperlukan bagi kebutuhan pemberitahuan lebih lanjut. Jika Anda tidak akan mengambil tindakan untuk memperbaiki sesuatu, kecualikan dari kebijakan pemberitahuan Anda. Misalnya, Anda mungkin tidak perlu memberi tahu di VM pengembangan pekerja magang.

Untuk mengurangi pemberitahuan 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 dan kemudian menyaring kategori {i>metadata<i} yang tidak diperlukan.

Menggunakan operator streaming teratas untuk mengurangi jumlah deret waktu yang ditampilkan

Jika kondisi Anda menggunakan kueri PromQL atau MQL, maka Anda dapat menggunakan operator top-stream untuk memilih sejumlah deret waktu yang ditampilkan dengan nilai tertinggi:

Misalnya, klausa topk(metric, 5) dalam batas kueri PromQL jumlah deret waktu yang dikembalikan menjadi lima di setiap periode eksekusi.

Membatasi ke jumlah deret waktu teratas dapat mengakibatkan hilangnya data dan pemberitahuan yang salah, seperti:

  • Jika lebih dari N deret waktu melanggar batas, 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 tertutup otomatis meskipun deret waktu yang dikecualikan tetap yang melanggar batas.
  • Kueri kondisi Anda mungkin tidak menunjukkan konteks penting seperti dasar pengukuran deret waktu yang berfungsi sebagaimana mestinya.

Untuk mengurangi risiko tersebut, pilih nilai besar untuk N dan gunakan aliran data teratas operator hanya dalam kebijakan pemberitahuan yang mengevaluasi banyak deret waktu, seperti untuk setiap container Kubernetes.

Menambah durasi periode eksekusi (khusus PromQL)

Jika kondisi Anda menggunakan kueri PromQL, Anda dapat mengubah durasinya periode eksekusi dengan menetapkan Kolom evaluationInterval di kondisi.

Interval evaluasi yang lebih lama menghasilkan deret waktu yang lebih sedikit per bulan; misalnya, kueri kondisi dengan interval 15 detik berjalan dua kali lebih sering sebagai kueri dengan interval 30 detik, dan kueri dengan interval 1 menit berjalan setengah lebih sering dibandingkan kueri dengan interval 30 detik.