Kontrol dan atribusi biaya

Google Cloud Managed Service for Prometheus mengenakan biaya untuk jumlah sampel yang diserap ke dalam Cloud Monitoring dan untuk permintaan baca ke Monitoring API. Jumlah sampel yang diserap adalah kontributor utama terhadap biaya Anda.

Dokumen ini menjelaskan cara mengontrol biaya yang terkait dengan penyerapan metrik dan cara mengidentifikasi sumber penyerapan bervolume tinggi.

Untuk mengetahui informasi selengkapnya tentang harga Managed Service for Prometheus, lihat ringkasan harga Google Cloud Managed untuk Prometheus.

Lihat tagihan Anda

Untuk melihat tagihan Google Cloud Anda, lakukan langkah berikut:

Di konsol Google Cloud, buka halaman Penagihan.

Buka Penagihan
Jika Anda memiliki lebih dari satu akun penagihan, pilih Go to linked billing account untuk melihat akun penagihan project saat ini. Untuk menemukan akun penagihan lain, pilih Manage billing accounts dan pilih akun yang ingin Anda dapatkan laporan penggunaannya.
Di bagian Pengelolaan biaya di menu navigasi Penagihan, pilih Laporan.
Dari menu Services, pilih opsi Cloud Monitoring.
Dari menu SKU, pilih opsi berikut:
- Sampel Prometheus yang Diserap
- Permintaan Monitoring API

Screenshot berikut menampilkan laporan penagihan untuk Google Cloud Managed Service for Prometheus dari satu project:

Laporan penagihan untuk Google Cloud Managed Service for Prometheus menunjukkan penggunaan saat ini dan yang diproyeksikan.

Mengurangi biaya Anda

Untuk mengurangi biaya terkait penggunaan Google Cloud Managed Service for Prometheus, Anda dapat melakukan hal berikut:

Kurangi jumlah deret waktu yang Anda kirim ke layanan terkelola dengan memfilter data metrik yang Anda hasilkan.
Kurangi jumlah sampel yang Anda kumpulkan dengan mengubah interval scraping.
Batasi jumlah sampel dari metrik berkardinalitas tinggi yang berpotensi salah dikonfigurasi.

Mengurangi jumlah deret waktu

Dokumentasi Prometheus open source jarang merekomendasikan pemfilteran volume metrik, yang wajar jika biaya dibatasi oleh biaya mesin. Namun, saat membayar penyedia layanan terkelola per unit, mengirim data tanpa batas dapat menyebabkan tagihan yang tidak perlu tinggi.

Pengekspor yang disertakan dalam project kube-prometheus—khususnya layanan kube-state-metrics—dapat menghasilkan banyak data metrik. Misalnya, layanan kube-state-metrics memunculkan ratusan metrik, yang banyak di antaranya mungkin sama sekali tidak berharga bagi Anda sebagai konsumen. Cluster tiga node baru yang menggunakan project kube-prometheus mengirimkan sekitar 900 sampel per detik ke Google Cloud Managed Service for Prometheus. Memfilter metrik yang tidak relevan ini mungkin sudah cukup untuk menurunkan tagihan Anda ke tingkat yang dapat diterima.

Untuk mengurangi jumlah metrik, Anda dapat melakukan hal berikut:

Ubah konfigurasi scrape Anda untuk menyalin lebih sedikit target.
Filter metrik yang dikumpulkan seperti yang dijelaskan sebagai berikut:
- Memfilter metrik yang diekspor saat menggunakan koleksi terkelola.
- Memfilter metrik yang diekspor saat menggunakan koleksi yang di-deploy sendiri.

Jika menggunakan layanan kube-state-metrics, Anda dapat menambahkan aturan pelabelan ulang Prometheus dengan tindakan keep. Untuk koleksi terkelola, aturan ini berlaku di definisi PodMonitoring atau ClusterPodMonitoring Anda. Untuk pengumpulan yang di-deploy sendiri, aturan ini masuk ke dalam konfigurasi scrape Prometheus atau definisi ServiceMonitor (untuk prometheus-operator).

Misalnya, penggunaan filter berikut pada cluster tiga node baru akan mengurangi volume sampel sekitar 125 sampel per detik:

  metricRelabeling:
  - action: keep
    regex: kube_(daemonset|deployment|pod|namespace|node|statefulset|persistentvolume|horizontalpodautoscaler)_.+
    sourceLabels: [__name__]

Filter sebelumnya menggunakan ekspresi reguler untuk menentukan metrik yang akan dipertahankan berdasarkan nama metrik. Misalnya, metrik yang namanya diawali dengan kube_daemonset_ akan disimpan. Anda juga dapat menentukan tindakan drop, yang memfilter metrik yang cocok dengan ekspresi reguler.

