Pengoptimalan biaya untuk Kemampuan Observasi Google Cloud

Kemampuan observasi Google Cloud terdiri dari sekumpulan layanan terkelola berbasis cloud yang dirancang untuk memberikan kemampuan observasi mendalam ke layanan aplikasi dan infrastruktur. Salah satu manfaat layanan terkelola di Google Cloud adalah layanan berbasis penggunaan, yang berarti Anda hanya membayar sesuai penggunaan. Meskipun model penetapan harga ini mungkin memberikan manfaat dari segi biaya jika dibandingkan dengan pemberian lisensi software standar, model ini mungkin menyulitkan untuk memperkirakan biaya. Solusi ini menjelaskan cara memahami penggunaan layanan ini dan mengoptimalkan biaya Anda.

Harga

Karena layanan Kemampuan observasi Google Cloud merupakan layanan terkelola, layanan tersebut memungkinkan Anda berfokus pada insight yang diberikan, bukan infrastruktur yang diperlukan untuk menggunakan layanan ini. Saat menggunakan layanan ini, Anda tidak perlu membayar satu per satu untuk mesin virtual, lisensi software, pemindaian keamanan, pemeliharaan hardware, atau ruang di pusat data. Layanan ini memberikan biaya per penggunaan yang sederhana.

Biaya mencakup tagihan untuk Cloud Logging, Cloud Monitoring, dan Cloud Trace. Produk logging Error Reporting tidak memiliki biaya terpisah saat masih dalam versi beta, dan Anda dapat menggunakan Cloud Profiler tanpa biaya. Untuk Error Reporting, Anda mungkin akan dikenai sedikit biaya jika error Anda diserap oleh Logging.

Anda juga dapat membaca ringkasan semua informasi harga

Biaya logging dan pelaporan error

Harga logging didasarkan pada volume log yang dapat dikenakan biaya yang diserap. Harga produk ini memberikan biaya per GiB yang sederhana. Ini adalah alokasi gratis per bulan, dan log tertentu, seperti Cloud Audit Logs, tidak dikenai biaya.

Contoh penggunaan produk yang menghasilkan biaya melalui volume log tambahan mencakup penggunaan:

  • Cloud Load Balancing
  • Agen Logging di Compute Engine
  • Agen Logging di Amazon Web Services (AWS)
  • Operasi tulis di Cloud Logging API

Memantau biaya

Pemantauan harga didasarkan pada volume metrik yang dapat dikenakan biaya yang diserap dan jumlah panggilan API yang dapat dikenai biaya. Misalnya, metrik non-Google Cloud seperti metrik agen, kustom, eksternal, dan AWS dapat dikenai biaya. Metode projects.timeSeries.list dalam Cloud Monitoring API dikenai biaya berdasarkan panggilan API, sedangkan penggunaan API lainnya gratis. Ini adalah alokasi volume metrik gratis per bulan, dan banyak metrik, termasuk semua metrik Google Cloud, tidak dikenai biaya. Lihat Memantau harga untuk mengetahui informasi selengkapnya tentang metrik yang dapat dikenakan biaya.

Contoh penggunaan produk yang menimbulkan biaya melalui volume metrik dan panggilan API mencakup penggunaan:

  • Memantau metrik kustom
  • Agen Pemantauan di Compute Engine
  • Agen Pemantauan di AWS
  • Operasi baca di Monitoring API

Catat biaya

Harga trace didasarkan pada jumlah span yang diserap dan pada akhirnya dipindai. Beberapa layanan Google Cloud, seperti lingkungan standar App Engine, otomatis menghasilkan span yang tidak dikenai biaya. Ada alokasi gratis per bulan untuk Trace.

Contoh penggunaan produk yang menghasilkan biaya melalui span yang diserap mencakup penambahan instrumentasi untuk:

  • Span untuk aplikasi App Engine di luar span default
  • Cloud Load Balancing
  • Aplikasi kustom

Penggunaan

Memahami penggunaan dapat memberikan insight tentang komponen mana yang menghasilkan biaya. Tindakan ini membantu Anda mengidentifikasi area yang mungkin sesuai untuk pengoptimalan.

Analisis tagihan Google Cloud

Langkah pertama untuk memahami penggunaan Anda adalah meninjau tagihan Google Cloud dan memahami biaya Anda. Salah satu cara untuk mendapatkan insight adalah menggunakan Billing Reports di Google Cloud Console.

