Mengoptimalkan dan memantau biaya Google Cloud Observability

Halaman ini menjelaskan cara mengoptimalkan dan memantau biaya Google Cloud Observability. Untuk mengetahui informasi harga, lihat Harga Google Cloud Observability.

Anda mungkin juga tertarik dengan dokumen berikut:

Optimalkan

Bagian ini memberikan panduan tentang cara mengurangi atau mengoptimalkan biaya yang terkait dengan Cloud Logging, Cloud Trace, dan Google Cloud Managed Service for Prometheus.

Mengurangi biaya Cloud Logging

Untuk mengurangi biaya penyimpanan Cloud Logging, konfigurasikan filter pengecualian di sink log Anda untuk mencegah entri log bernilai rendah di-streaming ke bucket log Anda. Anda dapat mengonfigurasi sink log untuk mengecualikan semua entri log yang cocok dengan filter pengecualian, atau hanya mengecualikan persentase entri log yang cocok. Entri log yang dikecualikan tidak di-streaming ke bucket log Anda dan tidak dihitung terhadap alokasi penyimpanan Anda. Untuk mempelajari lebih lanjut, lihat Filter sink log.

Biaya penyimpanan Cloud Logging hanya berlaku untuk data log yang disimpan di bucket log. Anda dapat mengonfigurasi sink log sehingga data log tidak disimpan di bucket log, tetapi dialihkan ke salah satu tujuan berikut:

Cloud Logging tidak mengenakan biaya untuk merutekan entri log ke tujuan yang tercantum. Namun, Anda mungkin dikenai biaya saat entri log diterima oleh tujuan.

Untuk mengetahui informasi tentang cara merutekan data log, lihat Merutekan log ke tujuan yang didukung.

Mengoptimalkan biaya untuk Managed Service for Prometheus

Harga untuk Managed Service for Prometheus didesain agar dapat dikontrol. Karena Anda dikenai biaya berdasarkan sampel, Anda dapat menggunakan berikut ini untuk mengontrol biaya:

  • Periode pengambilan sampel: Mengubah periode scraping metrik dari 15 detik menjadi 60 detik dapat menghemat biaya sebesar 75%, tanpa mengorbankan kardinalitas. Anda dapat mengonfigurasi periode pengambilan sampel per tugas, per target, atau secara global.

  • Pemfilteran: Anda dapat menggunakan pemfilteran untuk mengurangi jumlah sampel yang dikirim ke penyimpanan data global milik layanan; Untuk mendapatkan informasi lebih lanjut, lihat Memfilter metrik yang diekspor. Gunakan konfigurasi pelabelan ulang metrik dalam konfigurasi scrape Prometheus untuk menghapus metrik pada waktu penyerapan, berdasarkan pencocok label.

  • Simpan data bernilai rendah berkardinalitas tinggi. Anda dapat menjalankan Prometheus standar bersama layanan terkelola, menggunakan konfigurasi scape yang sama, dan menyimpan data secara lokal yang tidak layak dikirim ke penyimpanan data global milik layanan.

Harga untuk Managed Service for Prometheus dirancang agar dapat diprediksi.

  • Anda tidak akan dikenakan penalti karena memiliki histogram sparse. Sampel dihitung hanya untuk nilai pertama yang bukan nol, lalu saat nilai untuk bucketn lebih besar dari nilai di bucketn-1. Misalnya, histogram dengan nilai 10 10 13 14 14 14 dihitung sebagai tiga sampel, untuk bucket pertama, ketiga, dan keempat.

    Bergantung pada jumlah histogram yang Anda gunakan, dan untuk apa Anda menggunakannya, pengecualian bucket yang tidak berubah dari harga biasanya mungkin mengakibatkan penghitungan sampel sebesar 20% hingga 40% lebih sedikit untuk tujuan penagihan dibandingkan dengan jumlah absolut yang akan ditunjukkan oleh bucket histogram.

  • Dengan mengenakan biaya per sampel, Anda tidak akan dikenai penalti untuk container yang diskalakan dan tidak diskalakan, preemptible, atau efemeral dengan cepat, seperti yang dibuat oleh HPA atau Autopilot GKE.

    Jika Managed Service for Prometheus dikenakan biaya per metrik, Anda akan membayar kardinalitas sebulan penuh, sekaligus setiap kali container baru dijalankan. Dengan harga per sampel, Anda hanya membayar saat container sedang berjalan.

Kueri, termasuk kueri pemberitahuan