Terkadang, Anda mungkin menganggap seluruh pengekspor tidak penting. Misalnya, paket kube-prometheus menginstal pemantauan layanan berikut secara default, yang banyak di antaranya tidak diperlukan di lingkungan terkelola:

alertmanager
coredns
grafana
kube-apiserver
kube-controller-manager
kube-scheduler
kube-state-metrics
kubelet
node-exporter
prometheus
prometheus-adapter
prometheus-operator

Untuk mengurangi jumlah metrik yang diekspor, Anda dapat menghapus, menonaktifkan, atau menghentikan scraping monitor layanan yang tidak diperlukan. Misalnya, menonaktifkan monitor layanan kube-apiserver pada cluster tiga node baru akan mengurangi volume sampel Anda sekitar 200 sampel per detik.

Mengurangi jumlah sampel yang dikumpulkan

Google Cloud Managed Service for Prometheus mengenakan biaya per sampel. Anda dapat mengurangi jumlah sampel yang diserap dengan menambah durasi periode pengambilan sampel. Contoh:

Mengubah periode pengambilan sampel 10 detik menjadi periode pengambilan sampel 30 detik dapat mengurangi volume sampel sebesar 66%, tanpa banyak kehilangan informasi.
Mengubah periode pengambilan sampel 10 detik menjadi periode pengambilan sampel 60 detik dapat mengurangi volume sampel sebesar 83%.

Untuk mengetahui informasi tentang cara sampel dihitung dan pengaruh periode pengambilan sampel terhadap jumlah sampel, lihat Contoh harga berdasarkan sampel yang diserap.

Anda biasanya dapat menetapkan interval scraping per tugas atau per target.

Untuk koleksi terkelola, tetapkan interval scrape di resource PodMonitoring menggunakan kolom interval. Untuk koleksi yang di-deploy sendiri, Anda menetapkan interval pengambilan sampel dalam konfigurasi salinan, biasanya dengan menetapkan kolom interval atau scrape_interval.

Mengonfigurasi agregasi lokal (khusus koleksi yang di-deploy sendiri)

Jika Anda mengonfigurasi layanan menggunakan koleksi yang di-deploy sendiri, misalnya dengan kube-prometheus, prometheus-operator, atau dengan men-deploy image secara manual, Anda dapat mengurangi sampel yang dikirim ke Google Cloud Managed Service for Prometheus dengan menggabungkan metrik berkardinalitas tinggi secara lokal. Anda dapat menggunakan aturan perekaman untuk menggabungkan label pergi seperti instance dan menggunakan tanda --export.match atau variabel lingkungan EXTRA_ARGS untuk hanya mengirim data gabungan ke Monarch.

Misalnya, Anda memiliki tiga metrik, high_cardinality_metric_1, high_cardinality_metric_2, dan low_cardinality_metric. Anda ingin mengurangi sampel yang dikirim untuk high_cardinality_metric_1 dan menghilangkan semua sampel yang dikirim untuk high_cardinality_metric_2, sekaligus mempertahankan semua data mentah yang disimpan secara lokal (mungkin untuk tujuan pemberitahuan). Penyiapan Anda mungkin terlihat seperti ini:

Men-deploy image Google Cloud Managed Service for Prometheus.
Konfigurasikan konfigurasi scrape Anda untuk menyalin semua data mentah ke server lokal (menggunakan sesedikit mungkin filter sesuai keinginan).
Konfigurasi aturan perekaman untuk menjalankan agregasi lokal melalui high_cardinality_metric_1 dan high_cardinality_metric_2, mungkin dengan menggabungkan label instance atau sejumlah label metrik, bergantung pada apa yang memberikan pengurangan terbaik dalam jumlah seri waktu yang tidak diperlukan. Anda dapat menjalankan aturan yang terlihat seperti berikut ini, yang menghapus label instance dan menjumlahkan deret waktu yang dihasilkan di label yang tersisa:
```
record: job:high_cardinality_metric_1:sum
expr: sum without (instance) (high_cardinality_metric_1)
```
Lihat operator agregasi dalam dokumentasi Prometheus untuk mengetahui opsi agregasi lainnya.
Deploy image Managed Service for Prometheus dengan flag filter berikut, yang mencegah data mentah dari metrik yang tercantum dikirim ke Monarch:
```
--export.match='{__name__!="high_cardinality_metric_1",__name__!="high_cardinality_metric_2"}'
```
Contoh flag export.match ini menggunakan pemilih yang dipisahkan koma dengan operator != untuk memfilter data mentah yang tidak diinginkan. Jika Anda menambahkan aturan perekaman tambahan untuk menggabungkan metrik berkardinalitas tinggi lainnya, Anda juga harus menambahkan pemilih __name__ baru ke filter agar data mentah dihapus. Dengan menggunakan satu flag yang berisi beberapa pemilih dengan operator != untuk memfilter data yang tidak diinginkan, Anda hanya perlu mengubah filter saat membuat agregasi baru, bukan setiap kali mengubah atau menambahkan konfigurasi scrape.