Halaman Reports menawarkan berbagai filter yang berguna untuk mempersempit hasil menurut waktu, project, produk, SKU, dan label. Anda dapat menggunakan filter Products untuk mempersempit data penagihan ke pemantauan dan pencatatan biaya.

Logging

Logging menyediakan daftar log, volume log saat ini, dan volume bulanan yang diproyeksikan untuk setiap project. Anda dapat meninjau detail ini untuk setiap project sambil meninjau biaya Logging pada tagihan Google Cloud Anda. Hal ini memudahkan untuk melihat log mana yang memiliki volume tertinggi dan, oleh karena itu, yang paling berkontribusi pada biaya.

Anda dapat menemukan volume log yang diserap dalam project Anda di halaman Logs Storage. Halaman Logs Storage menyediakan daftar log dan volumenya untuk bulan sebelumnya dan bulan berjalan, serta proyeksi volume untuk akhir bulan.

Analisis ini memungkinkan Anda mengembangkan insight tentang penggunaan log dalam project tertentu, serta perubahan volumenya dari waktu ke waktu. Anda dapat menggunakan analisis ini untuk mengidentifikasi log mana yang harus dipertimbangkan untuk dioptimalkan.

Pemantauan

Monitoring, yang disusun menjadi cakupan metrik, memberikan daftar mendetail project serta volume metrik sebelumnya, saat ini, dan yang diproyeksikan. Karena cakupan metrik dapat mencakup lebih dari satu project, volume untuk setiap project dicantumkan secara terpisah, seperti yang diilustrasikan dalam gambar berikut.

Workspace dengan beberapa project

Pelajari cara menemukan detail penggunaan Monitoring.

Anda dapat melihat grafik mendetail dari metrik volume metrik untuk setiap project di Metrics Explorer dalam Monitoring, yang memberikan insight terkait volume metrik yang diserap dari waktu ke waktu.

Analisis ini menyediakan volume metrik Monitoring untuk setiap project yang Anda identifikasi saat meninjau biaya Monitoring pada tagihan Google Cloud Anda. Anda kemudian dapat meninjau volume metrik tertentu dan memahami komponen mana yang berkontribusi pada volume dan biaya paling banyak.

Trace

Trace memberikan tampilan mendetail dari span yang diserap untuk bulan saat ini dan sebelumnya. Anda dapat meninjau detail ini di konsol Google Cloud untuk setiap project yang Anda identifikasi saat meninjau tagihan Trace pada tagihan Google Cloud.

Analisis ini memberitahukan jumlah span yang diserap untuk setiap project di Workspace yang Anda identifikasi saat meninjau biaya Trace pada tagihan Google Cloud. Kemudian, Anda dapat meninjau jumlah span tertentu yang diserap serta memahami project dan layanan mana yang berkontribusi pada jumlah span dan biaya tertinggi.

Ekspor logging

Logging menyediakan sink logging untuk mengekspor log ke Cloud Storage, BigQuery, dan Pub/Sub ini.

Misalnya, jika Anda mengekspor semua log dari Logging ke BigQuery untuk penyimpanan dan analisis jangka panjang, Anda akan dikenai biaya BigQuery, termasuk penyimpanan per GiB, streaming insert, dan biaya kueri singkat ini.

Untuk mengetahui biaya yang dihasilkan ekspor Anda, pertimbangkan langkah-langkah berikut:

  1. Temukan sink logging Anda. Cari tahu jika ada, sink logging apa yang telah Anda aktifkan. Misalnya, project Anda mungkin sudah memiliki beberapa sink logging yang dibuat untuk berbagai tujuan, seperti operasi keamanan atau untuk memenuhi persyaratan peraturan.
  2. Tinjau detail penggunaan Anda. Tinjau penggunaan untuk tujuan ekspor. Misalnya, ukuran tabel BigQuery untuk BigQuery Export atau ukuran bucket untuk ekspor Cloud Storage.

Menemukan sink logging Anda

Sink logging Anda mungkin berada di level project (satu atau beberapa sink per project) atau mungkin berada di level organisasi Google Cloud, yang disebut ekspor gabungan. Sink ini mungkin menyertakan banyak log project dalam organisasi Google Cloud yang sama.

