Harga Cloud Monitoring

Harga untuk Google Cloud Observability memungkinkan Anda mengontrol penggunaan pengeluaran Google Cloud Anda. Harga produk Google Cloud Observability ditentukan berdasarkan volume data atau tingkat penggunaan. Anda dapat menggunakan alokasi penggunaan data gratis untuk memulai tanpa biaya atau komitmen di awal.

Tabel berikut meringkas informasi harga untuk Cloud Logging, Cloud Monitoring, dan Cloud Trace.

Ringkasan harga Cloud Logging

Fitur Harga1 Alokasi gratis per bulan
Penyimpanan logging* $0,50/GiB;
Tagihan satu kali untuk mengalirkan log ke penyimpanan buket log untuk pengindeksan, pembuatan kueri, dan analisis; mencakup penyimpanan hingga 30 hari di bucket log. Tidak ada biaya tambahan untuk pembuatan kueri dan analisis data log. 		50 GiB pertama/project/bulan
Retensi logging† $0,01 per GiB per bulan untuk log yang disimpan lebih dari 30 hari; ditagih setiap bulan sesuai dengan retensi. Log yang dipertahankan selama periode retensi data default tidak dikenakan biaya retensi.
Router Log‡ Tidak ada biaya tambahan Tidak berlaku
Log Analytics♣ Tidak ada biaya tambahan Tidak berlaku
*  Volume penyimpanan dihitung dalam ukuran sebenarnya entri log sebelum pengindeksan. Biaya penyimpanan tidak dikenakan untuk log yang disimpan di bucket log _Required.
 †  Biaya retensi tidak dikenakan untuk log yang disimpan di bucket log _Required, yang memiliki periode retensi data tetap 400 hari.
 ‡ Perutean log didefinisikan sebagai log penerusan yang diterima melalui Cloud Logging API ke tujuan yang didukung. Tujuan mungkin mengenakan biaya untuk log yang dirutekan.
 ♣ Biaya tidak dikenakan untuk mengupgrade bucket log agar dapat menggunakan Log Analytics atau menerbitkan kueri SQL dari halaman Log Analytics.
 Catatan: Informasi harga untuk Cloud Logging diubah pada 19 Juli 2023; namun, alokasi gratis dan tarifnya tidak berubah. Tagihan Anda mungkin merujuk ke informasi harga lama.

Ringkasan harga Cloud Monitoring

Fitur Harga Alokasi gratis per bulan Tanggal mulai berlaku
Semua data Monitoring
kecuali data yang diserap menggunakan Managed Service for Prometheus		 $0,2580/MiB1: 150–100.000 MiB pertama
$0,1510/MiB: 100.000–250.000 MiB berikutnya
$0,0610/MiB: >250.000 MiB		 Semua metrik Google Cloud yang tidak dapat dikenakan biaya
150 MiB pertama per akun penagihan untuk metrik yang dikenakan biaya dberdasarkan byte yang diserap		 1 Juli 2018
Metrik yang diserap menggunakan Google Cloud Managed Service for Prometheus, termasuk metrik bidang kontrol GKE $0,06/juta sampel†: 0-50 miliar sampel pertama yang diserap#
$0,048/juta sampel: 50-250 miliar sampel berikutnya yang diserap
$0,036/juta sampel: 250-500 miliar sampel berikutnya yang diserap
$0,024/juta sampel: >500 miliar sampel yang diserap		 Tidak berlaku 8 Agustus 2023
Panggilan API Monitoring $0,01/1.000 panggilan Read API
(panggilan Write API gratis)		 1 juta panggilan API Baca pertama disertakan per akun penagihan 1 Juli 2018
Eksekusi cek uptime Monitoring $0,30/1.000 eksekusi‡ 1 juta eksekusi per project Google Cloud 1 Oktober 2022
Eksekusi Monitoring Synthetic Monitors $1,20/1.000 eksekusi* 100 eksekusi per akun penagihan 1 November 2023
Kebijakan pemberitahuan $1,50 per bulan untuk setiap kondisi dalam kebijakan pemberitahuan
$0,35 per 1.000.000 deret waktu yang ditampilkan oleh kueri kondisi kebijakan pemberitahuan metrik♣		 Tidak berlaku 7 Januari 2025
† Google Cloud Managed Service for Prometheus menggunakan Penyimpanan Cloud Monitoring untuk penggunaan dan data metrik yang dibuat secara eksternal Monitoring API untuk mengambil data tersebut. Google Cloud Managed Service for Prometheus melakukan pengukuran berdasarkan sampel yang diserap, bukan byte, agar selaras dengan konvensi Prometheus. Untuk informasi lebih lanjut tentang pengukuran berbasis sampel, baca artikel Harga untuk kemampuan kontrol dan prediksi. Untuk mengetahui contoh komputasi, baca artikel Contoh penentuan harga berdasarkan sampel yang diserap.
 #  Sampel dihitung per akun penagihan.
 ‡  Eksekusi ditagihkan ke akun penagihan tempat eksekusi tersebut ditentukan. Untuk informasi selengkapnya, lihat Harga untuk eksekusi cek uptime.
 *  Eksekusi ditagihkan ke akun penagihan tempat eksekusi tersebut ditentukan. Untuk setiap eksekusi, Anda mungkin dikenai biaya tambahan dari layanan Google Cloud lainnya, termasuk layanan seperti Cloud Functions, Cloud Storage, dan Cloud Logging. Untuk informasi tentang biaya tambahan ini, lihat dokumen harga untuk layanan Google Cloud terkait.
 ♣ Untuk informasi selengkapnya, lihat Harga untuk pemberitahuan.

Ringkasan harga Cloud Trace

Fitur Harga Alokasi gratis per bulan Tanggal mulai berlaku
Penyerapan Trace $0,20/juta span 2,5 juta span pertama per akun penagihan 1 November 2018

Untuk mengetahui informasi mendetail tentang biaya produk Google Cloud Observability, lihat bagian-bagian berikut di halaman ini:

Untuk mengetahui informasi tentang harga GKE Enterprise, lihat GKE Enterprise.

Melihat penggunaan Anda

Untuk melihat penggunaan Anda saat ini, buka halaman Cloud Billing Reports di Konsol Google Cloud

Buka Penagihan Cloud

Berdasarkan data penggunaan saat ini, Anda dapat memperkirakan tagihan menggunakan kalkulator harga.

Contoh, pertimbangkan konfigurasi yang setiap instance VM Compute Engine-nya menghasilkan 10 GiB log yang dapat dikenakan biaya dan 20 MiB metrik yang dapat dikenakan biaya per bulan. Dengan kalkulator harga, Anda dapat menentukan perkiraan biaya Cloud Monitoring dan Cloud Logging:

1 VM 10 VM 100 VM 1000 VM
Biaya metrik per bulan $0,00 $12,90 $477,30 $5.121,30
Biaya logging per bulan $0,00 $25,00 $475,00 $4.975,00
Biaya Total: $0,00 $37,90 $952,30 $10.096,30

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

    Buka Penagihan

    Anda juga dapat menemukan halaman ini menggunakan kotak penelusuran.

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

    • 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 project dan produk Google Cloud, lalu membuat anggaran untuk kombinasi tersebut. Secara default, Anda akan menerima pemberitahuan saat anggaran terpakai 50%, 90%, dan 100%. Untuk dokumentasi lengkapnya, baca Menetapkan anggaran dan pemberitahuan anggaran.

Cloud Logging

Bucket log adalah container Logging yang menyimpan data log. Logging mengenakan biaya untuk volume data log yang disimpan di bucket log _Default dan bucket log yang ditentukan pengguna, jika volume tersebut melampaui alokasi bulanan gratis. Untuk bucket log _Default dan bucket log yang ditentukan pengguna, Logging juga mengenakan biaya jika log dipertahankan melampaui periode retensi data default, yaitu 30 hari.

Logging tidak mengenakan biaya tambahan untuk perutean log, penggunaan Cloud Logging API, atau untuk log yang disimpan di bucket log _Required, yang memiliki periode retensi data tetap 400 hari.

Bagian ini menyajikan informasi tentang topik-topik berikut:

Untuk melihat ringkasan informasi harga, baca Ringkasan harga Cloud Logging.

Untuk mengetahui batasan yang berlaku pada penggunaan Logging, termasuk periode retensi data, baca Kuota dan batasan.

Untuk melihat dan memahami data penggunaan Cloud Logging, baca Memperkirakan tagihan Anda.

Model penyimpanan Cloud Logging

Untuk setiap project Google Cloud, Logging otomatis membuat dua bucket log: _Required dan _Default. Untuk kedua bucket ini, Logging otomatis membuat sink log dengan nama _Required dan _Default yang merutekan log ke bucket log dengan nama yang terkait. Anda tidak dapat menonaktifkan atau memodifikasi sink _Required. Anda dapat menonaktifkan atau memodifikasi sink _Default untuk mencegah bucket _Default menyimpan log baru.

Anda dapat membuat bucket log yang ditentukan pengguna di project Google Cloud mana pun. Anda juga dapat mengonfigurasi sink untuk merutekan kombinasi log apa pun, bahkan antar-project Google Cloud di organisasi Google Cloud Anda, ke bucket log ini.

