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, konfigurasi 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.

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.

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.