Anda dapat melihat sink logging dengan melihat project tertentu. Konsol Google Cloud menyediakan daftar sink dan tujuannya. Guna melihat ekspor gabungan untuk organisasi Anda, Anda dapat menggunakan command line gcloud daftar sink logging --organization ORGANIZATION_ID.

Tinjau detail penggunaan Anda

Monitoring menyediakan beragam metrik tidak hanya untuk aplikasi Anda, tetapi juga untuk penggunaan produk Google Cloud. Anda bisa mendapatkan metrik penggunaan yang mendetail untuk Cloud Storage, BigQuery, dan Pub/Sub dengan melihat metrik penggunaan di Metrics Explorer.

Cloud Storage

Dengan menggunakan Metrics Explorer di Monitoring, Anda dapat melihat ukuran penyimpanan bucket Cloud Storage. Gunakan nilai berikut dalam Metrics Explorer untuk melihat ukuran penyimpanan bucket Cloud Storage yang digunakan untuk sink logging.

Agar dapat menampilkan metrik untuk resource yang dipantau dengan menggunakan Metrics Explorer, lakukan hal berikut:

  1. Di panel navigasi Konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics Explorer:

    Buka Metrics Explorer

  2. Pada elemen Metrik, luaskan menu Pilih metrik, masukkan Total bytes di panel filter, lalu gunakan submenu untuk memilih jenis dan metrik resource tertentu:
    1. Di menu Active resources, pilih GCS Bucket.
    2. Di menu Active metric category, pilih Storage.
    3. Di menu Active metrics, pilih Total bytes.
    4. Klik Apply.
    Nama yang sepenuhnya memenuhi syarat untuk metrik ini adalah storage.googleapis.com/storage/total_bytes.
  3. Konfigurasi cara data dilihat.
    • Di elemen Filter, klik Add filter, lalu pilih project_id. Untuk nilai, pilih project ID Google Cloud Anda.
    • Di elemen Filter, klik Add filter, lalu pilih bucket_name. Untuk nilai, pilih nama bucket ekspor Cloud Storage Anda.
    • Di entri Agregasi, tetapkan menu pertama ke Unaggregated.

    Untuk informasi selengkapnya tentang cara mengonfigurasi diagram, lihat Memilih metrik saat menggunakan Metrics Explorer.

Ukuran penyimpanan bucket Cloud Storage

Grafik sebelumnya menunjukkan ukuran data dalam TB yang diekspor dari waktu ke waktu, yang memberikan insight tentang penggunaan ekspor Logging ke Cloud Storage.

BigQuery

Dengan Metrics Explorer di Monitoring, Anda dapat melihat ukuran penyimpanan untuk set data BigQuery. Gunakan nilai berikut di Metrics Explorer untuk melihat ukuran penyimpanan set data BigQuery yang digunakan untuk sink logging.

Agar dapat menampilkan metrik untuk resource yang dipantau dengan menggunakan Metrics Explorer, lakukan hal berikut:

  1. Di panel navigasi Konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics Explorer:

    Buka Metrics Explorer

  2. Pada elemen Metrik, luaskan menu Pilih metrik, masukkan Stored bytes di panel filter, lalu gunakan submenu untuk memilih jenis dan metrik resource tertentu:
    1. Di menu Active resources, pilih BigQuery set data.
    2. Di menu Active metric category, pilih Storage.
    3. Di menu Metrik aktif, pilih Byte tersimpan.
    4. Klik Apply.
    Nama yang sepenuhnya memenuhi syarat untuk metrik ini adalah bigquery.googleapis.com/storage/stored_bytes.
  3. Konfigurasi cara data dilihat.
    • Di elemen Filter, klik Add filter, lalu pilih project_id. Untuk nilai, pilih project ID Google Cloud Anda.
    • Di elemen Filter, klik Add filter, lalu pilih dataset_id. Untuk nilai, pilih nama set data BigQuery Export.
    • Di entri Aggregation, tetapkan menu pertama ke Mean dan menu kedua ke dataset_id.
    • Di panel Display, tetapkan Widget type ke Stacked bar chart.
    • Tetapkan periode waktu minimal satu hari.

    Untuk informasi selengkapnya tentang cara mengonfigurasi diagram, lihat Memilih metrik saat menggunakan Metrics Explorer.

Ukuran penyimpanan set data BigQuery.

