Mengelola biaya pemberitahuan

Dokumen ini menjelaskan strategi yang dapat Anda gunakan untuk mengurangi biaya pemberitahuan. Untuk mengetahui informasi tentang model harga, lihat Harga Google Cloud Observability.

Menggabungkan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource

Pemberitahuan mengenakan biaya per kondisi. Oleh karena itu, jika memungkinkan, gunakan satu kebijakan pemberitahuan untuk memantau beberapa resource, bukan membuat satu kebijakan pemberitahuan untuk setiap resource.

Misalnya, anggaplah Anda memiliki 100 VM. Setiap VM menghasilkan deret waktu untuk jenis metrik my_metric. Berikut adalah dua cara berbeda untuk memantau deret waktu:

  • Anda membuat satu kebijakan pemberitahuan yang memiliki satu kondisi. Kondisi memantau my_metric dan menggabungkan data ke tingkat VM. Setelah penggabungan, ada satu deret waktu untuk setiap VM. Oleh karena itu, kondisi memantau 100 deret waktu.

  • Anda membuat 100 kebijakan pemberitahuan dan masing-masing berisi 1 kondisi. Setiap kondisi memantau deret waktu my_metric untuk salah satu VM, dan menggabungkan data ke tingkat VM. Oleh karena itu, setiap kondisi memantau satu deret waktu.

Opsi kedua, yang membuat 100 kondisi, lebih mahal daripada opsi pertama, yang hanya membuat 1 kondisi. Kedua opsi memantau 100 deret waktu.

Gabungkan hanya ke tingkat yang Anda perlukan untuk mendapatkan pemberitahuan

Ada biaya untuk setiap deret waktu yang dipantau oleh kebijakan pemberitahuan. 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.

Misalnya, anggaplah Anda memiliki 100 VM. Setiap VM menghasilkan deret waktu untuk jenis metrik my_metric. Setiap VM Anda termasuk dalam salah satu dari lima layanan. Anda memutuskan untuk membuat satu kebijakan pemberitahuan yang memiliki satu kondisi yang memantau my_metric. Berikut dua opsi penggabungan yang berbeda:

  • Anda menggabungkan data ke layanan. Setelah penggabungan, ada satu deret waktu untuk setiap layanan. Oleh karena itu, kondisi memantau 5 deret waktu.

  • Anda menggabungkan data ke tingkat VM. Setelah penggabungan, ada satu deret waktu untuk setiap VM. Oleh karena itu, kondisi memantau 100 deret waktu.

Opsi kedua, yang memantau 100 deret waktu, lebih mahal daripada opsi pertama, yang hanya memantau lima deret waktu.

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 memerhatikan pemberitahuan tentang latensi menurut layanan, Anda mungkin ingin menggabungkan ke tingkat layanan.

Jangan membuat pemberitahuan pada data mentah yang tidak digabungkan

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 Anda hanya akan mendapatkan 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 mendapatkan 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.

Gunakan 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:

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.