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 dan Contoh harga pemberitahuan.

Melihat perkiraan tagihan Anda menggunakan kalkulator harga dalam UI

Saat Anda membuat atau mengedit kebijakan pemberitahuan, Cloud Alerting akan menampilkan perkiraan biaya kebijakan. Anda dapat menggunakan kalkulator ini untuk melihat perubahan estimasi biaya saat Anda mengubah parameter kebijakan pemberitahuan.

Menggunakan Metrics Explorer untuk memverifikasi jumlah poin yang ditampilkan

Jumlah titik yang ditampilkan oleh kueri kebijakan pemberitahuan terutama bergantung pada kardinalitas output kueri kebijakan pemberitahuan Anda. Untuk melihat perkiraan kardinalitas kebijakan pemberitahuan Anda, lakukan langkah berikut:

  • Untuk kondisi pemberitahuan nilai minimum metrik, gunakan Metrics Explorer untuk membuat kueri yang identik. Tambahkan transformasi sekunder Count time series menurut None.
  • Untuk kondisi pemberitahuan PromQL, salin kueri ke Metrics Explorer, lalu lakukan hal berikut:
    • Pisahkan kueri Anda menjadi beberapa klausa dengan membagi setiap operator >, <, >=, <=, ==, !=, AND, OR, dan UNLESS.
    • Hapus klausa yang tidak berisi metrik, seperti nilai batas numerik.
    • Gabungkan setiap klausa dalam fungsi count().
    • Jumlahkan hasilnya.

  • Untuk kondisi pemberitahuan MQL, salin kueri ke Metrics Explorer. Hapus baris | condition. Tambahkan baris | group_by [], .count di bagian akhir.

    MQL tidak digunakan lagi dan kasus yang meminta bantuan untuk men-debug masalah penagihan mungkin ditolak oleh Cloud Customer Care.

Menggabungkan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource

Pemberitahuan mengenakan biaya per referensi metrik, dan setiap kebijakan batas metrik memiliki satu referensi metrik 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 satu titik setiap menit untuk jenis metrik my_metric. Berikut adalah dua cara berbeda untuk memantau poin yang ditampilkan:

  • Anda membuat satu kebijakan pemberitahuan yang memiliki satu kondisi dan oleh karena itu memiliki satu referensi metrik. Kondisi memantau my_metric dan menggabungkan data ke tingkat VM. Setelah penggabungan, ada satu titik yang ditampilkan untuk setiap VM. Oleh karena itu, kondisi menghasilkan 100 poin yang ditampilkan per evaluasi.

  • Anda membuat 100 kebijakan pemberitahuan dan setiap kebijakan berisi satu kondisi sehingga memiliki satu referensi metrik. Setiap kondisi memantau deret waktu my_metric untuk salah satu VM, dan menggabungkan data ke tingkat VM. Oleh karena itu, setiap kondisi menampilkan satu poin per evaluasi.

Opsi kedua, yang membuat 100 kondisi (100 referensi metrik), lebih mahal daripada opsi pertama, yang hanya membuat 1 kondisi (1 referensi metrik). Kedua opsi ini memberikan 100 poin per evaluasi.

Gabungkan hanya ke tingkat yang perlu Anda beri tahu

Satu titik ditampilkan 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 projectGoogle 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 titik 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 agregasi yang berbeda:

  • Anda mengagregasi data ke layanan. Setelah penggabungan, setiap eksekusi kebijakan pemberitahuan akan menampilkan satu titik untuk setiap layanan. Oleh karena itu, kondisi ini akan menampilkan 5 poin per eksekusi.

  • Anda menggabungkan data ke tingkat VM. Setelah penggabungan, setiap eksekusi kebijakan pemberitahuan menampilkan satu titik untuk setiap VM. Oleh karena itu, kondisi ini menampilkan 100 poin per eksekusi.

Opsi kedua, yang menampilkan 100 poin per eksekusi, lebih mahal daripada opsi pertama, yang hanya menampilkan lima poin per eksekusi.

Saat mengonfigurasi kebijakan pemberitahuan, pilih tingkat agregasi yang paling sesuai untuk kasus penggunaan Anda. Misalnya, jika Anda ingin menerima 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 memberikan notifikasi 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 poin yang ditampilkan untuk setiap periode eksekusi. Namun, jika Anda melakukan agregasi ke VM, maka Anda hanya akan mendapatkan 100 titik yang ditampilkan per periode eksekusi, terlepas dari kardinalitas label data pokok.

Pemberitahuan tentang data mentah juga membuat Anda berisiko mendapatkan peningkatan poin yang ditampilkan 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 poin yang dikembalikan 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.

Menyaring respons yang tidak perlu

Konfigurasikan 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 titik yang ditampilkan

Jika kondisi Anda menggunakan kueri PromQL, Anda dapat menggunakan operator aliran teratas untuk memilih sejumlah titik yang ditampilkan dengan nilai tertinggi:

Misalnya, klausa topk(metric, 5) dalam kueri PromQL membatasi jumlah titik yang ditampilkan menjadi lima di setiap periode eksekusi.

Membatasi jumlah titik teratas dapat menyebabkan data hilang dan insiden salah, seperti:

  • Jika lebih dari N titik melanggar batas, Anda akan kehilangan data di luar N titik teratas.
  • Jika titik pelanggaran terjadi di luar N titik teratas, insiden Anda mungkin ditutup otomatis meskipun titik yang dikecualikan masih melanggar batas.
  • Kueri kondisi Anda mungkin tidak menampilkan konteks penting seperti titik dasar yang berfungsi sebagaimana mestinya.

Untuk mengurangi risiko tersebut, pilih nilai besar untuk N dan gunakan operator top-streams hanya dalam kebijakan pemberitahuan yang mengevaluasi banyak deret waktu, seperti insiden untuk setiap penampung Kubernetes.

Memperpanjang 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 titik 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.

Jangan gunakan "Unspecified Resource" (Khusus metrik berbasis log)

Kondisi pemberitahuan yang menggunakan metrik Berbasis log memungkinkan Anda menetapkan "Resource yang Tidak Ditentukan" sebagai jenis resource yang dipantau. Jika Anda melakukannya, kondisi pemberitahuan akan meluncurkan kueri terpisah untuk setiap jenis resource yang dipantau di Cloud Monitoring. Karena setiap kueri menagih minimum satu titik yang ditampilkan, tidak menentukan jenis resource akan menyebabkan tagihan titik yang ditampilkan tinggi.

Untuk menurunkan tagihan, pilih jenis resource tertentu, bukan menggunakan "Resource Tidak Ditentukan". Hal ini berfungsi karena sebagian besar metrik Berbasis log hanya muncul dalam satu jenis resource. Jika metrik Berbasis log muncul di beberapa jenis resource, Anda dapat membuat beberapa kebijakan pemberitahuan atau menggunakan beberapa kondisi dalam satu kebijakan pemberitahuan.