Grafik sebelumnya menunjukkan ukuran set data ekspor dalam TB dari waktu ke waktu, yang memberikan insight tentang penggunaan ekspor Logging ke BigQuery.

Pub/Sub

Dengan menggunakan Metrics Explorer di Monitoring, Anda dapat melihat jumlah pesan dan ukuran pesan yang diekspor ke Pub/Sub. Gunakan nilai berikut di Metrics Explorer untuk melihat ukuran penyimpanan topik Pub/Sub yang digunakan untuk sink logging.

Agar dapat menampilkan metrik untuk resource yang dipantau dengan menggunakan Metrics Explorer, lakukan hal berikut:

  1. Di panel navigasi Konsol Google Cloud, pilih Monitoring, lalu pilih  Metrics Explorer:

    Buka Metrics Explorer

  2. Pada elemen Metrik, luaskan menu Pilih metrik, masukkan Byte cost di panel filter, lalu gunakan submenu untuk memilih jenis dan metrik resource tertentu:
    1. Di menu Active resources, pilih Cloud Pub/Sub topic.
    2. Di menu Kategori metrik aktif, pilih Topik.
    3. Di menu Active metrics, pilih Topic byte cost.
    4. Klik Apply.
    Nama yang sepenuhnya memenuhi syarat untuk metrik ini adalah pubsub.googleapis.com/topic/byte_cost.
  3. Konfigurasi cara data dilihat.
    • Di elemen Filter, klik Add filter, lalu pilih project_id. Untuk nilai, pilih project ID Google Cloud Anda.
    • Di elemen Filter, klik Add filter, lalu pilih topic_id. Untuk nilai, pilih nama topik Pub/Sub Export.
    • Di entri Agregasi, tetapkan menu pertama ke Unaggregated.

    Untuk informasi selengkapnya tentang cara mengonfigurasi diagram, lihat Memilih metrik saat menggunakan Metrics Explorer.

Ukuran penyimpanan topik Pub/Sub Grafik sebelumnya menunjukkan ukuran data dalam KB yang diekspor dari waktu ke waktu, yang memberikan insight tentang penggunaan untuk Logging mengekspor ke Pub/Sub.

Menerapkan kontrol biaya

Opsi berikut menjelaskan cara yang mungkin dilakukan untuk mengurangi biaya Anda. Setiap opsi akan mengorbankan insight tentang aplikasi dan infrastruktur Anda. Pilih opsi yang memberi Anda kompromi terbaik antara kemampuan observasi dan biaya.

Mencatat kontrol biaya

Untuk mengoptimalkan penggunaan Logging, Anda dapat mengurangi jumlah log yang diserap ke dalam Logging. Ada beberapa strategi yang dapat Anda gunakan untuk membantu mengurangi volume log sambil terus mempertahankan log yang diperlukan developer dan operator Anda.

Kecualikan log

Anda dapat mengecualikan sebagian besar log yang tidak diperlukan oleh tim developer dan operasi dari Logging atau Error Reporting.

Mengecualikan log berarti log tersebut tidak muncul di UI Logging atau Error Reporting. Anda dapat menggunakan filter logging untuk memilih entri log tertentu atau seluruh log yang akan dikecualikan. Anda juga dapat menggunakan aturan pengecualian pengambilan sampel untuk mengecualikan persentase entri logging. Misalnya, Anda dapat memilih untuk mengecualikan log tertentu berdasarkan volume yang tinggi atau kurangnya nilai praktis.