Untuk bucket log _Default dan bucket log yang ditentukan pengguna, Anda dapat mengonfigurasi periode retensi data kustom.

Anda dapat mengupgrade bucket log untuk menggunakan Log Analytics. Upgrade bucket log agar dapat menggunakan Log Analytics tidak dikenai biaya.

Untuk informasi lebih lanjut tentang bucket dan sink Cloud Logging, baca Ringkasan pemilihan rute dan penyimpanan.

Harga penyimpanan

Logging tidak mengenakan biaya untuk log yang disimpan di bucket _Required. Anda tidak dapat menghapus bucket _Required atau memodifikasi sink _Required. Bucket _Required menyimpan log berikut:

Logging mengenakan biaya untuk volume data log yang belum diindeks yang disimpan di bucket log _Default dan bucket log yang ditentukan pengguna, jika volume totalnya melampaui alokasi bulanan gratis. Setiap operasi tulis entri log ke bucket log _Default atau ke bucket log yang ditentukan pengguna akan mengurangi alokasi penyimpanan Anda. Misalnya, jika Anda memiliki sink yang merutekan sebuah entri log ke tiga bucket log, entri log tersebut akan disimpan tiga kali.

Harga retensi

Tabel berikut mencantumkan periode retensi data untuk log yang disimpan di bucket log:

Bucket Periode retensi data default Retensi kustom
_Required 400 hari Tidak dapat dikonfigurasi
_Default 30 hari Dapat dikonfigurasi
Ditentukan pengguna 30 hari Dapat dikonfigurasi

Logging mengenakan biaya retensi jika log dipertahankan melampaui periode retensi data default. Anda tidak dapat mengonfigurasi periode retensi data untuk bucket log _Required. Biaya retensi tidak dikenakan jika log hanya disimpan selama periode retensi data default bucket log.

Jika periode retensi data sebuah bucket log dipersingkat, akan ada masa tenggang tujuh hari untuk mengamankan log yang telah habis masa berlakunya agar tidak dihapus. Anda tidak dapat membuat kueri atau melihat log yang telah habis masa berlakunya. Namun, dalam waktu tujuh hari ini, Anda dapat memulihkan akses penuh dengan memperpanjang periode retensi data bucket log tersebut. Log yang disimpan selama masa tenggang ini mengurangi biaya retensi Anda.

Jika Anda merutekan sebuah entri log ke beberapa bucket log, Anda dapat dikenai biaya penyimpanan dan retensi beberapa kali. Misalkan Anda merutekan sebuah entri log ke bucket log _Default dan bucket log yang ditentukan pengguna. Selain itu, asumsikan Anda mengonfigurasi periode retensi data kustom untuk kedua bucket menjadi lebih dari 30 hari. Untuk konfigurasi ini, Anda akan menerima dua tagihan penyimpanan dan dua tagihan retensi.

Mengurangi penyimpanan log

Logging memungkinkan Anda mengidentifikasi dan mengecualikan entri log secara manual agar tidak disimpan di bucket log dengan mengonfigurasi filter pengecualian untuk sink Anda. Dengan filter pengecualian, biaya penyimpanan dapat ditekan. Anda juga dapat mempertimbangkan untuk merutekan log keluar dari Cloud Logging.

Filter pengecualian dapat menghapus semua entri log yang cocok dengan filter, atau hanya menghapus sebagian log yang cocok dengan filter. Jika sebuah entri log cocok dengan filter pengecualian untuk sebuah sink, sink tersebut tidak akan merutekan entri log itu ke tujuannya. Akibatnya, tujuan tidak akan menyerap entri log itu. Entri log yang dikecualikan tidak dihitung terhadap alokasi penyimpanan Anda. Untuk petunjuk menetapkan filter pengecualian, baca Pengecualian log.

Untuk mempertahankan akses ke log yang tidak disimpan di bucket log, Anda juga dapat menggunakan sink log untuk merutekan entri log dari Cloud Logging ke tujuan yang didukung. Cloud Logging tidak mengenakan biaya untuk merutekan log. Namun, layanan Google Cloud yang menerima log tersebut akan mengenakan biaya penggunaan kepada Anda. Untuk informasi selengkapnya, baca dokumen berikut:

Untuk informasi tentang merutekan log keluar dari Cloud Logging, baca Merutekan log ke tujuan yang didukung.

Harga metrik berbasis log

Metrik berbasis log yang ditentukan sistem tersedia untuk semua project Google Cloud dan tidak dikenakan biaya.

Metrik berbasis log yang ditentukan pengguna adalah sebuah class dalam metrik kustom Cloud Monitoring dan dapat dikenakan biaya. Untuk mengetahui detail harga, lihat Metrik yang dapat dikenakan biaya.

Untuk informasi lebih lanjut, baca Ringkasan metrik berbasis log.

Membuat kebijakan pemberitahuan tentang 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.

Cloud Monitoring

Monitoring mengenakan biaya untuk berikut ini:

  • Metrik yang diukur berdasarkan byte yang diserap, saat data metrik yang diserap melebihi alokasi metrik bulanan gratis.

    Metrik yang tidak dapat dikenakan biaya tidak mengurangi batas alokasi.

  • Metrik yang diukur berdasarkan jumlah sampel yang diserap.

  • Panggilan operasi baca Cloud Monitoring API yang melebihi alokasi API bulanan gratis.

    Panggilan operasi tulis Monitoring API tidak mengurangi batas alokasi.

  • Eksekusi cek uptime.

  • Eksekusi monitor sintetis.

  • Ketentuan kebijakan pemberitahuan yang diukur berdasarkan jumlah kondisi aktif per bulan.

  • Deret waktu yang ditampilkan oleh kueri kondisi kebijakan pemberitahuan.

Dalam Monitoring, penyerapan mengacu pada proses penulisan deret waktu ke Monitoring. Setiap deret waktu menyertakan sejumlah titik data; titik data tersebut adalah dasar untuk biaya penyerapan. Untuk mengetahui informasi harga, lihat harga Cloud Monitoring.

Bagian ini memberikan informasi berikut:

Untuk mengetahui informasi harga saat ini, lihat Harga Cloud Monitoring.

Untuk mengetahui batas yang berlaku pada penggunaan Monitoring, lihat Kuota dan batas.

Untuk melihat penggunaan Anda saat ini, lakukan salah satu langkah berikut:

  • Di konsol Google Cloud, buka halaman Billing:

    Buka Penagihan

    Anda juga dapat menemukan halaman ini menggunakan kotak penelusuran.

  • Di Konsol Google Cloud, buka Halaman Setelan Pemantauan:

    Buka Monitoring Settings

    Jika Anda menggunakan bilah pencarian untuk menemukan halaman ini, kemudian pilih hasil yang sub judulnya Pemantauan.

Berdasarkan data penggunaan saat ini, Anda dapat memperkirakan tagihan.

Metrik yang tidak dapat dikenakan biaya

Data metrik dari Google Cloud, GKE Enterprise, dan Knative tidak dikenai biaya. Metrik yang tidak dapat dikenakan biaya (gratis) meliputi:

Metrik yang dapat dikenakan biaya

Semua data metrik, kecuali metrik yang tercantum di bagian yang berjudul Non-chargeable metrics, dapat dikenakan biaya. Sebagian besar penyerapan metrik dikenakan biaya berdasarkan jumlah byte, tetapi beberapa penyerapan dikenakan biaya berdasarkan jumlah sampel; model penetapan harga ini dijelaskan di bagian berikut.

Faktor-faktor berikut berkontribusi terhadap biaya penyerapan:

  • Jenis titik data—nilai skalar atau nilai distribusi—yang dikumpulkan oleh metrik.

    • Untuk informasi tentang jenis data yang terkait dengan jenis metrik tertentu, lihat daftar metrik.
    • Untuk mengetahui informasi tentang jenis data skalar dan distribusi, lihat Jenis nilai.

  • Jumlah titik data yang ditulis ke deret waktu. Nilai ini bergantung pada frekuensi pengambilan sampel data dan kardinalitas data Anda. Kardinalitas menentukan jumlah deret waktu yang dihasilkan untuk kombinasi jenis metrik dan resource yang dimonitor; untuk informasi selengkapnya, lihat Kardinalitas.

Nilai untuk label metrik dan resource yang merupakan bagian dari deret waktu tidak berkontribusi pada tagihan Anda.

Metrik yang dikenakan biaya berdasarkan byte yang diserap

Metrik berikut dapat dikenakan biaya dan diberi harga berdasarkan jumlah byte yang diserap:

Untuk tujuan penetapan harga, volume penyerapan dihitung sebagai berikut:

  • Untuk jenis data skalar: 8 byte untuk setiap titik data yang ditulis ke deret waktu. Metrik penghitung berbasis log yang ditentukan pengguna termasuk dalam kategori ini.
  • Untuk jenis data distribusi: 80 byte untuk setiap titik data yang ditulis ke deret waktu.

Untuk informasi tentang titik data dalam deret waktu, lihat Deret waktu: data dari resource yang dimonitor.

