Aufnahme und Abfrage mit verwalteter und selbst bereitgestellter Erfassung
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
In diesem Dokument wird beschrieben, wie Sie eine Umgebung einrichten können, die selbst bereitgestellte Collectors mit verwalteten Collectors in verschiedenen Google Cloud-Projekten und Clustern mischt.
Wir empfehlen dringend, für alle Kubernetes-Umgebungen die verwaltete Erfassung zu verwenden. Dadurch entfällt der Aufwand für die Ausführung von Prometheus-Collectors in Ihrem Cluster.
Sie können verwaltete und selbst bereitgestellte Collectors im selben Cluster ausführen.
Wir empfehlen die Verwendung eines konsistenten Monitoring-Ansatzes. Sie können jedoch auch für einige bestimmte Anwendungsfälle, wie das Hosten eines Push-Gateways, Bereitstellungsmethoden mischen, wie in diesem Dokument dargestellt.
Das folgende Diagramm zeigt eine Konfiguration, die zwei Google Cloud-Projekte und drei Cluster verwendet und die verwaltete und die selbst bereitgestellte Erfassung kombiniert. Wenn Sie nur die verwaltete oder die selbst bereitgestellte Erfassung verwenden, ist das Diagramm weiterhin anwendbar. Ignorieren Sie einfach den nicht verwendeten Erfassungsstil:
Beachten Sie Folgendes, um eine Konfiguration wie im Diagramm einzurichten und zu verwenden:
Sie müssen alle erforderlichen Exporter in Ihren Clustern installieren.
Google Cloud Managed Service for Prometheus installiert in Ihrem Namen keine Exporter.
Projekt 1 hat einen Cluster, der die verwaltete Erfassung ausführt und der als Knoten-Agent ausgeführt wird. Collectors werden mit PodMonitoring-Ressourcen konfiguriert, um Ziele innerhalb eines Namespace zu extrahieren, und mit ClusterPodMonitoring-Ressourcen, um Ziele in einem Cluster zu extrahieren. PodMonitorings müssen auf jeden Namespace angewendet werden, in dem Sie Messwerte erfassen möchten.
ClusterPodMonitorings werden pro Cluster einmal angewendet.
Alle in Projekt 1 erfassten Daten werden in Monarch unter Projekt 1 gespeichert. Diese Daten werden standardmäßig in der Google Cloud-Region gespeichert, von der sie ausgegeben wurden.
Projekt 2 hat einen Cluster, der die selbst bereitgestellte Erfassung mit dem Prometheus-Operator ausführt und der als eigenständiger Dienst ausgeführt wird. Dieser Cluster ist so konfiguriert, dass er mit PodMonitors oder ServiceMonitors des Prometheus-Operators Daten aus Pods oder VMs extrahiert.
Projekt 2 hostet auch ein Push-Gateway-Sidecar, um Messwerte aus sitzungsspezifischen Arbeitslasten zu erfassen.
Alle in Projekt 2 erfassten Daten werden in Monarch unter Projekt 2 gespeichert. Diese Daten werden standardmäßig in der Google Cloud-Region gespeichert, von der sie ausgegeben wurden.
Projekt 1 hat auch einen Cluster, in dem Grafana und der Datenquellen-Synchronizer ausgeführt werden. In diesem Beispiel werden diese Komponenten in einem eigenständigen Cluster gehostet, können aber in einem beliebigen einzelnen Cluster gehostet werden.
Der Datenquellen-Synchronizer ist für die Verwendung von Bereichsprojekt_A konfiguriert und das zugrunde liegende Dienstkonto hat Berechtigungen des Typs Monitoring-Betrachter für Bereichsprojekt_A.
Wenn ein Nutzer Abfragen von Grafana sendet, erweitert Monarch Bereichsprojekt_A in die überwachten Projekte, aus denen es besteht, und gibt Ergebnisse für Projekt 1 und Projekt 2 in allen Google Cloud-Regionen zurück. Alle Messwerte behalten ihre ursprünglichen Labels project_id und location (Google Cloud-Region) für Gruppierungs- und Filterzwecke bei.
Führen Sie bei Verwendung von Managed Service for Prometheus keine Föderation durch.
Verwenden Sie stattdessen die lokale Aggregation, um die Kardinalität und Kosten durch das "Sammeln" von Daten vor dem Senden an Monarch zu reduzieren. Weitere Informationen finden Sie unter Lokale Aggregation konfigurieren.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-05 (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)."]]