Berikut ini beberapa contoh pengecualian umum:

  • Kecualikan log dari Cloud Load Balancing. Load balancer dapat menghasilkan log dengan volume yang tinggi untuk aplikasi dengan traffic yang tinggi. Misalnya, Anda dapat menggunakan filter logging untuk menyiapkan pengecualian bagi 90% pesan dari Cloud Load Balancing.

  • Kecualikan Log Alur Virtual Private Cloud (Kontrol Layanan VPC). Log aliran mencakup log untuk setiap komunikasi antara mesin virtual dalam jaringan Kontrol Layanan VPC, yang dapat menghasilkan log dalam jumlah besar. Ada dua pendekatan untuk mengurangi volume log, yang dapat Anda gunakan secara bersamaan atau terpisah.

    • Kecualikan menurut konten entri log. Kecualikan sebagian besar Log Aliran VPC, dengan hanya mempertahankan pesan log tertentu yang mungkin berguna. Misalnya, jika Anda memiliki VPC pribadi yang seharusnya tidak menerima traffic masuk dari sumber eksternal, Anda mungkin hanya ingin mempertahankan log aliran dengan kolom sumber dari alamat IP eksternal.
    • Kecualikan berdasarkan persentase. Pendekatan lainnya adalah mengambil sampel hanya mengambil sampel log yang diidentifikasi oleh filter. Misalnya, Anda dapat mengecualikan 95% dan hanya mempertahankan 5% dari log alur.

  • Kecualikan respons 200 OK HTTP dari log permintaan. Untuk aplikasi, pesan 200 OK HTTP mungkin tidak memberikan banyak insight dan dapat menghasilkan volume log yang tinggi untuk aplikasi dengan traffic tinggi.

Baca Pengecualian log untuk menerapkan pengecualian logging.

Ekspor log

Anda dapat mengekspor log, tetapi mengecualikannya agar tidak diserap ke dalam Logging. Dengan begitu, Anda dapat menyimpan log di Cloud Storage dan BigQuery atau menggunakan Pub/Sub untuk memproses log, sekaligus mengecualikan log dari Logging, yang dapat membantu mengurangi biaya. Artinya, log Anda tidak muncul di Logging, tetapi telah diekspor.

Gunakan metode ini untuk menyimpan log untuk analisis jangka panjang tanpa menimbulkan biaya penyerapan ke Logging. Untuk mendapatkan pemahaman mendetail tentang cara pengecualian dan ekspor berinteraksi, lihat masa aktif diagram log, yang menggambarkan cara entri log yang diekspor diperlakukan dalam Logging.

Mengurangi penggunaan agen Logging

Anda dapat mengurangi volume log dengan tidak mengirimkan log tambahan yang dibuat oleh agen Logging ke Logging. Agen logging mengalirkan log dari aplikasi pihak ketiga umum, seperti Apache, Mongodb, dan MySQL.

Misalnya, Anda dapat mengurangi volume log dengan memilih untuk tidak menambahkan agen Logging ke mesin virtual dalam lingkungan pengembangan Anda atau lingkungan tidak penting lainnya ke Logging. Virtual machine Anda terus melaporkan log standar ke Logging, tetapi tidak melaporkan log dari aplikasi pihak ketiga atau syslog.

Memantau kontrol biaya

Untuk mengoptimalkan penggunaan Monitoring, Anda dapat mengurangi volume metrik yang dapat dikenakan biaya yang diserap ke Monitoring dan jumlah panggilan baca ke Monitoring API. Ada beberapa strategi yang dapat Anda gunakan untuk mengurangi volume metrik sambil terus mempertahankan metrik yang diperlukan developer dan operator Anda.

Mengoptimalkan metrik dan penggunaan label

Cara Anda menggunakan label pada metrik kustom Monitoring dapat memengaruhi volume deret waktu yang dihasilkan.

Jika memiliki metrik kustom dengan dua label, misalnya nilai cost_center dan env, Anda dapat menghitung jumlah deret waktu maksimum dengan mengalikan kardinalitas kedua label.

total_num_time_series = cost_center_cardinality * env_cardinality

Jika ada 11 nilai cost_center dan 5 nilai env, berarti Anda dapat membuat hingga 55 deret waktu. Inilah sebabnya mengapa label metrik tambahan dapat menambah volume metrik yang signifikan dan, oleh karena itu, meningkatkan biaya. Lihat postingan blog Tips dan trik Cloud Monitoring: Memahami metrik dan membuat diagram untuk mengetahui deskripsi mendetail tentang kardinalitas metrik.

Sebaiknya lakukan tindakan berikut untuk meminimalkan jumlah deret waktu:

  • Jika memungkinkan, batasi jumlah label metrik kustom.
  • Pilih label dengan cermat untuk menghindari nilai label dengan kardinalitas tinggi. Misalnya, menggunakan user_id sebagai label akan menghasilkan setidaknya satu deret waktu untuk setiap pengguna, yang dapat menjadi jumlah yang sangat besar jika Anda memiliki banyak traffic.

Mengurangi penggunaan agen Monitoring

