Penyerapan dan pembuatan kueri dengan koleksi yang dikelola dan di-deploy sendiri
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini menjelaskan cara menyiapkan lingkungan yang menggabungkan kolektor yang di-deploy sendiri dengan kolektor terkelola, di berbagai project dan clusterGoogle Cloud .
Sebaiknya gunakan pengumpulan terkelola untuk semua lingkungan Kubernetes. Dengan begitu, overhead untuk menjalankan kolektor Prometheus dalam cluster Anda akan praktis dihilangkan.
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
projectGoogle Cloud , tiga cluster, dan menggabungkan koleksi yang dikelola dan di-deploy sendiri. Jika Anda hanya menggunakan koleksi terkelola atau yang di-deploy sendiri, diagram ini masih berlaku; cukup abaikan gaya koleksi yang tidak Anda gunakan:
Untuk menyiapkan dan menggunakan konfigurasi seperti yang ada dalam diagram, perhatikan
hal berikut:
Anda harus menginstal eksportir yang diperlukan di cluster.
Google Cloud Managed Service for Prometheus tidak menginstal eksportir apa pun atas nama Anda.
Project 1 memiliki cluster yang menjalankan koleksi terkelola, yang berjalan sebagai agen node. Pengumpul dikonfigurasi dengan resource PodMonitoring untuk meng-scrape target dalam namespace dan dengan resource ClusterPodMonitoring untuk meng-scrape target di seluruh cluster. PodMonitorings harus diterapkan di
setiap namespace tempat Anda ingin mengumpulkan metrik.
ClusterPodMonitorings diterapkan satu kali 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 pengumpulan yang di-deploy sendiri menggunakan prometheus-operator dan berjalan sebagai layanan mandiri. Cluster ini
dikonfigurasi untuk menggunakan PodMonitors atau ServiceMonitors prometheus-operator
untuk menyalin eksportir di pod atau VM.
Project 2 juga menghosting sidecar gateway push untuk mengumpulkan metrik dari
workload sementara.
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
penyinkron sumber data. Dalam contoh ini, komponen
ini dihosting di cluster mandiri, tetapi dapat dihosting di
satu cluster.
Pengsinkron sumber data dikonfigurasi untuk menggunakan scoping_project_A, dan akun layanan pokoknya memiliki izin Pelihat Pemantauan untuk scoping_project_A.
Saat pengguna mengeluarkan kueri dari Grafana,
Monarch akan memperluas scoping_project_A ke dalam project
yang dipantau penyusunnya dan menampilkan hasil untuk Project 1 dan Project 2
di semua Google Cloud region. Semua metrik mempertahankan label project_id dan location (regionGoogle Cloud ) aslinya untuk tujuan pengelompokan dan pemfilteran.
Jangan melakukan federasi saat menggunakan 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.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Ingestion and querying with managed and self-deployed collection\n\nThis document describes how you might set up an environment that mixes\nself-deployed collectors with managed collectors, across different\nGoogle Cloud projects and clusters.\n\nWe strongly recommend using managed collection for all Kubernetes\nenvironments; doing so practically eliminates the overhead of running\nPrometheus collectors within your cluster.\nYou can run managed and self-deployed collectors within the same cluster.\nWe recommend using a consistent approach to monitoring, but you might choose\nto mix deployment methods for some specific use cases, such as hosting a\npush gateway, as illustrated in this document.\n\nThe following diagram illustrates a configuration that uses two\nGoogle Cloud projects, three clusters, and mixes managed and self-deployed\ncollection. If you use only managed or self-deployed collection, then the\ndiagram is still applicable; just ignore the collection style you aren't using:\n\nTo set up and use a configuration like the one in the diagram, note the\nfollowing:\n\n- You must install any necessary [exporters](https://prometheus.io/docs/instrumenting/exporters/)\n in your clusters.\n Google Cloud Managed Service for Prometheus does not install any exporters on your behalf.\n\n- Project 1 has a cluster running managed collection, which runs as a node\n agent. Collectors are configured with\n [PodMonitoring](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#podmonitoring) resources to scrape\n targets within a namespace and with\n [ClusterPodMonitoring](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#clusterpodmonitoring) resources\n to scrape targets across a cluster. PodMonitorings must be applied in\n every namespace in which you want to collect metrics.\n ClusterPodMonitorings are applied once per cluster.\n\n All data collected in Project 1 is saved in Monarch under\n Project 1. This data is stored by default in the Google Cloud region\n from which it emitted.\n- Project 2 has a cluster running self-deployed collection using\n prometheus-operator and running as a standalone service. This cluster\n is configured to use prometheus-operator PodMonitors or ServiceMonitors\n to scrape exporters on pods or VMs.\n\n Project 2 also hosts a push gateway sidecar to gather metrics from\n ephemeral workloads.\n\n All data collected in Project 2 is saved in Monarch under\n Project 2. This data is stored by default in the Google Cloud region\n from which it emitted.\n- Project 1 also has a cluster running [Grafana](/stackdriver/docs/managed-prometheus/query#ui-grafana) and the\n [data source syncer](/stackdriver/docs/managed-prometheus/query#grafana-oauth). In this example, these\n components are hosted in a standalone cluster, but they can be hosted in\n any single cluster.\n\n The data source syncer is configured to use scoping_project_A,\n and its underlying service account has [Monitoring Viewer](/monitoring/access-control#mon_roles_desc)\n permissions for scoping_project_A.\n\n When a user issues queries from Grafana,\n Monarch expands scoping_project_A into its constituent\n monitored projects and returns results for both Project 1 and Project 2\n across all Google Cloud regions. All metrics retain their original\n `project_id` and `location` (Google Cloud region) labels for\n grouping and filtering purposes.\n\nIf your cluster is not running inside Google Cloud, you must manually\nconfigure the `project_id` and `location` labels. For information about setting\nthese values, see [Run Managed Service for Prometheus outside of\nGoogle Cloud](/stackdriver/docs/managed-prometheus/setup-unmanaged#gmp-outside-gcp).\n\n**Do not federate when using Managed Service for Prometheus.**\nTo reduce cardinality and cost by \"rolling up\" data before sending it to\nMonarch, use local aggregation instead. For more information,\nsee [Configure local aggregation](/stackdriver/docs/managed-prometheus/cost-controls#local-aggregation)."]]