Metrik yang dikenakan biaya berdasarkan sampel yang diserap

Metrik berikut dapat dikenakan biaya dan diberi harga berdasarkan jumlah sampel yang diserap:

Untuk tujuan penetapan harga, jumlah sampel dihitung sebagai berikut:

  • Untuk jenis data skalar: 1 untuk setiap titik yang ditulis ke deret waktu.
  • Untuk jenis data distribusi: 2 untuk setiap titik yang ditulis ke deret waktu, ditambah 1 untuk setiap bucket histogram yang memiliki jumlah bukan nol.

Untuk informasi tentang titik data dalam deret waktu, lihat Deret waktu: data dari resource yang dimonitor.

Pemberitahuan tentang metrik yang diserap

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

Contoh harga berdasarkan byte yang diserap

Contoh berikut menggambarkan cara mendapatkan estimasi biaya untuk mengumpulkan data metrik untuk metrik yang dikenakan biaya berdasarkan byte yang diserap. Contoh ini dimaksudkan untuk menggambarkan penghitungan; untuk perkiraan yang komprehensif, gunakan Kalkulator Harga. Jika Anda mengakses {i>tool<i} ini, gunakan Google Cloud Observability untuk memasukkan metrik, logging, dan data trace.

Skenario dasar adalah sebagai berikut: Anda memiliki beberapa resource yang dimonitor, seperti Compute Engine, Google Kubernetes Engine, atau App Engine, yang menuliskan data dari sejumlah metrik setiap bulannya.

Variabel di seluruh skenario meliputi:

  • Jumlah resource.
  • Jumlah metrik.
  • Apakah metrik itu berupa metrik Google Cloud atau bukan.
  • Tarif untuk tempat penulisan data metrik.

Contoh di bagian ini adalah untuk harga Monitoring per Juli 2020.

Latar belakang umum

Pada contoh harga berikut, setiap titik data metrik yang diserap diasumsikan sebagai jenis double, int64, atau bool. Ini dihitung sebagai 8 byte untuk tujuan penetapan harga. Total ada sekitar 730 jam (365 hari/12 bulan * 24 jam) dalam satu bulan, atau 43.800 menit.

Untuk satu data penulisan metrik dengan frekuensi 1 titik data/menit selama satu bulan:

  • Total titik data adalah: 43.800
  • Total volume yang diserap:
    • 350.400 byte (43.800 titik data * 8 byte)
    • 0,33416748 MiB (350.400 byte / 1.048.576 byte/MiB)

Untuk satu data penulisan metrik dengan frekuensi 1 titik data/jam selama satu bulan:

  • Total titik data adalah: 730
  • Total volume yang diserap:
    • 5.840 byte (730 titik data * 8 byte)
    • 0,005569458 MiB (5.840 byte / 1.048.576 byte/MiB)

Contoh

Skenario 1: Anda memiliki 1.000 resource, masing-masing menuliskan 75 metrik. Ini adalah khusus metrik Google Cloud, yang ditulis dengan kecepatan 1 titik data/menit.

  • Penyerapan bulanan: 25.063 MiB: 0,33416748 MiB untuk satu metrik * 75.000 (yaitu, 1.000 resource, 75 metrik)
  • Perkiraan biaya per bulan: $0,00 (Metrik Google Cloud tidak dikenakan biaya)
MiB yang diserap Tarif ($/MiB) Biaya ($)
tak terbatas 0,00 $0,00
Total 25.063 $0,00

Skenario 2: Anda memiliki 1.000 resource, masing-masing menuliskan 75 metrik kustom. Ini adalah penulisan metrik yang dapat dikenakan biaya dengan kecepatan 1 titik data/menit.

  • Penyerapan bulanan: 25.063 MiB (sama seperti di atas)
  • Perkiraan biaya per bulan: $6.427,55
MiB yang diserap Tarif ($/MiB) Biaya ($)
150 0,00 $0,00
24.913 0,258 $6.427,55
Total 25.063 $6.427,55

Skenario 3: Anda memiliki 1.000 resource, masing-masing menuliskan 75 metrik kustom. Ini adalah penulisan metrik yang dapat dikenakan biaya dengan kecepatan 1 titik data/jam.

  • Penyerapan bulanan: 418 MiB = 0,005569458 MiB untuk satu metrik * 75.000
  • Perkiraan biaya per bulan: $69,14
MiB yang diserap Tarif ($/MiB) Biaya ($)
150 0,00 $0,00
267 0,258 $69,14
Total 417 $69,14

Skenario 4: Anda memiliki 1 resource yang menuliskan 500.000 metrik. Ini adalah metrik yang dapat dikenakan biaya yang masing-masing menulis dengan kecepatan 1 titik data/menit.

  • Penyerapan bulanan: 167.084 MiB: 0,33416748 MiB untuk satu metrik * 500.000
  • Perkiraan biaya per bulan: $35.890,98
MiB yang diserap Tarif ($/MiB) Biaya ($)
150 0,00 $0,00
99.850 0,258 $25.761,30
67.084 0,151 $10.129,68
Total 167.084 $35.890,98

Harga untuk kemampuan kontrol dan prediksi

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 Prometheus dijalankan, dan ditagih melalui panggilan Cloud Monitoring API. Untuk mengetahui tarif saat ini, lihat tabel ringkasan untuk harga Managed Service for Prometheus atau harga Monitoring.

Contoh harga berdasarkan sampel yang diserap

Contoh berikut menggambarkan cara memperkirakan biaya untuk mengumpulkan metrik yang dikenakan biaya berdasarkan sampel yang diserap. Pengenaan biaya berbasis sampel digunakan untuk Google Cloud Managed Service for Prometheus

Contoh berikut dimaksudkan untuk menggambarkan teknik penghitungan, bukan untuk memberikan data penagihan.

Skenario dasarnya adalah sebagai berikut: Anda memiliki sejumlah container atau pod yang menulis titik di sejumlah deret waktu setiap bulan. Data tersebut dapat terdiri dari distribusi atau nilai skalar.

Variabel di seluruh skenario meliputi:

  • Jumlah container atau pod.
  • Jumlah deret waktu.
  • Apakah data tersebut terdiri dari nilai skalar, distribusi, atau keduanya.
  • Tarif untuk tempat penulisan data.

Menghitung sampel

Sebelum dapat memperkirakan harga, Anda perlu mengetahui cara menghitung sampel. Jumlah sampel yang dihitung untuk nilai bergantung pada berikut ini:

  • Apakah nilai merupakan skalar atau distribusi
  • Kecepatan penulisan nilai

Bagian ini menjelaskan cara memperkirakan jumlah sampel yang ditulis untuk deret waktu selama periode penagihan bulanan.

Dalam sebulan, ada sekitar 730 jam (365 hari / 12 bulan * 24 jam), 43.800 menit, atau 2.628.000 detik.

Jika deret waktu menulis nilai skalar, setiap nilai akan dihitung sebagai satu sampel. Jumlah sampel yang ditulis dalam sebulan hanya bergantung pada seberapa sering nilai tersebut ditulis. Perhatikan contoh berikut:

  • Untuk nilai yang ditulis setiap 15 detik:
    • Kecepatan tulis: 1 nilai/15 dtk = 1 sampel/15 dtk
    • Sampel per bulan: 175.200 (1 sampel/15 dtk * 2.628.000 detik/bulan)
  • Untuk nilai yang ditulis setiap 60 detik:
    • Kecepatan tulis: 1 nilai/60 dtk = 1 sampel/60 dtk
    • Sampel per bulan: 43.800 (1 sampel/60 dtk * 2.628.000 dtk/bulan)

Jika deret waktu menulis nilai distribusi, maka setiap nilai dapat berisi 2 + n sampel, dengan n adalah jumlah bucket dalam histogram. Jumlah sampel yang ditulis dalam sebulan bergantung pada jumlah bucket dalam histogram Anda dan seberapa sering nilai ditulis.

Misalnya, setiap instance dalam histogram 50 bucket dapat berisi 52 sampel. Jika nilainya ditulis sekali setiap 60 detik, maka histogram 50 bucket menulis maksimal 2.277.600 sampel per bulan. Jika histogram memiliki 100 bucket dan ditulis sekali setiap 60 detik, maka setiap histogram dapat berisi 102 sampel dan menulis maksimal 4.467.600 sampel per bulan.

Sebagian besar deret waktu distribusi berisi kurang dari jumlah maksimum sampel. Dalam praktiknya, antara 20% dan 40% bucket histogram kosong. Persentase ini bahkan lebih tinggi untuk pengguna dengan histogram sparse, seperti yang dihasilkan oleh Istio.

Saat menghitung sampel untuk harga, hanya bucket dengan nilai yang tidak kosong yang disertakan. Jumlah maksimum sampel per histogram adalah 2 + n . Jika 25% bucket Anda kosong, jumlah sampel yang diharapkan adalah 2 + 0,75n per histogram. Jika 40% bucket Anda kosong, jumlah sampel yang diharapkan adalah 2 + 0,60n per histogram.