Metode deployment tertentu, seperti prometheus-operator, mungkin mengharuskan Anda untuk menghapus tanda kutip tunggal yang mengapit tanda kurung.

Alur kerja ini mungkin menimbulkan beberapa overhead operasional dalam membuat dan mengelola aturan perekaman dan flag export.match, tetapi kemungkinan Anda dapat memangkas banyak volume dengan hanya berfokus pada metrik dengan kardinalitas sangat tinggi. Untuk mengetahui informasi tentang cara mengidentifikasi metrik yang paling diuntungkan dari pra-agregasi lokal, lihat Mengidentifikasi metrik volume tinggi.

Jangan terapkan penggabungan saat menggunakan Managed Service for Prometheus. Alur kerja ini tidak lagi digunakan karena satu server Prometheus yang di-deploy sendiri dapat melakukan agregasi tingkat cluster apa pun yang mungkin Anda perlukan. Federasi dapat menyebabkan efek yang tidak terduga seperti metrik berjenis "tidak diketahui" dan volume penyerapan yang meningkat dua kali lipat.

Batasi sampel dari metrik berkardinalitas tinggi (khusus koleksi yang di-deploy sendiri)

Anda dapat membuat metrik berkardinalitas sangat tinggi dengan menambahkan label yang memiliki banyak nilai potensial, seperti ID pengguna atau alamat IP. Metrik tersebut dapat menghasilkan sampel dalam jumlah yang sangat besar. Menggunakan label dengan jumlah nilai yang besar biasanya merupakan kesalahan konfigurasi. Anda dapat melindungi dari metrik berkardinalitas tinggi pada kolektor yang di-deploy sendiri dengan menetapkan nilai sample_limit dalam konfigurasi salinan.

Jika Anda menggunakan batas ini, sebaiknya tetapkan ke nilai yang sangat tinggi, sehingga batas ini hanya akan menangkap metrik yang jelas-jelas salah dikonfigurasi. Setiap sampel yang melebihi batas akan dihapus, dan sangat sulit untuk mendiagnosis masalah yang disebabkan karena melebihi batas.

Menggunakan batas sampel bukanlah cara yang tepat untuk mengelola penyerapan sampel, tetapi batas tersebut dapat melindungi Anda dari kesalahan konfigurasi yang tidak disengaja. Untuk mengetahui informasi selengkapnya, lihat Menggunakan sample_limit untuk menghindari kelebihan beban.

Mengidentifikasi dan mengatribusikan biaya

Anda dapat menggunakan Cloud Monitoring untuk mengidentifikasi metrik Prometheus yang menulis sampel dalam jumlah terbesar. Metrik ini yang paling berkontribusi terhadap biaya Anda. Setelah mengidentifikasi metrik yang paling mahal, Anda dapat mengubah konfigurasi scrape untuk memfilter metrik ini dengan tepat.

Halaman Metrics Management Cloud Monitoring menyediakan informasi yang dapat membantu Anda mengontrol jumlah biaya yang dikeluarkan untuk metrik yang dapat dikenakan biaya tanpa memengaruhi kemampuan observasi. Halaman Pengelolaan Metrik melaporkan informasi berikut:

Volume penyerapan untuk penagihan berbasis byte dan sampel, di seluruh domain metrik dan untuk masing-masing metrik.
Data tentang label dan kardinalitas metrik.
Penggunaan metrik dalam kebijakan pemberitahuan dan dasbor kustom.
Rasio error penulisan metrik.

Untuk menampilkan halaman Metrics Management, lakukan hal berikut:

Di panel navigasi konsol Google Cloud, pilih Monitoring, lalu pilih Metrics management:
Buka Pengelolaan metrik
Di toolbar, pilih periode waktu. Secara default, halaman Metrics Management menampilkan informasi tentang metrik yang dikumpulkan dalam satu hari sebelumnya.

Untuk informasi selengkapnya tentang halaman Metrics Management, baca artikel Melihat dan mengelola penggunaan metrik.