Semua kueri yang dikeluarkan oleh pengguna, termasuk kueri yang dikeluarkan saat aturan perekaman Prometheus dijalankan, dikenakan biaya melalui panggilan Cloud Monitoring API.

Mengurangi penggunaan Trace

Untuk mengontrol volume penyerapan span Trace, Anda dapat mengelola frekuensi sampling trace untuk menyeimbangkan seberapa banyak trace yang dibutuhkan untuk analisis performa, dengan toleransi biaya Anda.

Untuk sistem dengan traffic tinggi, umumnya pelanggan dapat mengambil sampel 1 dalam 1.000 transaksi, atau bahkan 1 dalam 10.000 transaksi, dan masih mendapat cukup informasi untuk analisis performa.

Frekuensi sampling dikonfigurasi dengan library klien Cloud Trace.

Mengurangi tagihan pemberitahuan

Bagian 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.

Memantau

Bagian ini menjelaskan cara memantau biaya dengan membuat kebijakan pemberitahuan. Kebijakan pemberitahuan dapat memantau data metrik dan memberi tahu Anda saat data tersebut melampaui batas.

Memantau byte log bulanan yang diserap

Untuk membuat kebijakan pemberitahuan yang akan dipicu saat jumlah byte log yang ditulis ke bucket log melampaui batas yang ditentukan pengguna untuk Cloud Logging, gunakan setelan berikut.

Kolom New condition
Nilai
Resource and Metric Di menu Resources, pilih Global.
Di menu Metric categories, pilih Logs-based metric.
Di menu Metrics, pilih Monthly log bytes ingested.
Filter Tidak ada.
Across time series
Time series aggregation		 sum
Rolling window 60 m
Rolling window function max
Kolom Configure alert trigger
Nilai
Condition type Threshold
Alert trigger Any time series violates
Threshold position Above threshold
Threshold value Anda menentukan nilai yang dapat diterima.
Retest window Nilai minimum yang dapat diterima adalah 30 menit.

Memantau total metrik yang diserap

Anda tidak dapat membuat pemberitahuan berdasarkan metrik bulanan yang diserap. Namun, Anda dapat membuat pemberitahuan untuk biaya Cloud Monitoring. Untuk mengetahui informasinya, lihat Mengonfigurasi pemberitahuan penagihan.

Memantau span trace bulanan yang diserap

Untuk membuat kebijakan pemberitahuan yang terpicu saat span Cloud Trace bulanan Anda diserap melebihi batas yang ditentukan pengguna, gunakan setelan berikut.

Kolom New condition
Nilai
Resource and Metric Di menu Resources, pilih Global.
Di menu Metric categories, pilih Billing.
Di menu Metrics, pilih Monthly trace spans ingested.
Filter
Across time series
Time series aggregation		 sum
Rolling window 60 m
Rolling window function max
Kolom Configure alert trigger
Nilai
Condition type Threshold
Alert trigger Any time series violates
Threshold position Above threshold
Threshold value Anda menentukan nilai yang dapat diterima.
Retest window Nilai minimum yang dapat diterima adalah 30 menit.

Mengonfigurasi pemberitahuan penagihan

Jika Anda ingin menerima pemberitahuan saat biaya yang dapat ditagih atau yang diperkirakan telah melampaui anggaran tertentu, buat pemberitahuan melalui halaman Budgets and alerts di konsol Google Cloud :

  1. Di konsol Google Cloud , buka halaman Penagihan:

    Buka Penagihan

    Anda juga dapat menemukan halaman ini dengan menggunakan kotak penelusuran.

    Jika Anda memiliki lebih dari satu akun Penagihan Cloud, lakukan salah satu langkah berikut:

    • Untuk mengelola Penagihan Cloud untuk project saat ini, pilih Go to linked billing account.
    • Untuk menemukan akun Penagihan Cloud lain, pilih Manage billing accounts dan tentukan akun yang anggarannya ingin Anda tetapkan.
  2. Di menu navigasi Billing, pilih Budgets & alerts.
  3. Klik Create budget.
  4. Lengkapi dialog anggaran. Dalam dialog ini, Anda dapat memilih Google Cloud project dan produk, lalu membuat anggaran untuk kombinasi tersebut. Secara default, Anda akan menerima pemberitahuan saat anggaran terpakai 50%, 90%, dan 100%. Untuk dokumentasi lengkapnya, lihat Menetapkan anggaran dan pemberitahuan anggaran.