In diesem Dokument sind die Kontingente und Limits für Cloud Monitoring aufgeführt.
- Kontingente geben an, wie viel einer zählbaren, freigegebenen Ressource Sie verwenden können. Kontingente werden von Google Cloud-Diensten wie Cloud Monitoring definiert.
- Systemlimits sind feste Werte, die nicht geändert werden können.
Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.
Das Cloud-Kontingentsystem ermöglicht Folgendes:
- Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
- Ihren Verbrauch dieser Ressourcen einschränken
- Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.
Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Verwenden Sie die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung beantragen.
Für Monitoring-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.
Benutzerdefinierte Messwerte
Auf der Cloud Monitoring-Seite Messwertverwaltung können Sie den Betrag steuern, den Sie für abrechenbare Messwerte ausgeben, ohne die Beobachtbarkeit zu beeinträchtigen. Die Seite Messwertverwaltung enthält folgende Informationen:
- Aufnahmevolumen für byte- und probenbasierte Abrechnung für Messwertdomains und einzelne Messwerte
- Daten zu Labels und zur Kardinalität von Messwerten
- Anzahl der Lesevorgänge für jeden Messwert.
- Verwenden Messwerten in Benachrichtigungsrichtlinien und benutzerdefinierten Dashboards
- Rate von Messwert-Schreibfehlern
Mit der Messwertverwaltung können Sie auch unnötige Messwerte ausschließen, sodass keine Kosten für die Datenaufnahme anfallen. Weitere Informationen zur Seite Messwertverwaltung finden Sie unter Messwertnutzung ansehen und verwalten.
| Kategorie | Höchstwert |
|---|---|
| Benutzerdefinierte Messwertdeskriptoren pro Projekt1 | 10.000 |
| Labels pro Messwertdeskriptor | 30 |
| Stringlänge für den Labelschlüssel | 100 |
| Stringlänge für den Labelwert | 1.024 |
| Zeitreihen in einer Schreibanfrage2 | 200 |
| Geschwindigkeit, mit der Daten in einer einzelnen Zeitachse geschrieben werden können3 | 1 Datenpunkt pro 5 Sekunden |
| Histogramm-Buckets pro benutzerdefiniertem Verteilungsmesswert | 200 |
| Arbeitslast, Prometheus und externe4 Messwertdeskriptoren pro Projekt | 25.000 |
| Aktive Zeitachsen aus benutzerdefinierten Messwerten pro überwachter Ressource5 | 200.000 |
| Aktive Zeitachsen aus Arbeitslastmesswerten pro überwachter Ressource5 | 200.000 |
| Aktive Zeitreihen aus Prometheus pro überwachter Ressource5 | 1.000.000 |
| Aktive Zeitachsen aus externen Messwerten pro überwachter Ressource5 | 200.000 |
| Häufigkeit, mit der Messwertdeskriptoren erstellt werden können | 6.000 pro Minute und Projekt |
1 Dieses Limit wird durch Cloud Monitoring festgelegt. Andere Dienste können möglicherweise niedrigere Maximalwerte festlegen. Benutzerdefinierte Messwerte werden in custom.googleapis.com geschrieben.
2 Pro Zeitachse in einer Anfrage kann nur ein Datenpunkt geschrieben werden. Der genannte Höchstwert entspricht also zugleich der maximalen Anzahl von Datenpunkten, die pro Anfrage geschrieben werden können.
3
Bei der Cloud Monitoring API müssen zwischen den Endzeiten von Punkten, die in eine Zeitachse geschrieben werden, mindestens fünf Sekunden liegen. Wenn die Datenpunkte in der richtigen Reihenfolge in die Zeitreihe geschrieben werden, können Sie dafür einen Batchvorgang nutzen.
4 Externe Messwerte sind diejenigen, die in external.googleapis.com geschrieben werden.
5
Eine Zeitachse ist aktiv, wenn Sie in den vergangenen 24 Stunden Datenpunkte darauf geschrieben haben.
Das in der Zeile angegebene Limit ist die Gesamtzahl der aktiven Zeitreihen für eine einzelne überwachte Ressource (z. B. eine einzelne gce_instance-VM oder ein einzelner k8s_container-Container) für alle benutzerdefinierten Messwerte in dieser Zeile (benutzerdefiniert, Arbeitslast, Prometheus oder extern). Eine Ausnahme bildet die überwachte Ressource global, bei der das Limit für jeden benutzerdefinierten Messwert einzeln gilt. Dies ist ein systemweites Sicherheitslimit, das nicht angepasst werden kann.
Kontingente und Limits der Monitoring API
| Kategorie | Höchstwert |
|---|---|
| Limits der API-Nutzung |
So rufen Sie die API-Kontingente und -Limits auf:
|
| Lebensdauer der API-Seitentoken | 24 Stunden |
Kontingente der Monitoring API
Für die Monitoring API gelten Kontingentlimits für die Anzahl der Zeitreihenanforderungen zur Aufnahme von Daten und für Zeitreihenabfragen. Anforderungen zur Aufnahme von Daten sind Aufrufe, die Zeitreihendaten schreiben, und Abfragen sind Aufrufe, die Zeitreihendaten abrufen. Auch für andere Monitoring API-Endpunkte gelten interne Limits. Solche Endpunkte sind nicht darauf ausgelegt, eine hohe Anzahl an Anforderungen zu verarbeiten.
Verwenden Sie eine API-Anfrage, um Daten für mehrere Zeitachsen zu schreiben, um die Anzahl der API-Anfragen zu reduzieren, die beim Schreiben von Zeitachsendaten durch Ihre Dienste auftreten.
Wir empfehlen, mindestens 10 Objekte pro Anfrage zu schreiben.
Weitere Informationen zum Batching von API-Anfragen finden Sie unter timeSeries.create.
Wenn Sie nach dem Batching Ihrer API-Anfragen weiterhin höhere Monitoring API-Kontingentlimits benötigen, wenden Sie sich an den Google Cloud-Support.
Für die anderen Limits gelten die auf dieser Seite angegebenen festen Werte.
Weitere Informationen finden Sie unter Mit Kontingenten arbeiten:
Datenaufbewahrung
Messwertdatenpunkte, deren Aufbewahrungsdauer überschritten wurde, werden aus Zeitreihen gelöscht.
| Kategorie | Wert |
|---|---|
Aufbewahrung von Datenpunkten aus benutzerdefinierten, externen und Agent-Messwerten, darunter:
|
24 Monate1 |
Aufbewahrung von Datenpunkten aus Messwerten des Typs Prozessintegrität: agent.googleapis.com/processes, , mit Ausnahme von count_by_state und fork_state, wie im vorherigen Eintrag erwähnt. |
24 Stunden |
Aufbewahrung von Datenpunkten für einige Google Cloud-Dienste, einschließlich der meisten Messwerte in den folgenden Kategorien:
|
24 Monate1 |
| Aufbewahrung von Datenpunkten aus allen anderen Messwerttypen, einschließlich | 6 Wochen |
| Lebensdauer der API-Seitentoken | 24 Stunden |
† Messwertdaten werden – bei ursprünglicher Frequenz der Probenahme – für einen Zeitraum von 6 Wochen aufbewahrt. Die Frequenz wird anschließend zur erweiterten Speicherung auf 10-Minuten-Intervalle herabgestuft.
2 Google Cloud Managed Service for Prometheus-Messwertdaten werden an der ursprünglichen Probefrequenz eine Woche lang gespeichert. Sie werden dann für die nächsten fünf Wochen auf 1-Minuten-Intervalle herabgestuft und zur erweiterten Speicherung auf 10-Minuten-Intervalle herabgestuft.
Ressourcengruppen
| Kategorie | Wert |
|---|---|
| Anzahl der Ressourcengruppen pro Messwertbereich | 500 |
| Maximale Anzahl an Gruppen in einem E-Mail-Bericht1 | 10 |
1 Bei der Konfiguration von Cloud Monitoring-E-Mail-Berichten können Sie Informationen zur Nutzung Ihrer Ressourcengruppen anfordern. Aufgrund von Einschränkungen innerhalb des Tools für die E-Mail-Berichte können die generierten Berichte jedoch nur Daten zu maximal zehn Gruppen enthalten.
Überwachte Projektlimits
Cloud Monitoring unterstützt offiziell bis zu 375 Google Cloud-Projekte pro Messwertbereich .
Sie können bis zu 1.000 Google Cloud-Projekte pro Messwertbereich hinzufügen. Es kann jedoch zu Leistungsproblemen kommen, insbesondere bei der Abfrage benutzerdefinierter Messwerte oder Verlaufsdaten. Cloud Monitoring garantiert nur für 375 Google Cloud-Projekte pro Messwertbereich leistungsstarke Abfragen und Diagramme .
Wenn Sie das Kontingent für Google Cloud-Projekte pro Messwertbereich erhöhen möchten, können Sie eine Erhöhung des Kontingents „Überwachte Projekte / Messwertbereich für die Überwachung“ beantragen. Weitere Informationen finden Sie in der Dokumentation zum Verwalten Ihres Kontingents.
Limits für das Erstellen und Aktualisieren von Messwertdeskriptoren
Cloud Monitoring erzwingt beim Erstellen neuer Messwerte, beim Hinzufügen neuer Labelnamen zu vorhandenen Messwerten und beim Löschen von Messwerten ein Ratenlimit pro Minute. Diese Ratenbegrenzung wird normalerweise nur erreicht, wenn Sie zum ersten Mal eine Einbindung in Cloud Monitoring vornehmen, z. B. beim Migrieren einer vorhandenen, ausgereiften Prometheus-Bereitstellung zu Cloud Monitoring. Dies ist keine Ratenbeschränkung für die Datenaufnahme. Dieses Ratenlimit gilt nur, wenn noch-nie-dagewesene Messwerte erstellt oder neue Labelnamen zu vorhandenen Messwerten hinzugefügt werden.
Dieses Kontingent ist fest, aber alle Probleme sollten automatisch behoben werden, wenn neue Messwerte und Messwertlabels bis zum Limit pro Minute erstellt werden.
Limits für Benachrichtigungen
| Kategorie | Wert | Richtlinientyp1 |
|---|---|---|
| Benachrichtigungsrichtlinien (Summe des Messwerts und Logs) pro Messwertbereich 2 | 500 | Messwert, Log |
| Bedingungen pro messwertbasierter Benachrichtigungsrichtlinie | 6 | Messwert |
| Bedingungen gemäß SQL-basierter Benachrichtigungsrichtlinie (öffentliche Vorschau) | 1 | SQL |
| Maximaler Zeitraum, in dem eine Bedingung für fehlende Messwerte ausgewertet wird3 |
1 Tag | Messwert |
| Maximaler Zeitraum, in dem eine Messwertschwellenbedingung ausgewertet wird3 |
23 Stunden, 30 Minuten | Messwert |
| Maximale Länge des Filters, der in einer Bedingung für Messwertschwellen verwendet wird |
2.048 Unicode-Zeichen | Messwert |
| Maximale Anzahl von Zeitreihen , die von einer Prognosebedingung überwacht werden |
64 | Messwert |
| Mindestprognosezeitraum | 1 Stunde (3.600 Sekunden) | Messwert |
| Maximales Prognosefenster | 2,5 Tage (216.000 Sekunden) | Messwert |
| Benachrichtigungskanäle pro Benachrichtigungsrichtlinie | 16 | Messwert, Log |
| Maximale Benachrichtigungsrate4 | 1 Benachrichtigung alle 5 Minuten für jede logbasierte Benachrichtigungsrichtlinie | Log |
| Maximale Anzahl an Benachrichtigungen | 20 Benachrichtigungen pro Tag für jede logbasierte Benachrichtigungsrichtlinie | Log |
| Maximale Anzahl gleichzeitig offener Vorfälle pro Benachrichtigungsrichtlinie |
1.000 | Messwert |
| Zeitraum, nach dem ein Vorfall ohne neue Daten automatisch geschlossen wird |
7 Tage | Messwert |
| Maximale Dauer eines Vorfalls, wenn er nicht manuell geschlossen wird | 7 Tage | Log |
| Aufbewahrung geschlossener Vorfälle | 13 Monate | Nicht zutreffend |
| Aufbewahrung offener Vorfälle | Unbefristet | Nicht zutreffend |
| Benachrichtigungskanäle pro Messwertbereich | 4.000 | Nicht zutreffend |
| Maximale Anzahl von Benachrichtigungsrichtlinien pro Schlummerfunktion | 16 | Messwert, Log |
| Beibehalten einer Schlummerfunktion | 13 Monate | Nicht zutreffend |
2Apigee und Apigee Hybrid sind stark in Cloud Monitoring eingebunden. Das Benachrichtigungslimit für alle Apigee-Aboebenen (Standard, Enterprise und Enterprise Plus) entspricht dem für Cloud Monitoring: 500 pro Messwertbereich.
3 Der maximale Zeitraum, der eine Bedingung auswertet, ist die Summe des Ausrichtungszeitraums und der Dauerfensterwerte. Wenn für den Ausrichtungszeitraum beispielsweise 15 Stunden festgelegt sind und das Dauerfenster 15 Stunden beträgt, sind 30 Stunden für die Bewertung der Bedingung erforderlich.
4Wenn bei der Abfrage Ihrer richtlinienbasierten Benachrichtigungsrichtlinie Labelwerte extrahiert werden, entspricht jede Kombination aus extrahierten Werten einer eigenen Benachrichtigungszeitachse. Angenommen, eine richtlinienbasierte Benachrichtigung extrahiert die Werte eines Labels. Angenommen, das Label kann zwei Werte haben. Bei dieser Konfiguration könnten Sie innerhalb von 5 Minuten zwei Benachrichtigungen erhalten, eine für jeden Labelwert.
Einschränkungen für synthetische Monitore
| Kategorie | Wert |
|---|---|
| Verfügbarkeitsdiagnosen pro Messwertbereich * | 100 |
| Maximale Anzahl von ICMP-Pings pro öffentlicher Verfügbarkeitsdiagnose | 3 |
| Synthetische Monitore pro Messwertbereich | 100† |
†Informationen zum Erhöhen dieses Limits finden Sie unter Kontingente über die Google Cloud Console verwalten.
Limits für Diagramme
| Kategorie | Wert |
|---|---|
| Dashboards pro Messwertbereich | 1000 |
| Diagramme in einem Dashboard | 40 |
| Linien in einem Diagramm | 50* |
| Zeilen in einer Tabelle | 300 |
To improve performance, we've limited the time series displayed in this chart angezeigt.
Wenn Sie alle Zeitreihen sehen möchten, maximieren Sie die Kurzinfo und wählen Sie die Schaltfläche Alle Zeitreihen anzeigen aus.
Service Level Objectives
| Kategorie | Wert |
|---|---|
| Anzahl der SLOs pro Dienst | 500 |