Metrik yang dikirim dari agen Monitoring adalah metrik yang dapat dikenakan biaya. Agen pemantauan mengalirkan metrik aplikasi dan sistem dari aplikasi pihak ketiga umum, seperti Apache, MySQL, dan Nginx, serta metrik tambahan tingkat VM Google Cloud. Jika Anda tidak memerlukan metrik sistem atau metrik yang mendetail dari aplikasi pihak ketiga untuk VM tertentu, Anda dapat mengurangi volumenya dengan tidak mengirimkan metrik ini. Anda juga dapat mengurangi volume metrik dengan mengurangi jumlah VM menggunakan agen Monitoring.

Misalnya, Anda dapat mengurangi volume metrik dengan memilih untuk tidak menambahkan project Google Cloud dalam lingkungan pengembangan Anda atau lingkungan tidak penting lainnya ke Monitoring. Selain itu, Anda dapat memilih untuk tidak menyertakan agen Monitoring di VM dalam lingkungan pengembangan atau lingkungan tidak penting lainnya.

Mengurangi penggunaan metrik kustom

Metrik kustom adalah metrik yang dapat dikenakan biaya yang dibuat menggunakan Monitoring API untuk memantau metrik apa pun yang disediakan oleh pengguna. Anda dapat membuat metrik ini menggunakan Monitoring API atau menggunakan integrasi.

Salah satu integrasi tersebut adalah OpenCensus. OpenCensus adalah distribusi library yang mengumpulkan metrik dan trace terdistribusi dari aplikasi Anda. Aplikasi yang dilengkapi dengan OpenCensus dapat melaporkan metrik ke beberapa backend, termasuk Monitoring menggunakan metrik kustom. Metrik ini muncul di Monitoring pada jenis resource awalan custom.googleapis.com/opencensus. Misalnya, latensi dua arah klien yang dilaporkan oleh OpenCensus muncul di Monitoring pada jenis resource custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency.

Makin banyak aplikasi yang Anda instrumentasi untuk mengirim metrik, makin banyak metrik pemantauan kustom yang dihasilkan. Jika ingin mengurangi volume metrik, Anda dapat mengurangi jumlah metrik pemantauan kustom yang dikirim aplikasi Anda.

Lacak kontrol biaya

Untuk mengoptimalkan penggunaan Trace, Anda dapat mengurangi jumlah span yang diserap dan dipindai. Saat melengkapi aplikasi untuk melaporkan span ke Trace, Anda menggunakan sampling untuk menyerap sebagian traffic. Pengambilan sampel adalah bagian penting dari sistem pelacakan karena memberikan insight tentang penguraian latensi yang disebabkan oleh komponen aplikasi, seperti panggilan RPC. Ini bukan hanya praktik terbaik untuk menggunakan Trace, tetapi Anda juga dapat mengurangi volume span karena alasan pengurangan biaya.

Gunakan pengambilan sampel OpenCensus

Jika menggunakan Trace sebagai tujuan ekspor untuk trace OpenCensus, Anda dapat menggunakan fitur pengambilan sampel di OpenCensus untuk mengurangi volume trace yang diserap.

Misalnya, jika Anda memiliki aplikasi web populer dengan 5000 kueri/detik, Anda mungkin mendapatkan cukup insight dari pengambilan sampel 5% traffic aplikasi, bukan 20%. Tindakan ini akan mengurangi jumlah span yang diserap ke dalam Trace menjadi seperempat.

Anda dapat menentukan sampling dalam konfigurasi instrumentasi menggunakan library OpenCensus Python untuk Trace. Sebagai contoh, pengekspor OpenCensus Python menyediakan ProbabilitySampler yang dapat Anda gunakan untuk menentukan frekuensi sampling.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Menggunakan kuota span Cloud Trace API

Anda dapat menggunakan kuota untuk membatasi penggunaan Trace dan biaya. Anda dapat menerapkan kuota span dengan halaman kuota khusus API di konsol Google Cloud.

Menetapkan kuota tertentu yang lebih rendah dari kuota produk default berarti Anda menjamin bahwa project Anda tidak akan melebihi batas kuota tertentu. Hal ini adalah cara untuk memastikan bahwa biaya Anda sesuai dengan yang diharapkan. Anda dapat memantau kuota ini dari halaman kuota khusus API, seperti yang ditunjukkan dalam gambar berikut.

Memantau halaman kuota khusus API

