Penyerapan dan pembuatan kueri dengan koleksi yang dikelola dan di-deploy sendiri

Dokumen ini menjelaskan cara menyiapkan lingkungan yang menggabungkan kolektor yang di-deploy sendiri dengan kolektor terkelola, di berbagai project dan cluster Google Cloud.

Sebaiknya gunakan koleksi terkelola untuk semua lingkungan Kubernetes. Dengan begitu, Anda dapat secara praktis menghilangkan overhead menjalankan kolektor Prometheus dalam cluster Anda. Anda dapat menjalankan kolektor terkelola dan yang di-deploy sendiri dalam cluster yang sama. Sebaiknya gunakan pendekatan yang konsisten untuk pemantauan, tetapi Anda dapat memilih untuk menggabungkan metode deployment untuk beberapa kasus penggunaan tertentu, seperti menghosting gateway push, seperti yang diilustrasikan dalam dokumen ini.

Diagram berikut mengilustrasikan konfigurasi yang menggunakan dua project Google Cloud, tiga cluster, serta koleksi yang dikelola dan di-deploy sendiri. Jika Anda hanya menggunakan koleksi yang dikelola atau di-deploy sendiri, maka diagram masih berlaku; abaikan gaya koleksi yang tidak Anda gunakan:

Anda dapat menyiapkan Google Cloud Managed Service untuk Prometheus dengan campuran koleksi yang terkelola dan yang di-deploy sendiri.

Untuk menyiapkan dan menggunakan konfigurasi seperti yang ada dalam diagram, perhatikan hal berikut:

  • Anda harus menginstal pengekspor yang diperlukan di cluster Anda. Google Cloud Managed Service for Prometheus tidak menginstal pengekspor apa pun atas nama Anda.

  • Project 1 memiliki cluster yang menjalankan koleksi terkelola, yang berjalan sebagai agen node. Kolektor dikonfigurasi dengan resource PodMonitoring untuk menyalin target dalam namespace dan dengan resource ClusterPodMonitoring untuk menyalin target di seluruh cluster. PodMonitoring harus diterapkan di setiap namespace tempat Anda ingin mengumpulkan metrik. ClusterPodMonitorings diterapkan sekali per cluster.

    Semua data yang dikumpulkan di Project 1 disimpan di Monarch di bagian Project 1. Data ini disimpan secara default di region Google Cloud tempat data tersebut dimunculkan.

  • Project 2 memiliki cluster yang menjalankan koleksi yang di-deploy sendiri menggunakan operator prometheus dan berjalan sebagai layanan mandiri. Cluster ini dikonfigurasi untuk menggunakan PodMonitors atau ServiceMonitors untuk meng-scrap pengekspor pada pod atau VM.

    Project 2 juga menghosting file bantuan push gateway untuk mengumpulkan metrik dari workload efemeral.

    Semua data yang dikumpulkan di Project 2 disimpan di Monarch di bagian Project 2. Data ini disimpan secara default di region Google Cloud tempat data tersebut dimunculkan.

  • Project 1 juga memiliki cluster yang menjalankan Grafana dan sinkronisasi sumber data. Dalam contoh ini, komponen ini dihosting di cluster mandiri, tetapi dapat dihosting di cluster tunggal mana pun.

    Penyinkron sumber data dikonfigurasi untuk menggunakan scoping_project_A, dan akun layanan yang mendasarinya memiliki izin Monitoring Viewer untuk scoping_project_A.

    Saat pengguna mengeluarkan kueri dari Grafana, Monarch memperluas scoping_project_A ke project yang dipantau konstituennya dan menampilkan hasil untuk Project 1 dan Project 2 di semua region Google Cloud. Semua metrik mempertahankan label project_id dan location asli (region Google Cloud) untuk tujuan pengelompokan dan pemfilteran.

Jika cluster tidak berjalan di dalam Google Cloud, Anda harus mengonfigurasi label project_id dan location secara manual. Untuk mengetahui informasi tentang cara menetapkan nilai ini, lihat Menjalankan Google Cloud Managed Service for Prometheus di luar Google Cloud.

Jangan gabungkan saat menggunakan Google Cloud Managed Service for Prometheus. Untuk mengurangi kardinalitas dan biaya dengan "menggabungkan" data sebelum mengirimkannya ke Monarch, gunakan agregasi lokal. Untuk informasi selengkapnya, lihat Mengonfigurasi agregasi lokal.