Bagian berikut menjelaskan cara menganalisis jumlah sampel yang Anda kirim ke Google Cloud Managed Service for Prometheus dan mengatribusikan volume tinggi ke metrik, namespace Kubernetes, dan region Google Cloud tertentu.

Mengidentifikasi metrik bervolume tinggi

Untuk mengidentifikasi metrik Prometheus dengan volume penyerapan terbesar, lakukan hal berikut:

Di panel navigasi konsol Google Cloud, pilih Monitoring, lalu pilih Metrics management:
Buka Pengelolaan metrik
Pada kartu skor Sampel yang dapat ditagih, klik Lihat diagram.
Temukan diagram Proses Transfer Volume Namespace, lalu klik Opsi diagram lainnya.
Pilih opsi diagram Lihat di Metrics Explorer.
Di panel Builder Metrics Explorer, ubah kolom sebagai berikut:
1. Di kolom Metrik, pastikan resource dan metrik berikut dipilih:
  Metric Ingestion Attribution dan Samples written by attribution id.
2. Untuk kolom Aggregation, pilih sum.
3. Untuk kolom by, pilih label berikut:
  - attribution_dimension
  - metric_type
4. Untuk kolom Filter, gunakan attribution_dimension = namespace. Anda harus melakukannya setelah menggabungkan dengan label attribution_dimension.
Diagram yang dihasilkan menunjukkan volume penyerapan untuk setiap jenis metrik.
Untuk melihat volume penyerapan setiap metrik, pada tombol berlabel Chart Table Both, pilih Both. Tabel menunjukkan volume yang diserap untuk setiap metrik di kolom Nilai.
Klik header kolom Value dua kali untuk mengurutkan metrik berdasarkan volume penyerapan yang menurun.

Diagram yang dihasilkan, yang menunjukkan metrik teratas Anda berdasarkan volume yang diurutkan berdasarkan rata-rata, akan terlihat seperti screenshot berikut: Diagram yang dikonfigurasi menunjukkan volume penyerapan metrik untuk setiap metrik.

Mengidentifikasi namespace bervolume tinggi

Untuk mengatribusikan volume penyerapan ke namespace Kubernetes tertentu, lakukan hal berikut:

Di panel navigasi konsol Google Cloud, pilih Monitoring, lalu pilih Metrics management:
Buka Pengelolaan metrik
Pada kartu skor Sampel yang dapat ditagih, klik Lihat diagram.
Temukan diagram Proses Transfer Volume Namespace, lalu klik Opsi diagram lainnya.
Pilih opsi diagram Lihat di Metrics Explorer.
Di panel Builder di Metrics Explorer, ubah kolom sebagai berikut:
1. Di kolom Metrik, pastikan resource dan metrik berikut dipilih:
  Metric Ingestion Attribution dan Samples written by attribution id.
2. Konfigurasikan parameter kueri lainnya yang sesuai:
  - Untuk menghubungkan keseluruhan volume penyerapan dengan namespace:
    - Untuk kolom Aggregation, pilih sum.
    - Untuk kolom by, pilih label berikut:
      - attribution_dimension
      - attribution_id
    - Untuk kolom Filter, gunakan attribution_dimension = namespace.
  - Untuk menghubungkan volume penyerapan metrik individual dengan namespace:
    - Untuk kolom Aggregation, pilih sum.
    - Untuk kolom by, pilih label berikut:
      - attribution_dimension
      - attribution_id
      - metric_type
    - Untuk kolom Filter, gunakan attribution_dimension = namespace.
  - Untuk mengidentifikasi namespace yang bertanggung jawab atas metrik bervolume tinggi tertentu:
    1. Identifikasi jenis metrik untuk metrik bervolume tinggi dengan menggunakan salah satu contoh lain untuk mengidentifikasi jenis metrik bervolume tinggi. Jenis metrik adalah string dalam tampilan tabel yang diawali dengan prometheus.googleapis.com/. Untuk informasi selengkapnya, lihat Mengidentifikasi metrik bervolume tinggi.
    2. Batasi data diagram ke jenis metrik yang diidentifikasi dengan menambahkan filter untuk jenis metrik di kolom Filter. Contoh:
      metric_type= prometheus.googleapis.com/container_tasks_state/gauge.
    3. Untuk kolom Aggregation, pilih sum.
    4. Untuk kolom by, pilih label berikut:
      - attribution_dimension
      - attribution_id
    5. Untuk kolom Filter, gunakan attribution_dimension = namespace.
  - Untuk melihat penyerapan berdasarkan region Google Cloud, tambahkan label location ke kolom by.
  - Untuk melihat penyerapan oleh project Google Cloud, tambahkan label resource_container ke kolom by.