Jika mengurangi kuota span, Anda juga harus mempertimbangkan untuk memantau metrik kuota span dan menyiapkan kebijakan pemberitahuan di Monitoring untuk mengirim pemberitahuan saat penggunaan mendekati kuota. Pemberitahuan ini akan meminta Anda untuk melihat penggunaan serta mengidentifikasi aplikasi dan developer yang mungkin menghasilkan span bervolume besar. Jika Anda menetapkan kuota span dan kuota tersebut terlampaui, span akan dihapus hingga Anda menyesuaikan kuota.

Misalnya, jika kuota span adalah 50 juta span yang diserap, Anda dapat menyetel pemberitahuan setiap kali menggunakan 80% kuota API, yaitu 40 juta span. Ikuti petunjuk dalam mengelola kebijakan pemberitahuan untuk membuat kebijakan pemberitahuan menggunakan detail berikut.

  1. Di Konsol Google Cloud, buka Monitoring atau gunakan tombol berikut:
    Go to Monitoring
  2. Di panel navigasi Monitoring, pilih Alerting lalu pilih Create Policy.
  3. Masukkan nama untuk kebijakan pemberitahuan.
  4. Klik Tambahkan Ketentuan:
    1. Setelan di panel Target menentukan resource dan metrik yang akan dipantau. Klik kotak teks untuk mengaktifkan menu, lalu pilih resource global.
    2. Klik kotak teks untuk mengaktifkan menu, lalu pilih cloudtrace.googleapis.com/billing/monthly_spans_ingested.
    3. Tambahkan nilai Filter berikut:
      • Klik project_id, lalu pilih project ID Google Cloud Anda.
      • Klik chargeable, lalu pilih true
    4. Setelan di panel Configuration pada kebijakan pemberitahuan menentukan kapan pemberitahuan dipicu. Lengkapi kolom berikut:
      • Untuk Pemicu kondisi jika pilih Deret waktu mana pun melanggar
      • Untuk Nilai Minimum, masukkan 40000000
      • Untuk, pilih nilai terbaru
    5. Klik Save.

  5. Klik Save.

    Pemberitahuan yang dihasilkan dari kebijakan pemberitahuan serupa dengan pemberitahuan berikut. Di pemberitahuan, Anda dapat melihat detail tentang project, kebijakan pemberitahuan yang menghasilkan pemberitahuan, dan nilai metrik saat ini.

Detail notifikasi

Optimalkan pemanggil pihak ketiga

Aplikasi Anda mungkin dipanggil oleh aplikasi lain. Jika aplikasi Anda melaporkan span, jumlah span yang dilaporkan oleh aplikasi Anda mungkin bergantung pada traffic masuk yang Anda terima dari aplikasi pihak ketiga. Misalnya, jika Anda memiliki microservice frontend yang memanggil microservice checkout dan keduanya diinstrumentasikan dengan OpenCensus, frekuensi sampling untuk traffic setidaknya setinggi frekuensi pengambilan sampel frontend. Memahami cara aplikasi berinstrumen berinteraksi memungkinkan Anda menilai dampak jumlah span yang diserap.

Ekspor logging

Jika biaya Anda terkait ekspor Logging menjadi masalah, salah satu solusi adalah memperbarui sink logging agar menggunakan filter logging untuk mengurangi volume log yang diekspor. Anda dapat mengecualikan log dari ekspor yang tidak diperlukan.

Misalnya, jika Anda memiliki lingkungan dengan aplikasi yang berjalan di Compute Engine dan menggunakan Cloud SQL, Cloud Storage, dan BigQuery, Anda dapat membatasi log yang dihasilkan agar hanya menyertakan informasi untuk produk tersebut. Filter berikut membatasi ekspor ke log untuk Cloud Audit Logs, Compute Engine, Cloud Storage, Cloud SQL, dan BigQuery. Anda dapat menggunakan filter ini untuk sink logging dan hanya menyertakan log yang dipilih.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

Kesimpulan

Kemampuan observasi Google Cloud memberikan kemampuan untuk melihat data penggunaan produk agar Anda dapat memahami detail penggunaan produk Anda. Dengan data penggunaan ini, Anda dapat mengonfigurasi produk sehingga dapat mengoptimalkan penggunaan dan biaya dengan tepat.

Langkah selanjutnya