Tabel penghitungan dan ringkasan berikut menunjukkan jumlah sampel maksimum dan jumlah sampel yang diharapkan dan lebih realistis:

  • Untuk nilai histogram 50 bucket yang ditulis setiap 15 detik:

    • Kecepatan tulis: 1 nilai/15 dtk
    • Sampel maksimum:
      • Per histogram: 52
      • Per bulan: 9.110.400 (52 * 1 nilai/15 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 25% kosong:
      • Per histogram: 39,5 (2 + 0.75(50), atau 2 + (50 - 12,5))
      • Per month: 6.920.400 (39,5 * 1 nilai/15 detik * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 40% kosong:
      • Per histogram: 32 (2 + 0,6(50), atau 2 + (50 - 20))
      • Per bulan: 5.606.400 (nilai 32 * 1 nilai/15 dtk * 2.628.000 detik/bulan)

  • Untuk nilai histogram 50 bucket yang ditulis setiap 60 detik:

    • Kecepatan tulis: 1 nilai/60 dtk
    • Sampel maksimum:
      • Per histogram: 52
      • Per bulan: 2.277.600 (52 * 1 nilai/60 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 25% kosong:
      • Per histogram: 39,5 (2 + 0.75(50), atau 2 + (50 - 12,5))
      • Per bulan: 1.730.100 (39,5 * 1 nilai/60 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 40% kosong:
      • Per histogram: 32 (2 + 0,6(50), atau 2 + (50 - 20))
      • Per bulan: 1.401.600 (32 x 1 nilai/60 dtk * 2.628.000 detik/bulan)

  • Untuk nilai histogram 100 bucket yang ditulis setiap 15 detik:

    • Kecepatan tulis: 1 nilai/15 dtk
    • Sampel maksimum:
      • Per histogram: 102
      • Per bulan: 17.870.400 (102 * 1 nilai/15 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 25% kosong:
      • Per histogram: 77 (2 + 0,75(100), atau 2 + (100-25))
      • Per bulan: 13.490.400 (77 * 1 nilai/15 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 40% kosong:
      • Per histogram: 62 (2 + 0,6(100), atau 2 + (100 - 40))
      • Per bulan: 10.862.400 (62 x 1 nilai/15 dtk * 2.628.000 detik/bulan)

  • Untuk nilai histogram 100 bucket yang ditulis setiap 60 detik:

    • Kecepatan tulis: 1 nilai/60 dtk
    • Sampel maksimum:
      • Per histogram: 102
      • Per bulan: 4.467.600 (102 * 1 nilai/60 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 25% kosong:
      • Per histogram: 77 (2 + 0,75(100), atau 2 + (100-25))
      • Per bulan: 3.372.600 (77 * 1 nilai/60 dtk * 2.628.000 detik/bulan)
    • Sampel yang diharapkan, dengan asumsi 40% kosong:
      • Per histogram: 62 (2 + 0,6(100), atau 2 + (100 - 40))
      • Per bulan: 2.715.600 (62 x 1 nilai/60 dtk * 2.628.000 detik/bulan)

Tabel berikut merangkum informasi sebelumnya:

Jumlah bucket Kecepatan tulis Sampel per bulan
(maks)		 Sampel per bulan
(25% kosong)		 Sampel per bulan
(40% kosong)
50 1 sampel/15 dtk 9.110.400 6.920.400 5.606.400
50 1 sampel/60 dtk 2.277.600 1.730.100 1.401.600
100 1 sampel/15 dtk 17.870.400 13.490.400 10.862.400
100 1 sampel/60 dtk 4.467.600 3.372.600 2.715.600

Contoh

Untuk memperkirakan harga, hitung jumlah sampel yang ditulis selama sebulan dan terapkan nilai harganya. Harga ditetapkan per satu juta, untuk rentang yang ditumpuk, sebagai berikut:

Rentang penyerapan Managed Service for Prometheus Maksimum untuk rentang
Hingga 50 miliar (50.000 juta) $0,06/juta $3.000,.00
50 miliar hingga 250 miliar (250.000 juta) $0,048/juta $9.600,00
250 miliar hingga 500 miliar (500.000 juta) $0,036/juta $9.000,00
Lebih dari 500 miliar (500.000 juta) $0,024/juta  

Bagian berikutnya dilanjutkan dengan kemungkinan skenario.

Skenario 1: Anda memiliki 100 container, masing-masing menulis 1.000 deret waktu skalar.

Varian A: Jika setiap deret waktu ditulis setiap 15 detik (1 sampel/15 dtk), maka jumlah sampel yang ditulis per bulan adalah 17.520.000.000 (175.200 sampel/bulan * 1.000 deret waktu * 100 container), atau 17.520 juta.

Varian B: Jika setiap deret waktu ditulis setiap 60 detik (1 sampel/60 dtk), maka jumlah sampel yang ditulis per bulan adalah 4.380.000.000 (43.800 sampel/bulan) * 1.000 deret waktu * 100 container), atau 4.380 juta.

Dalam kedua kasus ini, terdapat kurang dari 50.000 juta sampel sehingga hanya tarif pertama yang berlaku. Tidak ada sampel yang dikenakan biaya pada tarif lain.

Varian Sampel yang diserap Rentang penyerapan Managed Service for Prometheus
($0,06, $0,048, $0,036, $0,024)
A (1 sampel/15 dtk)



Total 		17.520 juta



17.520 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$1.051,20



$1.051,20
B (1 sampel/60 dtk)



Total 		4.380 juta



4.380 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$262,80



$262,80

Skenario 2: Anda memiliki 1.000 container, masing-masing menulis 1.000 deret waktu skalar.

Varian A: Jika setiap deret waktu ditulis setiap 15 detik (1 sampel/15 dtk), maka jumlah sampel yang ditulis per bulan adalah 175.200.000.000 atau 175.200 juta:

  • 50.000 juta sampel pertama dikenakan biaya dengan tarif pertama.
  • 125.200 juta sampel sisanya dikenakan biaya dengan tarif kedua.
  • Tidak ada sampel yang dikenakan biaya dengan tarif lain.

Varian B: Jika setiap deret waktu ditulis setiap 60 detik (1 sampel/60 dtk), maka jumlah sampel yang ditulis per bulan adalah 4.380.000.000 atau 43.800 juta. Nilai bulanan ini kurang dari 50.000 juta sampel sehingga hanya tarif pertama yang berlaku.

Varian Sampel yang diserap Rentang penyerapan Managed Service for Prometheus
($0,06, $0,048, $0,036, $0,024)
A (1 sampel/15 dtk)



Total 		50.000 juta
125.200 juta


175.200 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$3.000,00
$6.009,60


$9.009,60
B (1 sampel/60 dtk)



Total 		43.800 juta



43.800 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$2.628,00



$2.628,00

Skenario 3: Anda memiliki 100 container, yang masing-masing menulis 1.000 deret waktu distribusi 100 bucket. Anda memperkirakan 25% bucket akan kosong.

Varian A: Jika setiap deret waktu ditulis setiap 15 detik (1 sampel/15 dtk), maka jumlah sampel yang ditulis per bulan adalah 1.349.040.000.000 (13.490.400 sampel/bulan * 1.000 deret waktu * 100 container), atau 1.349.040 juta.

  • 50.000 juta sampel pertama dikenakan biaya dengan tarif pertama.
  • 200.000 juta sampel berikutnya dikenakan biaya dengan tarif kedua.
  • 250.000 juta sampel berikutnya dikenakan biaya dengan tarif ketiga.
  • 749.040 juta sampel sisanya dikenakan biaya dengan tarif keempat.

Varian B: Jika setiap deret waktu ditulis setiap 60 detik (1 sampel/60 dtk), maka jumlah sampel yang ditulis per bulan adalah 337.260.000.000 (3.372.600 sampel/bulan) * 1.000 deret waktu * 100 container), atau 337.260 juta.

  • 50.000 juta sampel pertama dikenakan biaya dengan tarif pertama.
  • 200.000 juta sampel berikutnya dikenakan biaya dengan tarif kedua.
  • 87.260 juta sampel sisanya dikenakan biaya dengan tarif ketiga.
Varian Sampel yang diserap Rentang penyerapan Managed Service for Prometheus
($0,06, $0,048, $0,036, $0,024)
A (1 sampel/15 dtk)



Total 		50.000 juta
200.000 juta
250.000 juta
749.040 juta
1.349.040 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$3.000,00
$9.600,00
$9.000,00
$17.976,96
$39.576,96
B (1 sampel/60 dtk)



Total 		50.000 juta
200.000 juta
87.260 juta

337.260 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$3.000,00
$9.600,00
$3.141,36

$15.741,36

Skenario 4: Anda memiliki 1.000 container, yang masing-masing menulis 10.000 deret waktu distribusi 100 bucket. Anda memperkirakan 40% bucket akan kosong.

Varian A: Jika setiap deret waktu ditulis setiap 15 detik (1 sampel/15 dtk), maka jumlah sampel yang ditulis per bulan adalah 108.624.000.000.000 (10.862.400 sampel/bulan * 10.000 deret waktu * 1.000 container), atau 108.624.000 juta.

  • 50.000 juta sampel pertama dikenakan biaya dengan tarif pertama.
  • 200.000 juta sampel berikutnya dikenakan biaya dengan tarif kedua.
  • 250.000 juta sampel berikutnya dikenakan biaya dengan tarif ketiga.
  • 108.124.000 juta sampel sisanya dikenakan biaya dengan tarif keempat.

Varian B: Jika setiap deret waktu ditulis setiap 60 detik (1 sampel/60 dtk), maka jumlah sampel yang ditulis per bulan adalah 27.156.000.000.000 (2.715.600 sampel/bulan) * 10.000 deret waktu * 1.000 container), atau 27.156.000 juta.

  • 50.000 juta sampel pertama dikenakan biaya dengan tarif pertama.
  • 200.000 juta sampel berikutnya dikenakan biaya dengan tarif kedua.
  • 250.000 juta sampel berikutnya dikenakan biaya dengan tarif ketiga.
  • 26.656.000 juta sampel sisanya dikenakan biaya dengan tarif keempat.
Varian Sampel yang diserap Rentang penyerapan Managed Service for Prometheus
($0,06, $0,048, $0,036, $0,024)
A (1 sampel/15 dtk)



Total 		50.000 juta
200.000 juta
250.000 juta
108.124.000 juta
108.624.000 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$3.000,00
$9.600,00
$9.000,00
$2.594.976,00
$2.616.576,00
B (1 sampel/60 dtk)



Total 		50.000 juta
200.000 juta
250.000 juta
26.656.000 juta
27.156.000 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$3.000,00
$9.600,00
$9.000,00
$639.744,00
$661.344,00

Skenario 5: Anda mengalami hal berikut:

  • 1.000 kontainer, masing-masing menulis 1.000 deret waktu skalar setiap 15 detik. Jumlah sampel yang ditulis per bulan adalah 175.200.000.000, atau 175.200 juta. (Skenario 2, varian A.)

  • 1.000 container, masing-masing menulis 10.000 deret waktu distribusi 100 bucket setiap 15 detik. Anda memperkirakan 40% bucket akan kosong. Jumlah sampel yang ditulis per bulan adalah 108.624.000.000.000 atau 108.624.000 juta. (Skenario 4, varian A.)

Jumlah total sampel per bulan adalah 108.799.200 juta (175.200 juta + 108.624.000 juta).

  • 50.000 juta sampel pertama dikenakan biaya dengan tarif pertama.
  • 200.000 juta sampel berikutnya dikenakan biaya dengan tarif kedua.
  • 250.000 juta sampel berikutnya dikenakan biaya dengan tarif ketiga.
  • 108.299.200 juta sampel sisanya dikenakan biaya dengan tarif keempat.
Varian Sampel yang diserap Rentang penyerapan Managed Service for Prometheus
($0,06, $0,048, $0,036, $0,024)
2A + 4A



Total 		50.000 juta
200.000 juta
250.000 juta
108.299.200 juta
108.799.200 juta 		Hingga 50.000 juta
Hingga 250.000 juta
Hingga 500.000 juta
Lebih dari 500.000 juta 		$3.000,00
$9.600,00
$9.000,00
$2.599.180,80
$2.620.780,80

Harga untuk eksekusi cek uptime (Tanggal mulai berlaku: 1 Oktober 2022)

Biaya pemantauan untuk setiap eksekusi cek uptime regional, di luar alokasi bulanan gratis sebesar 1 juta eksekusi. Cek yang dijalankan di tiga region dihitung sebagai tiga eksekusi.

Biaya untuk eksekusi cek uptime adalah $0,30/1.000 eksekusi. Biaya akan muncul di tagihan Anda sebagai SKU "CA14-D3DE-E67F" untuk "Memantau Cek Uptime".

Contoh berikut menggambarkan cara memperkirakan biaya untuk menjalankan cek uptime. Contoh berikut bertujuan untuk menggambarkan teknik penghitungan, bukan untuk memberikan data penagihan.

Menghitung eksekusi cek uptime

Untuk memperkirakan biaya cek uptime, Anda perlu mengetahui jumlah eksekusi regional yang terjadi dalam sebulan. Pemantauan mengenakan biaya sebesar $0,30/1.000 eksekusi, dengan alokasi bulanan gratis sebesar 1 juta eksekusi.

Untuk memperkirakan biaya cek uptime, Anda dapat menggunakan penghitungan berikut:

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Untuk setiap cek uptime, jumlah eksekusi bergantung pada pilihan konfigurasi berikut:

  • Seberapa sering cek uptime dieksekusi: setiap menit, 5 menit, 10 menit, atau 15 menit.

  • Jumlah region tempat cek uptime dieksekusi.

  • Jumlah target yang dikonfigurasi oleh cek uptime. Jika cek uptime dikonfigurasi untuk satu VM, jumlah targetnya adalah 1. Jika cek uptime dikonfigurasi untuk satu grup resource, jumlah target adalah jumlah resource dalam satu grup.

Saat mengonfigurasi cek uptime, Anda menentukan lokasi untuk cek uptime, dan setiap lokasi dipetakan ke satu atau beberapa region. Tabel berikut menunjukkan lokasi yang valid untuk cek uptime dan region yang dipetakan.

Lokasi untuk konfigurasi cek uptime Mencakup region Google Cloud
ASIA_PACIFIC asia-southeast1
EUROPE europe-west1
SOUTH_AMERICA southamerica-east1
USA us-central1, us-east4, us-west1
GLOBAL Semua region dicakup oleh lokasi lain

Anda harus mengonfigurasi cek uptime untuk dieksekusi di minimal tiga region.

Untuk memperkirakan jumlah eksekusi untuk cek uptime, Anda perlu mengetahui jumlah region yang dicakup oleh lokasi cek uptime.

  • ASIA_PACIFIC, EUROPE, dan SOUTH_AMERICA masing-masing mencakup 1 region.
  • USA mencakup 3 region.
  • GLOBAL mencakup 6 region.

Dalam sebulan, ada sekitar 730 jam (365 hari / 12 bulan * 24 jam) atau 43.800 menit.

  • Cek uptime yang dikonfigurasi untuk berjalan setiap satu menit di USA akan berjalan di 3 region. Jika cek uptime ini dikonfigurasi untuk memeriksa satu VM, maka cek uptime ini dieksekusi 131.400 (3 * 43.800) kali dalam sebulan. Jika cek ini dikonfigurasi untuk memeriksa grup resource yang berisi 10 anggota, maka cek uptime dieksekusi 1.314.000 (10 * 131.400) kali dalam sebulan.

  • Cek uptime yang dikonfigurasi untuk dijalankan setiap satu menit di ASIA_PACIFIC, EUROPE, dan USA berjalan di 5 region. Cek uptime ini dieksekusi 219.000 kali dalam sebulan jika dikonfigurasi untuk satu target.

Tabel berikut menunjukkan jumlah eksekusi per jam dan bulanan untuk satu cek uptime yang dikonfigurasi untuk berjalan dengan frekuensi berbeda di sejumlah region yang berbeda:

Frekuensi eksekusi cek, sekali setiap:
 		 Jumlah region
 		 Eksekusi per jam
per target		 Eksekusi per bulan
per target
1 menit 3
4
5
6 		180
240
300
360 		131.400
175.200
219.000
262.800
5 menit 3
4
5
6 		36
48
60
72 		26.280
35.040
43.000
52.660
10 menit 3
4
5
6 		18
24
30
36 		13.140
17.520
21.900
26.280
15 menit 3
4
5
6 		12
16
20
24 		8.760
11.680
14.600
17.520

Contoh

Untuk memperkirakan harga, tentukan total eksekusi bulanan Anda dan kurangi 1.000.000. Semua eksekusi tersisa akan dikenakan biaya sebesar $0,30/1.000 eksekusi sehingga kalikan hasil eksekusi yang tersisa dengan 0,0003.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Skenario 1: Anda memiliki 1 cek uptime di lokasi USA yang memeriksa 1 VM sekali dalam semenit. Cek ini berjalan di 3 region. Cek ini dieksekusi 131.400 kali dalam sebulan dan tidak dikenakan biaya.

Total eksekusi bulanan
 		 Eksekusi bulanan yang dapat dikenakan biaya
(lebih dari 1.000.000)		 Biaya
($0,30/1.000 eksekusi)
131.400 0 $0,00

Skenario 2: Anda memiliki 1 cek uptime di lokasi USA yang memeriksa grup resource yang berisi 10 anggota sekali dalam satu menit. Cek ini berjalan di 3 region. Cek ini dieksekusi 10 * 131.400 kali sebulan dan biayanya sebesar $94,20/bulan. Satu-satunya perbedaan antara skenario ini dan Skenario 1 adalah jumlah target.

Total eksekusi bulanan
 		 Eksekusi bulanan yang dapat dikenakan biaya
(lebih dari 1.000.000)		 Biaya
($0,30/1.000 eksekusi)
1.314.000 (10 target) 314.000 $94,20

Skenario 3: Anda memiliki 10 cek uptime GLOBAL, yang masing-masing memeriksa 1 VM sekali dalam semenit. Cek ini berjalan di 6 region sehingga setiap cek dieksekusi 262.800 kali dalam sebulan. Total eksekusi bulanan adalah 2.628.000 (10 * 262.800). Skenario ini dikenakan biaya $488,40/bulan.

Total eksekusi bulanan
 		 Eksekusi bulanan yang dapat dikenakan biaya
(lebih dari 1.000.000)		 Biaya
($0,30/1.000 eksekusi)
2.628.,000 1.628.000 $488,40

Skenario 4: Anda memiliki 5 cek uptime di lokasi USA yang memeriksa 1 VM sekali setiap 5 menit. Cek ini berjalan di 3 region sehingga setiap cek dieksekusi 26.280 kali dalam sebulan. Total eksekusi bulanan untuk set cek ini adalah 105.120 (4 * 26.280).

Anda juga memiliki 2 cek uptime GLOBAL yang memeriksa 1 VM sekali setiap 15 menit. Cek ini berjalan di 6 region sehingga setiap cek dieksekusi 17.520 kali dalam sebulan. Total eksekusi bulanan untuk set cek ini adalah 35.040 (2 * 17.520).

Total eksekusi bulanan Anda adalah 140.160 (105.120 + 35.040). Skenario ini tidak dikenakan biaya.

Total eksekusi bulanan
 		 Eksekusi bulanan yang dapat dikenakan biaya
(lebih dari 1.000.000)		 Biaya
($0,30/1.000 eksekusi)
140.160 0 $0,00

Harga untuk eksekusi monitor sintetis (Tanggal mulai berlaku: 1 November 2023)

Cloud Monitoring mengenakan biaya untuk setiap eksekusi monitor sintetis, di luar alokasi gratis per bulan sebanyak 100 eksekusi per akun penagihan. Misalnya, jika Anda membuat 3 monitor sintetis dan mengonfigurasi masing-masingnya untuk dieksekusi setiap 5 menit, maka jumlah total eksekusi per bulan adalah 26.784:

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

Untuk menentukan jumlah eksekusi yang dapat dikenakan biaya, kurangi alokasi gratis dari jumlah total eksekusi, lalu kalikan hasilnya dengan biaya:

Total eksekusi bulanan
 		 Eksekusi bulanan yang dikenakan biaya
(lebih dari 100 eksekusi per akun penagihan)		 Biaya
($1,20/1.000 eksekusi)
26.784 26.684 $32,02

Harga untuk pemberitahuan

Mulai 7 Januari 2025, Cloud Monitoring akan mulai membebankan biaya untuk pemberitahuan. Model penetapan harganya adalah sebagai berikut:

  • $1,50 per bulan untuk setiap kondisi dalam kebijakan pemberitahuan.
  • $0,35 per 1.000.000 deret waktu yang ditampilkan oleh kueri kondisi kebijakan pemberitahuan metrik.

Bagian ini memberikan informasi berikut:

Definisi

  • Kondisi: Kondisi kebijakan pemberitahuan menjelaskan kapan resource, atau sekelompok resource, yang memerlukan respons.

    Biaya dikenakan untuk setiap kondisi $1,50 per bulan. Agar berhenti ditagih untuk suatu kondisi, Anda harus menghapus kebijakan pemberitahuan. Menunda atau menonaktifkan kebijakan tidak menghentikan Anda agar tidak ditagih.

  • Kebijakan pemberitahuan metrik dan berbasis log: Kebijakan pemberitahuan yang menggunakan jenis kondisi apa pun kecuali kondisi pencocokan log adalah pemberitahuan metrik kebijakan; kondisi kebijakan pemberitahuan metrik menampilkan deret waktu. Selama setiap periode eksekusi, kondisi dalam kebijakan pemberitahuan metrik akan mengeksekusi kueri mereka terhadap datastore Cloud Monitoring. URL yang dikembalikan deret waktu kemudian dievaluasi terhadap ambang batas untuk menentukan apakah pengaktifan kebijakan pemberitahuan.

    Kebijakan pemberitahuan berbasis log menggunakan kondisi pencocokan log. Kondisi pencocokan log tidak menampilkan deret waktu.

  • Periode eksekusi: Seberapa sering Cloud Monitoring mengeksekusi . Untuk sebagian besar jenis kondisi, durasinya adalah 30 detik dan tidak dapat ubah. Kondisi yang menggunakan kueri PromQL dapat menetapkan periode ini. Untuk informasi selengkapnya, lihat Menambah durasi periode eksekusi (Khusus PromQL).

  • Deret waktu yang ditampilkan: Selama setiap periode eksekusi, metrik mengirimkan pemberitahuan kebijakan mengeksekusi kueri kondisinya terhadap Cloud Monitoring datastore. Cloud Monitoring menampilkan data deret waktu sebagai respons terhadap setiap kueri. Setiap deret waktu dalam respons dihitung sebagai satu deret waktu dikembalikan.

    Jumlah deret waktu yang ditampilkan dalam satu bulan ditentukan oleh tiga faktor:

    • Bentuk dan cakupan data pokok.
    • Filter dan agregasi yang digunakan dalam kueri kondisi Anda.
    • Periode eksekusi.

    Misalnya, pertimbangkan konfigurasi yang memiliki hal berikut:

    • 100 virtual machine (VM), dengan setiap VM dimiliki oleh satu layanan.
    • Setiap VM memunculkan satu metrik, metric_name, yang memiliki label dengan 10 nilai.
    • Total lima layanan.

    Karena Anda memiliki 100 VM, yang masing-masing dapat menghasilkan 10 deret waktu (satu untuk setiap nilai label), Anda memiliki total 1.000 deret waktu yang mendasarinya. Setiap VM juga memiliki label mirip metadata yang merekam layanan mana yang memiliki VM.

    Anda dapat mengonfigurasi kebijakan pemberitahuan dengan cara berikut menggunakan PromQL, dengan setiap konfigurasi menghasilkan angka yang berbeda dari deret waktu yang ditampilkan per periode eksekusi:

    Konfigurasi Kueri PromQL Deret waktu yang ditampilkan per periode
    Tidak ada agregasi rate(metric_name[1m]) 1.000
    Menggabungkan ke VM sum by (vm) (rate(metric_name[1m])) 100
    Agregat ke nilai label sum by (label_key) (rate(metric_name[1m])) 10
    Menggabungkan ke layanan sum by (service) (rate(metric_name[1m])) 5
    Gabungan untuk memberi label pada nilai dan layanan sum by (service, label_key) (rate(metric_name[1m])) 50
    Agregat ke fleet sum (rate(metric_name[1m])) 1
    Memfilter dan menggabungkan ke satu VM sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Memfilter dan menggabungkan ke satu layanan sum (rate(metric_name{service="my_service_name"}[1m])) 1

Contoh penghitungan harga

Contoh berikut dilakukan dalam sebulan 30 hari, sehingga menghasilkan hal berikut periode evaluasi:

  • 86.400 periode eksekusi 30 detik per bulan
  • 172.800 periode eksekusi selama 15 detik per bulan (khusus kueri PromQL)

Contoh 1: Satu kebijakan, digabungkan dengan VM, 30 detik

Dalam contoh ini, gunakan konfigurasi berikut:

Data

  • 100 VM
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi pemberitahuan
  • Menggabungkan kondisi ke level VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 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: $4,52 per bulan

Contoh 2: 100 kebijakan (satu per VM), digabungkan dengan VM, 30 detik

Dalam contoh ini, gunakan konfigurasi berikut:

Data

  • 100 VM
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • 100 kondisi
  • Setiap kondisi difilter dan digabungkan ke dalam satu VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • Biaya kondisi: 100 kondisi * $1,50 per bulan = $150 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: $153,02 per bulan

Contoh 3: Satu kebijakan, digabungkan dengan VM, 15 detik

Dalam contoh ini, gunakan konfigurasi berikut:

Data

  • 100 VM
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi pemberitahuan PromQL
  • Menggabungkan kondisi ke level VM
  • Periode eksekusi selama 15 detik
Hasil biaya
  • Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 per bulan
  • Biaya deret waktu: 100 deret waktu yang ditampilkan per periode * 172.800 periode per bulan = 17,3 juta deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $6,05 per bulan
  • Total biaya: $7,55 per bulan

Contoh 4: Menggabungkan satu kebijakan ke setiap layanan, 30 detik

Dalam contoh ini, gunakan konfigurasi berikut:

Data

  • 100 VM, dengan setiap VM termasuk dalam satu layanan
  • Lima layanan total
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki satu label, yang memiliki 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi
  • Menggabungkan kondisi ke tingkat layanan
  • Periode eksekusi selama 30 detik
Hasil biaya
  • Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 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: $1,64 per bulan

Contoh 5: Menggabungkan satu kebijakan ke VM; kardinalitas dasar yang lebih tinggi per VM, 30 detik

Dalam contoh ini, gunakan konfigurasi berikut:

Data

  • 100 VM
  • Setiap VM menghasilkan satu metrik, metric_name
  • metric_name memiliki 100 label yang masing-masing berisi 1.000 nilai
Kebijakan pemberitahuan
  • Satu kondisi
  • Menggabungkan kondisi ke level VM
  • Periode eksekusi selama 30 detik
Hasil biaya
  • Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 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: $4,52 per bulan

Contoh 6: Menggabungkan satu kebijakan ke VM; gabungan dua metrik dalam satu kondisi, 30 detik

Dalam contoh ini, gunakan konfigurasi berikut:

Data

  • 100 VM
  • Setiap VM memunculkan dua metrik, metric_name_1 dan metric_name_2
  • Kedua metrik memiliki satu label yang masing-masing berisi 10 nilai
Kebijakan pemberitahuan
  • Satu kondisi
  • Menggabungkan kondisi ke level VM
  • Kondisi menggunakan operator OR untuk menggabungkan metrik
  • Periode eksekusi selama 30 detik
Hasil biaya
  • Biaya kondisi: 1 kondisi * $1,50 per bulan = $1,50 per bulan
  • Biaya deret waktu: 2 metrik * 100 deret waktu yang ditampilkan per metrik per periode * 86400 periode per bulan = 17,3 juta deret waktu yang ditampilkan per bulan * $0,35 per juta deret waktu = $6,05 per bulan
  • Total biaya: $7,55 per bulan

Contoh 7: 100 kebijakan pemberitahuan berbasis log

Dalam contoh ini, gunakan konfigurasi berikut:

Kebijakan pemberitahuan

  • 100 kondisi (satu kondisi per kebijakan pemberitahuan berbasis log)
Hasil biaya
  • Biaya kondisi: 100 kondisi * $1,50 per bulan = $150,00 per bulan
  • Biaya deret waktu: $0 (Kebijakan pemberitahuan berbasis log tidak menampilkan deret waktu.)
  • Total biaya: $150,00 per bulan

Saran untuk mengurangi tagihan pemberitahuan

Saat Anda mengonfigurasi kebijakan pemberitahuan berbasis metrik, gunakan saran untuk membantu mengurangi biaya tagihan pemberitahuan.

Mengonsolidasikan kebijakan pemberitahuan untuk beroperasi di lebih banyak resource

Karena biayanya $1,50 per kondisi, lebih hemat biaya penggunaan satu kebijakan pemberitahuan untuk memantau beberapa resource daripada menggunakan satu kebijakan pemberitahuan untuk memantau setiap resource. Misalnya, bandingkan Contoh 1 dengan Contoh 2: Dalam kedua contoh tersebut, 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 $150 lebih murah per bulan.

Gabungkan ke level yang perlu Anda buat notifikasinya

Penggabungan ke tingkat perincian yang lebih tinggi menghasilkan biaya yang lebih tinggi daripada mengagregasikan ke tingkat perincian yang lebih rendah. Misalnya, menggabungkan ke level project Google Cloud lebih murah daripada tingkat cluster, dan menggabungkan ke tingkat cluster lebih murah daripada menggabungkan ke tingkat cluster dan namespace.

Misalnya, bandingkan Contoh 1 dengan Contoh 4: Kedua contoh beroperasi pada data pokok yang sama dan memiliki satu peringatan lebih lanjut. Namun, karena kebijakan pemberitahuan di Contoh 4 digabungkan ke layanan, lebih murah daripada kebijakan pemberitahuan di Contoh 1, yang secara lebih terperinci ke VM.

Selain itu, bandingkan Contoh 1 dengan Contoh 5: Dalam hal ini, kardinalitas metrik di Contoh 5 10.000 kali lebih tinggi dari kardinalitas metrik di Contoh 1. Namun, karena kebijakan pemberitahuan di Contoh 1 dan dalam Contoh 5 digabungkan ke VM, dan karena jumlah VM di kedua contoh itu sama, contohnya setara harga.

Saat mengonfigurasi kebijakan pemberitahuan, pilih tingkat agregasi yang paling cocok untuk kasus penggunaan Anda. Misalnya, jika Anda ingin memberi peringatan pada CPU tingkat tinggi, maka Anda mungkin ingin menggabungkan ke level VM dan CPU. Jika Anda memperhatikan pemberitahuan latensi oleh endpoint, maka Anda mungkin ingin ke level endpoint.

Jangan beri tahu tentang data mentah yang tidak diagregasi

Pemantauan menggunakan sistem metrik dimensi, di mana setiap metrik memiliki total kardinalitas yang sama dengan jumlah resource yang dipantau dikalikan dengan jumlah kombinasi label pada metrik tersebut. Sebagai jika Anda memiliki 100 VM yang memunculkan metrik, dan metrik tersebut memiliki 10 label dengan masing-masing 10 nilai, maka total kardinalitas Anda adalah 100 * 10 * 10 = 10.000.

Karena bagaimana kardinalitas melakukan penskalaan, pemberitahuan tentang data mentah bisa sangat mahal. Pada contoh sebelumnya, Anda memiliki 10.000 deret waktu yang ditampilkan untuk setiap periode eksekusi. Namun, jika Anda melakukan agregasi ke VM, maka Anda memiliki hanya 100 deret waktu yang ditampilkan per periode eksekusi, terlepas dari labelnya kardinalitas data pokok.

Memberi tahu data mentah juga membuat Anda berisiko mengalami peningkatan deret waktu saat metrik Anda menerima label baru. Pada contoh sebelumnya, jika pengguna menambahkan label baru ke metrik, maka total kardinalitas Anda akan meningkat menjadi 100 * 11 * 10 = 11.000 deret waktu. Dalam hal ini, jumlah pengembalian deret waktu meningkat 1.000 setiap periode eksekusi meskipun pemberitahuan kebijakan tidak berubah. Jika Anda memilih melakukan agregasi ke VM, meskipun peningkatan kardinalitas dasar, Anda tetap hanya memiliki 100 deret waktu yang ditampilkan.

Memfilter respons yang tidak perlu

Konfigurasi kondisi Anda untuk hanya mengevaluasi data yang diperlukan bagi kebutuhan pemberitahuan lebih lanjut. Jika Anda tidak akan mengambil tindakan untuk memperbaiki sesuatu, kecualikan dari kebijakan pemberitahuan Anda. Misalnya, Anda mungkin tidak perlu memberi tahu di VM pengembangan pekerja magang.

Untuk mengurangi pemberitahuan 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 dan kemudian menyaring kategori {i>metadata<i} yang tidak diperlukan.

Menggunakan operator streaming teratas untuk mengurangi jumlah deret waktu yang ditampilkan

Jika kondisi Anda menggunakan kueri PromQL atau MQL, maka Anda dapat menggunakan operator top-stream untuk memilih sejumlah deret waktu yang ditampilkan dengan nilai tertinggi:

Misalnya, klausa topk(metric, 5) dalam batas kueri PromQL jumlah deret waktu yang dikembalikan menjadi lima di setiap periode eksekusi.

Membatasi ke jumlah deret waktu teratas dapat mengakibatkan hilangnya data dan pemberitahuan yang salah, seperti:

  • Jika lebih dari N deret waktu melanggar batas, Anda akan kehilangan data di luar deret waktu N teratas.
  • Jika deret waktu yang melanggar terjadi di luar deret waktu N teratas, insiden Anda mungkin tertutup otomatis meskipun deret waktu yang dikecualikan tetap yang melanggar batas.
  • Kueri kondisi Anda mungkin tidak menunjukkan konteks penting seperti dasar pengukuran deret waktu yang berfungsi sebagaimana mestinya.

Untuk mengurangi risiko tersebut, pilih nilai besar untuk N dan gunakan aliran data teratas operator hanya dalam kebijakan pemberitahuan yang mengevaluasi banyak deret waktu, seperti untuk setiap container Kubernetes.

Menambah durasi periode eksekusi (khusus PromQL)

Jika kondisi Anda menggunakan kueri PromQL, Anda dapat mengubah durasinya periode eksekusi dengan menetapkan Kolom evaluationInterval di kondisi.

Interval evaluasi yang lebih lama menghasilkan deret waktu yang lebih sedikit per bulan; misalnya, kueri kondisi dengan interval 15 detik berjalan dua kali lebih sering sebagai kueri dengan interval 30 detik, dan kueri dengan interval 1 menit berjalan setengah lebih sering dibandingkan kueri dengan interval 30 detik.

Tidak ikut serta

Jika Anda memiliki kontrak Google Cloud yang masih berlaku yang akan berakhir hingga 7 Januari 2025, Anda dapat menunda penagihan untuk pemberitahuan hingga kontrak jatuh tempo perpanjangan dengan meminta pengecualian dari Cloud Monitoring memberi tahu tim penagihan. Pengecualian bagi pelanggan dengan kontrak aktif akan dipertimbangkan untuk setiap kasus.

Anda dapat meminta pengecualian hingga 1 November 2024. Untuk meminta pengecualian penagihan hingga perpanjangan kontrak, isi formulir permintaan pengecualian penagihan.

Error Reporting

Untuk mengetahui informasi harga saat ini, lihat Harga Error Reporting.

Untuk mengetahui batas yang berlaku untuk penggunaan Error Reporting, lihat Kuota dan batas.

Cloud Profiler

Penggunaan Cloud Profiler tidak dikenakan biaya.

Untuk mengetahui batas yang berlaku pada penggunaan Profiler, lihat Kuota dan batas.

Cloud Trace

Biaya Trace dihitung didasarkan pada jumlah span trace yang diserap dan dipindai: Ketika dikirim ke Trace, data latensi dikemas sebagai trace yang terdiri dari span, dan durasinya diserap oleh backend Cloud Trace. Saat Anda melihat data trace, span yang disimpan akan dipindai oleh Cloud Trace. Bagian ini memberikan informasi berikut:

  • Menentukan trace space yang dapat dikenakan biaya dan tidak dapat dikenakan biaya
  • Memberikan contoh harga
  • Memberikan informasi tentang cara mengurangi penyerapan span trace Anda.
  • Memberikan setelan untuk kebijakan pemberitahuan yang dapat memberi tahu Anda jika penyerapan span trace Anda mencapai batas

Untuk mengetahui informasi harga saat ini, lihat Harga Cloud Trace.

Untuk mengetahui batas yang berlaku pada penggunaan Trace, lihat Kuota dan batas.

Untuk mengetahui informasi cara melihat penggunaan saat ini atau sebelumnya, lihat Memperkirakan tagihan Anda.

Span trace yang tidak dapat dikenakan biaya

Harga Cloud Trace tidak berlaku untuk span yang dihasilkan secara otomatis oleh App Engine Standard, Cloud Functions, atau Cloud Run: penyerapan trace ini tidak dapat dikenakan biaya.

Span trace yang dapat dikenakan biaya

Penyerapan span trace kecuali untuk span yang tercantum di bagian berjudul Trace tidak dapat dikenakan biaya, dapat dikenakan biaya dan diberi harga berdasarkan volume yang diserap. Hal ini mencakup span yang dibuat oleh instrumentasi yang Anda tambahkan ke aplikasi App Engine Standard.

Contoh penghitungan harga

Contoh ini untuk harga Trace per Juli 2020.

  • Jika Anda menyerap 2 juta span dalam sebulan, biayanya adalah $0. (2,5 juta span pertama yang diserap dalam sebulan tidak dikenakan biaya.)
  • Jika Anda menyerap 14 juta span dalam sebulan, biayanya adalah $2,30. (2,5 juta span pertama dalam sebulan tidak dikenakan biaya. Biaya span sisanya dihitung sebagai 11,5 juta span * $0,20/juta span = $2,30.)
  • Jika Anda menyerap 1 miliar span dalam sebulan, biayanya adalah $199. (2,5 juta span pertama dalam sebulan tidak dikenakan biaya. Biaya span sisanya dihitung sebagai 997,5 juta span * $0,20/juta span = $199,50.)

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.

Memberi tahu tentang span 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.

GKE Enterprise

Log dan metrik sistem GKE Enterprise tidak dikenai biaya. Log bidang kontrol, metrik bidang kontrol, dan subset metrik status Kube yang diseleksi adalah diaktifkan secara default untuk cluster GKE di Google Cloud yang terdaftar pada waktu pembuatan cluster di project yang mengaktifkan GKE Enterprise. Log bidang kontrol dikenai biaya Cloud Logging, sedangkan metrik yang diaktifkan secara default disertakan tanpa biaya tambahan.

Untuk mengetahui daftar log dan metrik GKE yang disertakan, lihat Log apa yang dikumpulkan dan Metrik yang tersedia.

Di cluster Google Distributed Cloud, log dan metrik sistem GKE Enterprise meliputi hal berikut:

  • Log dan metrik dari semua komponen dalam cluster admin
  • Log dan metrik dari komponen dalam namespace ini di cluster pengguna: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

Pertanyaan umum (FAQ)

Fitur produk manakah yang dapat digunakan secara gratis?

Penggunaan produk Google Cloud Observability dikenai biaya berdasarkan volume data. Selain biaya volume data yang dijelaskan di halaman ini, penggunaan semua Fitur produk Kemampuan Observasi Google Cloud tersedia gratis.

Berapa jumlah yang harus saya bayar?

Untuk memperkirakan biaya penggunaan, lihat Memperkirakan tagihan Anda.

Untuk mendapatkan bantuan terkait pertanyaan mengenai penagihan, lihat Pertanyaan tentang Penagihan.

Bagaimana cara saya memahami detail penggunaan saya?

Beberapa metrik memungkinkan Anda melihat perincian serta memahami volume log dan metrik menggunakan Metrics Explorer. lihat Melihat penggunaan mendetail di Metrics Explorer untuk mengetahui detailnya.

Jika Anda tertarik untuk mempelajari cara mengelola biaya, lihat blog ini postingan:

Bagaimana pengaruh cakupan metrik terhadap penagihan?

Pada umumnya, cakupan metrik tidak memengaruhi penagihan. Log dan metrik dikenakan biaya di project Google Cloud yang menerima data. Cakupan metrik untuk suatu project menentukan kumpulan project yang metriknya dapat dilihat dan dipantau oleh project tersebut. Saat menentukan cakupan metrik, Anda tidak memengaruhi project mana yang menerima data metrik atau menyebabkan data diduplikasi.

Misalkan organisasi Anda memiliki 100 virtual machine (VM): 60 VM dihosting oleh Project-A dan 40 VM berada di Project-B. Project-A menerima dan menyimpan metrik untuk VM-nya, dan akan dikenakan biaya saat metrik dapat dikenakan biaya. Demikian pula, Project-B menerima dan menyimpan metrik untuk VM-nya, dan dikenakan biaya saat metrik dapat dikenakan biaya. Jika membuat cakupan metrik yang mencakup Project-A dan Project-B, Anda dapat melihat metrik gabungan untuk 100 VM. Sekarang Anda dapat melihat hanya metrik untuk Project-A, hanya metrik Project-B, atau kombinasi metrik. Meskipun Anda memiliki dua cara untuk melihat metrik Project-A, tidak ada implikasi penagihan.

Dalam hal pemantauan akun AWS, Anda harus menghubungkan akun AWS ke Google Cloud dengan membuat Project AWS Connector. Project konektor menyimpan log dan memantau data untuk akun AWS.

Apa yang terjadi jika saya melampaui alokasi gratis?

Anda akan otomatis ditagih untuk penggunaan apa pun yang melebihi alokasi gratis Anda. Anda tidak akan kehilangan log atau metrik. Untuk lebih memahami tentang kemungkinan biaya, lihat Memperkirakan tagihan Anda.

Anda dapat membuat kebijakan pemberitahuan yang memantau penggunaan Anda dan memberi tahu Anda ketika sudah mencapai ambang batas untuk penagihan.

Saya memiliki banyak log Google Cloud di project yang tidak digunakan. Saya khawatir dengan tagihan atas log yang tidak digunakan tersebut. Bagaimana cara menghindarinya?

Anda dapat mengecualikan log untuk mengontrol log yang akan diserap ke dalam Logging. Lihat Mengurangi penggunaan log untuk mengetahui detail lebih lanjut.

Apakah layanan yang mengirim log ke project saya akan menerima error jika log dikecualikan?

Tidak. Layanan yang mengirim entri log tidak dapat menentukan apakah entri log diserap ke dalam Logging atau tidak.

Apakah saya akan dikenai biaya dua kali untuk log alur Virtual Private Cloud?

Jika Anda mengirim log alur VPC ke Logging, pembuatan log aliran VPC tidak dikenai biaya, dan hanya biaya Logging saja yang berlaku. Namun, jika Anda mengirimnya dan kemudian mengecualikan log alur VPC dari Logging, biaya log alur VPC akan berlaku. Untuk informasi selengkapnya, lihat Kalkulator Harga Google Cloud lalu pilih tab berjudul "Cloud Load Balancing and Network Services".

1 Untuk penetapan harga, semua unit diperlakukan sebagai ukuran biner misalnya, sebagai mebibyte (MiB atau 220 byte) atau gibibyte (GiB atau 230 byte).

2 Tidak ada biaya untuk metrik Google Cloud atau metrik GKE Enterprise yang diukur pada hingga 1 titik data per menit, resolusi tertinggi saat ini. Di masa mendatang, metrik yang diukur pada resolusi lebih tinggi mungkin akan dikenakan biaya.

3 Metrik proses saat ini dikumpulkan dengan kecepatan default yang telah ditentukan sebelumnya, yaitu sekali per menit dan tidak dapat diubah. Data ini umumnya berubah secara perlahan sehingga metrik ini saat ini diambil sampelnya secara berlebihan. Oleh karena itu, metrik proses pengenaan biaya sebesar 5% dari tarif standar sesuai dengan tarif standar jika metrik diambil sampelnya pada interval 20 menit. Pengguna yang mengumpulkan 100 MiB data dari metrik ini hanya dikenakan biaya untuk 5 MiB.

Langkah berikutnya

Meminta penawaran harga khusus

Dengan model harga bayar sesuai penggunaan Google Cloud, Anda hanya membayar untuk layanan yang Anda gunakan. Hubungi tim penjualan kami untuk mendapatkan penawaran harga khusus bagi organisasi Anda.
Hubungi bagian penjualan