Halaman ini menjelaskan cara mengoptimalkan dan memantau biaya Google Cloud Observability Anda. Untuk mengetahui informasi harga, lihat harga Google Cloud Observability.
Anda mungkin juga tertarik dengan dokumen berikut:
- Perkirakan tagihan Anda.
- Contoh harga.
- Mengoptimalkan biaya dengan Cost Explorer. Cost Explorer memberikan visualisasi data biaya dan metrik pemanfaatan saat ini dan historis. Dengan demikian, data ini membantu Anda mengidentifikasi peluang pengoptimalan.
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 penyimpanan log
Untuk mengurangi biaya penyimpanan Cloud Logging, konfigurasi filter pengecualian di sink log Anda untuk mengecualikan log tertentu agar tidak dirutekan. Filter pengecualian dapat menghapus semua entri log yang cocok dengan filter, atau hanya menghapus sebagian log. Jika sebuah entri log cocok dengan filter pengecualian sebuah sink, sink tersebut tidak akan merutekan entri log itu ke tujuannya. Entri log yang dikecualikan tidak dihitung terhadap alokasi penyimpanan Anda. Untuk petunjuk tentang cara menetapkan filter pengecualian, lihat Pengecualian log.
Opsi lain untuk mengurangi biaya penyimpanan Cloud Logging adalah merutekan log keluar dari Cloud Logging ke tujuan yang didukung. Cloud Logging tidak mengenakan biaya untuk merutekan log ke tujuan yang didukung. Namun, Anda mungkin dikenai biaya saat log diterima oleh tujuan:
Untuk informasi tentang merutekan log keluar dari Cloud Logging, baca 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 datastore 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 14dihitung 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. Untuk mengetahui tarif saat ini, lihat tabel ringkasan untuk harga Managed Service for Prometheus atau harga Monitoring.
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
Mulai paling cepat 1 Mei 2026, Cloud Monitoring akan mulai mengenakan biaya untuk penggunaan kebijakan pemberitahuan. Untuk mengetahui informasi tentang model harga, lihat Harga untuk pemberitahuan.Dokumen ini menjelaskan strategi yang dapat Anda gunakan untuk mengurangi biaya pemberitahuan.
Menggabungkan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource
Karena biaya per kondisi adalah $0,10, maka lebih hemat biaya menggunakan 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 memancarkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- Satu kondisi pemberitahuan
- Kondisi digabungkan ke tingkat VM
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $0,10 per bulan = $0,10 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: $3,12 per bulan
Contoh 2
Data
- 100 VM
- Setiap VM memancarkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- 100 kondisi
- Setiap kondisi difilter dan digabungkan ke satu VM
- Periode eksekusi 30 detik
- Biaya kondisi: 100 kondisi * $0,10 per bulan = $10 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: $13,02 per bulan
Dalam kedua contoh, 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 $10 lebih murah per bulan.
Gabungkan hanya ke tingkat yang perlu Anda beri tahu
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.
Perhatikan contoh berikut:
Contoh 1
Data
- 100 VM
- Setiap VM memancarkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- Satu kondisi pemberitahuan
- Kondisi digabungkan ke tingkat VM
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $0,10 per bulan = $0,10 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: $3,12 per bulan
Contoh 4
Data
- 100 VM, dengan setiap VM termasuk dalam satu layanan
- Total lima layanan
- Setiap VM memancarkan satu metrik,
metric_name metric_namememiliki satu label, yang memiliki 10 nilai
- Satu kondisi
- Kondisi digabungkan ke tingkat layanan
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $0,10 per bulan = $0,10 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: $0,24 per bulan
Contoh 5
Data
- 100 VM
- Setiap VM memancarkan satu metrik,
metric_name metric_namememiliki 100 label dengan masing-masing 1.000 nilai
- Satu kondisi
- Kondisi digabungkan ke tingkat VM
- Periode eksekusi 30 detik
- Biaya kondisi: 1 kondisi * $0,10 per bulan = $0,10 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: $3,12 per bulan
Bandingkan Contoh 1 dengan Contoh 4: Kedua contoh beroperasi pada data pokok yang sama dan memiliki satu kebijakan pemberitahuan. Namun, karena kebijakan pemberitahuan dalam Contoh 4 digabungkan ke layanan, kebijakan tersebut lebih murah daripada kebijakan pemberitahuan dalam Contoh 1, yang digabungkan secara lebih terperinci ke VM.
Selain itu, bandingkan Contoh 1 dengan Contoh 5: Dalam hal ini, kardinalitas metrik dalam Contoh 5 10.000 kali lebih tinggi daripada kardinalitas metrik dalam Contoh 1. Namun, karena kebijakan pemberitahuan dalam Contoh 1 dan Contoh 5 sama-sama digabungkan ke VM, dan karena jumlah VM sama dalam kedua contoh, harga kedua contoh tersebut setara.
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 memperhatikan pemberitahuan tentang latensi menurut endpoint, sebaiknya gabungkan ke tingkat endpoint.
Jangan membuat pemberitahuan pada data mentah yang tidak diagregasi
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 hanya 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 memiliki 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 biaya dan peringatan 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.
Menggunakan operator aliran teratas untuk mengurangi jumlah deret waktu yang ditampilkan
Jika kondisi Anda menggunakan kueri PromQL atau MQL, 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 tidak ada dan pemberitahuan 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-streams hanya dalam kebijakan pemberitahuan yang mengevaluasi banyak deret waktu, seperti pemberitahuan untuk setiap penampung Kubernetes.
Meningkatkan durasi periode eksekusi (khusus PromQL)
Jika kondisi Anda menggunakan kueri PromQL, Anda dapat mengubah durasi
periode eksekusi dengan menyetel 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 :
-
Di konsol Google Cloud , buka halaman 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.
- Di menu navigasi Billing, pilih Budgets & alerts.
- Klik Create budget.
- 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.